Improvements: Webserver / integration simplification

[dalathegreat]

What

This PR implements simplified webserver & battery/inverter integrations

Why

To simplify further development and make scaling the software up easier

How

• Instead of large #ifdef blocks inside Webserver.cpp to signal what battery/inverter is used, we now write a text string to the datalayer on startup. The webpage displays both battery_protocol and inverter_protocol. This simplifies development, no longer needed to add inverter/battery specific text outside of the battery's .cpp file.
• init_inverter() now calls setup_inverter() in each inverter protocol. Code required specifically for inverter protocol is now inside that inverter protocols .cpp file. This simplifies development, with less risk of forgetting inv specific stuff
• All #ifdef intervalUpdateValues removed, since code now updates at 1s rate instead of 5s
• Startup DEBUG_VIA_USB texts removed
• BONUS: Some inverter/batteries were missing from the Github workflow. Added them to build system

[nagyrobi]

Although it would probably require a serious amount of work at first, maybe it's worth considering implementing all these as ESPHome components.

ESPHome is a very well designed, extremely modular environment. It natively supports CAN and Modbus as frameworks, adding discrete devices on top of these is pretty straightforward. Has webserver support, MQTT fully customizable.
Easier to maintain on long term.

[dalathegreat]

Although it would probably require a serious amount of work at first, maybe it's worth considering implementing all these as ESPHome components.

ESPHome is a very well designed, extremely modular environment. It natively supports CAN and Modbus as frameworks, adding discrete devices on top of these is pretty straightforward. Has webserver support, MQTT fully customizable. Easier to maintain on long term.

Feel free to fork it there! I personally dont use MQTT or Webserver, I focus mainly on getting a stable and reliable way to re-use the batteries.

[clowrey]

Although it would probably require a serious amount of work at first, maybe it's worth considering implementing all these as ESPHome components.

ESPHome is a very well designed, extremely modular environment. It natively supports CAN and Modbus as frameworks, adding discrete devices on top of these is pretty straightforward. Has webserver support, MQTT fully customizable. Easier to maintain on long term.

I want to do a small test with ESPhome soon - I already have some of the Tesla M3 battery protocol decoded via ESPhome, mainly just need to emulate the BYD HV protocol - any interest in helping with that @nagyrobi ? I don't think it will be particularly hard and could be done all in YAML, or via an external component. We probably should start another thread on the discord or somewhere else to discuss this though.

[clowrey]

For this commit I fully support removing as many #ifdef blocks as possible from the code base :).

Somehow getting the dual batteries to not require doubling the Tesla.cpp file would be a huge improvement too eventually. Probably by making everything classes etc.

[dalathegreat]

Somehow getting the dual batteries to not require doubling the Tesla.cpp file would be a huge improvement too eventually. Probably by making everything classes etc.

This is on my TODO list, I really want to refactor the battery handling as a class (which would get rid of duplicate code). But a bit too much for this PR :)

[nagyrobi]

any interest in helping with that @nagyrobi

Sure!

[amarofarinha]

Very nice! LGTM.