-
-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Rework of code and adding features #110
base: main
Are you sure you want to change the base?
Conversation
So, after some time i almosted finished by ideas and features mentioned. My latest commit is a huge one but allmost replaced the whole codebase of the existing ESPAltherma implementation. Following changes have been done Code Base
Definition Files X10A
Definition Files CAN-Bus
Config/Setup Process
WebUI
MQTT
CAN-Bus
X10A
Todo
The above Todo list is still open, and the code is currently in beta status. I have been running my new code on an ESP32 (specifically the ESP32-WROOM-32E) for some time now, and it has been functioning well with a Rotex HPSU compact that has X10A and CAN (SJA1000) support. I would appreciate any feedback you may have. Additionally, I am wondering how such a significant change could be merged into the master branch. Perhaps it would be better to maintain it as a separate branch or version. |
merge main changes
First feedback: Wow. |
regarding X10a definitons. Clever move to decouple translation and actual addresses. Further feedback once I had time to have an actual look. |
To test/tun it:
To generate CAN and X10A definition files (will be created in build directory):
|
Hey @munzili, quite some impressive work in here indeed. Thanks! I'll need some time to review it and would suggest to split it in smaller PR easier to discuss and merge.
I also would need to have a look but that would mean to load significantly the flash with all the translations. That's significant. |
Splitting into smaller pieces for PR could be quite difficult. The main change is to use web UI to configure and control the system instead of compiling the config into it. This means setup.h and the definitions can't be .h files anymore. Therefore, a bigger code rewrite is needed to support it. Those changes are just coupled together and can't be created in a separate PR. What can be split into an own PR is CAN Support and all changes to support it, like including own ESP-IDF and therefore dropping ESP8266 support. But this feature requires a WebUI, so the PR would depend on the first (WebUI) one. Of course, there are new features added with the web UI which can be created into an own PR, but those would not make sense in my opinion as those changes belong together. These are changes like:
|
fixed merge (created too much history comments) |
wow, that looks like a bunch of work... I've to admit, I can't get it running. The description above doesn't help me much. Is it possible to download a full "version" I just have to compile and upload? |
I must admit I couldn't compile :-( I have uploaded recent version of code and during linking I have such error: Linking .pio/build/esp32/firmware.elf Looks like some problem with LittleFSFS library - I have checked and I have this library installed ... |
@bzq-pl
|
@munzili |
@maromme |
@munzili well platformio and using github for more than downloading projects is new to me, there I would need more detailed instructions. I did all my previous projects (a lot on esp32) in arduino IDE. |
@maromme Please take a look if it helps building it. |
well, that's getting a bit off topic now: I can't exec "git submodule update --init --recursive". Guess I need some kind extension to interact with github? Besides that, thank's for the explanations. Think I'll be fine with that then |
@maromme |
@munzili: thank you very much for this update. It's a major great update, compliment.
|
@munzili : thank's for your support! I can compile, but get an error. See attached file. I run the git submodule... etc before compiling edit: maybe it's my "thing": the nice thing about the main branch of @raomin is the simplicity of installing and setup (if you find the right definition file). that opens up the project for users with minimal programming skills. Right now, I've got the feeling that the installing process (compiling and upload) is a bit "trappy". There are many more things that could go wrong. To keep the simplicity, I guess a project like that should be more "closed": no external dependencies etc. If I think of my #273 I don't like the external library as well. |
Hello @munzili, |
I already have a stable working version - I keep my ESPAltherma up to date with my latest changes, and it is running stably without problems. I also got rid of the git submodule error and created the first unit tests. The CAN reading and writing is working fine, but the protocol doesn't work yet. Either my heat pump (Rotex HPSU 516) is not compatible with the code from https://github.com/ahermann86/fhemHPSU and https://github.com/zanac/pyHPSU, as I tried to recreate their code for ESPAltherma, or there is still a problem in the code. Another problem is that ESP8266 support is still not working. The code can be compiled and installed correctly, but the chip has too little RAM to handle the web server, web updates, X10A, and CAN scans. I will not mark this PR as stable until ESP8266 support works because of backward compatibility, unless raomin maybe uses the code as a 2.0 codebase or so to keep backward compatibility. |
my main working branch ist the feature-webui branch, the rework branch is for this PR |
@munzili Any update on this PR? I'm looking into buying a Altherma 3, and want to use ESP32 (wroom) to integrate ESPAltherma with it. It looks like it would be very valuable to use your branch, as it has some upgrades to the existing codebase. |
I'm really looking forward to get your branch up and running, but I am stuck compiling. Not really sure what it can be other than it throws errors about the RASPBERRY_PI_PICO_W board? Using
I did try to pin the |
you can use the nightly prebuilds in my branch under releases |
Hallo!
I'm currently working on refactoring the code in some places and adding also new features. As those are some "breaking changes" (topic changes, code setup process changes) i want to discuses them before creating a "final" pull request. The code is not fully tested yet but compiles and runs - so this is a early sate.
I just want to be sure that those changes are OK or maybe as those are breaking changes this should be released under a new version/tag/branch ... At the moment i did not update the documentation directory - will be done when changes should be ok.
After all i'm trying also to add CAN support to read the Rotex/Altherma CAN Bus based on the pyhspu project. Not sure if it gona work but i will give it a try. I also had ideas to refactore the code setup process in generell. At the end there should not be any code changes needed. Just download a precompiled firmware and config the ESP32 over Wifi/Webserver. Would make it simpler for non-programmers to use it.
So far i made those changes: