Feature: Implement go-e Controller integration

[CommanderRedYT]

This is a PR for adding a integration for go-e Controller.

I implemented it in a way that more integrations can be done at a later point (group it as "Integration Settings").

This is the link to the go-e API documentation: https://github.com/goecharger/go-eCharger-API-v2/blob/main/http-en.md

I am setting the api-key ecp on the go-e Controller (hostname/ip configurable via the webui) to a array with the values for the solar category and optionally the home category. It uses the local HTTP-Api of the go-e Controller. (Not Cloud HTTP API!!)

Note: Because I do not speak french, I could only set them to the english values.

I am offering to be the maintainer for at least this part of the project if wanted.

[CommanderRedYT]

I updated this value because I saw the correct value in the firmware and when copying UI elements I noticed this value being incorrect.

[CommanderRedYT]

This is the hostname format, the X's being the serial number, usually starting with 9 as the first digit.

[CommanderRedYT]

I do not speak this language so I left the keys to the english translations

[CommanderRedYT]

Small visual improvement

Before:

Now:

[CommanderRedYT]

Some JS devs have a script to load these .nvmrc files and set the correct node version automatically. I also updated the package.json file with the correct node engine version.

[CommanderRedYT]

Increase timeout when no data is available because we do not need to publish "0" so often.

The go-e Controller needs to be fed a value every couple seconds or else it will "forget" the value was set, so not sending does not work unfortunately. I also do not know the exact interval tho.

[CommanderRedYT]

FYI this will require #2331 to have successful CI runs

[CommanderRedYT]

All rebased now, should be ready to merge! 🎉

[stefan123t]

Sorry I may be numb or uninformed. Can you maybe explain what go-e Controller can be used for and/or some documentation pointers on what this integration actually achieves ;)

[CommanderRedYT]

The go-e Controller enables people who own a go-e Charger to measure their home power consumption. It is kinda a smart-meter, but you install it on a DIN rail in your apartment. It can forward this information to go-e Chargers and also has a homeassistant integration.

The information about solar can be used for pv-surplus charging for electric cars. https://go-e.com/de-at/loesungen/fuer-kunden/pv-ueberschussladen

Also, when you have a microinverter your typical setup is that when you measure your grid consumption you do not know how much energy your home uses unless you know how much energy you are producing.

This integration sets the consumption on both solar and optionally home category. These external category powers (ecp) will be added to what is measured per category.

Also here is a information I found on go-e's website:
https://go-e.com/fileadmin/Support/Anleitungen/Englisch/go-e-controller-datasheet.pdf
https://go-e.com/fileadmin/Support/Anleitungen/Deutsch/go-e-contoller-datenblatt.pdf

[CommanderRedYT]

Basically without this integration opendtu & go-e controller users will have a problem figuring out how much their home actually consumes (unless it is on its own fuse). For me, the garden outlet is on the same cable as the living room and a workdesk for example.

[CommanderRedYT]

@stefan123t Hi, I wanted to ask if this is good like that or if I need to add more info?

[stefan123t]

@CommanderRedYT thanks for the details Florian. I think now it is up to tbnobody or probably @schlimmchen at the downstream OpenDTU-OnBattery project to decide whether they want to add support for the go-e Controller.
I read up on the go-e Controller and it is something like a Shelly (Pro) 3EM, but with 6EM, that is you are able to monitor 2x 3phase or 1x 3phase and 3x 1phase.
There is already a Power Meter feature in the fork OpenDTU-OnBattery and hence it may IMHO fit in better with the feature set of the team at hoylabs.

[CommanderRedYT]

I am not so sure about that. This "power meter integration" here is just for telling the go-e Controller how much solar energy is produced so values like the home measurements are correct.

It does not mean that someone needs a battery for example, so imo it would fit in here too. It does not really have something todo with charging a battery.

[stefan123t]

@CommanderRedYT yes but the whole Power Meter and Dynamic Power Limit functionality is kept out of the mainline OpenDTU project for now, this is a feature which is available only in the OpenDTU-OnBattery daughter project.
I would also vote for having Power Meter and Dynamic Power Limit features in this project rather than only in the -OnBattery fork. But this is not my decision and there are still some changes to be expected especially with regards to Power Limit, before this is also merged into mainline.

[CommanderRedYT]

Again, you don't seem to understand. This has nothing Todo with limiting power. This is just so that the go-e Controller has the correct power levels and the pv surplus charging knows how much pv energy is there.

This MR only sets the values fetched from the inverters to the solar power value on the power meter because it is not possible to measure it due to the outlet being on the same circuit as 30 other devices

[CommanderRedYT]

Rebased the PR to newest master

[CommanderRedYT]

@stefan123t Do you know what the progress is here?

[stefan123t]

@CommanderRedYT yes I understand that this is a general use-case, but OpenDTU usually does not accept these extensions.
Though OpenDTU-OnBattery is IMHO not limited to only Batteries directly connected to OpenDTU.
You could think of the car 🏎️ connected to your go-e controller as a battery 🪫 too 🧐

@schlimmchen @AndreasBoehm is this PR #2330 something you would eventually consider in OpenDTU-OnBattery ?

[CommanderRedYT]

@stefan123t Another use case that has nothing to do with charging is that you then can for example control your water heater only when solar energy is there. There are many applications which do not involve EVs at all. It would mean that everyone who wants to use this would need to switch. And idk if you can just upload a onBattery binary as OTA for the original project.

How fast is the release cycle of onBattery? If it only takes a day or so from a opendtu release to a new onBattery release it's fine but if not I would be happier with just maintaining my own fork (which will basically just be me rebasing this PR all the time).

[stefan123t]

I am not aware of any time committment from OpenDTU-OnBattery folks at hoylabs to merge / pull updates from upstream within a day or so.
But past experience is that they communicate proactively with Thomas, ie some of the Changes are cherry picked from ODOB and/or are merged within hours. Thanks to all the people involved for maintaining both.

I would assume though that in order to merge your PR into ODOB it would require some changes.
Either by extensing the Battery / PowerMeter super classes available there. Maybe your code needs to be adapted and/or the abstract class.

Regarding your question about OTA, I have successfully flashed forth- and backward between OpenDTU and ODOB in the past.
Most of the config.json / pin_mapping.json is additional on the ODOB so I had no conflicts whatsoever. Though this can and will not be guaranteed, but you can always use the json and edit it by Hand in case you have a conflict. There is not much data stored on the OpenDTU itself most is only passed through.

[AndreasBoehm]

I don't see this as a feature for OpenDTU-OnBattery to be honest.

go-e offers mqtt and i think that this can be easily integrated using HA or nodeRed with the current data provided by openDTU: https://github.com/goecharger/go-eCharger-API-v2/blob/main/mqtt-de.md#werte-setzen

[CommanderRedYT]

@AndreasBoehm that means having additional things running. More software that requires more resources and that can fail. With HA the setting of external categories on the controller is not a feature afaik and with nodered its just another software stack just for a simple mqtt publish. That also means one would need to buy something like a raspberry pi.

When having it inside the opendtu firmware, one can even rely on go-e's cloud for data storage for example.

[stefan123t]

I can umderstand all three POVs:

• it is not OpenDTU core
• It is not OpenDTU-OnBattery either
• It is an Integration / Plugin to both OpenDTU and/or ODOB

As @CommanderRedYT already points out in his opening post it will be maintained in his own fork as a separate plugin.

I think we should somehow formalize this plugin approach eventually allowing multiple extensions to run in parallel and enhancing the functionality of OpenDTU and the features of ODOB.

Even though this may create additional overhead in the build framework I think the benefits of having this and other useful extensions running in the same context on the ESP32 are obvious.

Here is an example implementation of such a plugin framework:
https://www.reddit.com/r/esp32/comments/sxd38q/how_to_create_a_plugin_system_espidf/

I also understand that this may be neither necessary upstream in OpenDTU nor downstream in ODOB it would still benefit the Open*** ecosystem.

Though as it may pose the risk of Tasmota*zation of the build setup (i.e. a build bot which allows to generate firmware blobs with wanted and needed features) we should define the requirements for such a side car (pun intended) as a community rather thoroughly.

[CommanderRedYT]

@stefan123t With maintaining I meant if any problems exist with the code I am always there to fix it. But also of course for development and testing, as long as I don't have push permissions, I will maintain it as my own fork.