[eebus] Add support for the eebus

[mstormi]

Originating in the energy management discussion topic openhab/openhab-core#3478, having an EEBus binding would be a big benefit.

Implementing EEBus is a big task in itself, though, plus somewhat unclear if relevant and unappealing to take on (my words, but as also said @kaikreuzer in openhab/openhab-core#3478 (comment)) because of its commercial driver and origins.
It's nonetheless well alive at least in Germany and has recently become more popular in commercial implementations in major consumers like ev chargers and heat pumps.

More important even so, German standards body VDE FNN also defined it as the way forward to have smart meters (iMSys or CLS gateways, respectively) directly control/power-dim those devices OR to connect the CLSGW via EEBus to a customer-site energy management system that in turn also is connected to those devices and takes care of handling the dimming requirements.
Open source implementations have become available in EVCC and OpenWB, too.

Now with AI codegen superpower that we didn't have 3 years ago, would someone be willing take on the EEBus spec and have Claude et al implement it?

I can provide the spec if needed.

Related: openhab/openhab-core#3478

[stamateviorel]

looking at the eebus sounds like a great ideea but hardware to test will be a problem i think. Do you have a such hardware or do you have clients wich such hardware ? you are the first guy mentioning this here in belgium where i install inverters heat pumps car charger etc i never heard of eebus even though i just install an sma energy manager for an inverter. I am willing to invest an agent but without giving it direct access to hardware to test its shooting in the dark i believe. You think using only specs is enough to feed the agent ?

[mstormi]

Hard to tell. There's different use cases. You can use EEBus to control some heat pumps like Vaillant and Stiebel Eltron from your EMS.
You can use it to control some ev chargers like the Volkswagen ones ("Elli").
The most appealing one is to have a smart meter (or CLS gateway, actually) but these are very 'German' products.
Currently I don't have any of these at hand. I'd love to get hold of a CLSGW myself.

[mstormi]

Here's an Open Source implementation of EEBus in Java https://github.com/openmuc

Is there some kind openHAB developer soul able and willing to integrate that i.e. turn that into a binding?

cc: @stamateviorel @weymann

@kaikreuzer Kai would you know any developer that we could ask if he's willing to take on this ?

EEBus Spec (registration required) is available at https://www.eebus.org/specifications/download-specifications/

[stamateviorel]

I can help the licence is not a problem anymore with openmuc but hardware will they do have some virtual stuff on a subscription https://eebustester.com/

[mstormi]

Well I'd think that's over the top for us. It's their way of making money from companies that urgently need to build EEBus into their systems like smart meter producers or commercial EMS vendors.

I'd guess that we will find enough owners of EEBus-capable devices like ev chargers and heat pump within our community (see examples above). We will just have to ask our users.
Not sure on the smart meter part, to be frank, I have not heard of any EEBus capable §14a CLS gateway in operation in Germany but I believe that if there's one, I'll be one of the first to get it myself ;-) Again, we can make a public shout-out on the forum.

[stamateviorel]

The same problem was with ocpp slot of people don't have the knowledge or time to produce enough logs details about their device so unless one of us gets his hand on this type of hardware or the test software the ai will produce something but probably not usable I know from ocpp it was a lot of debugging with fable and opus and monitoring for days doing charging sessions to get most of the basic functionality working stable. But if you want setup a repo already with all information you have an I put ai to start working on it this weekend.

[mstormi]

Interesting: we might even be able to get a potential implementation of ours tested by the standards body itself or the lab they ordered to certify products, actually.
as the testing itself is said to be free (only certification is $$$, but that we don't need, right?)

https://www.50komma2.de/metering/eebus-zertifizierung-laeuft/

[lsiepel]

If nobody has a device that supports eebus, what is the point of investing all the time and effort.
Don’t want to discourage any effort, I just don’t see how this will move forward without devices and a real world use case in operation by any of the developers

[stamateviorel]

well @lsiepel the ideea sound great its what any electrician or system integrator dream of having devices you push them on the network and by magic they can all talk a common language. But yeah i install sma inverters but i never heard from sellers or clients or even me found any info about eebus until now.

@mstormi how do you want to proceed about this i just let the ai take the OpenMUC repo and come up with a binding ?

[mstormi]

well @lsiepel the ideea sound great its what any electrician or system integrator dream of having devices you push them on the network and by magic they can all talk a common language. But yeah i install sma inverters but i never heard from sellers or clients or even me found any info about eebus until now.

Well much of that is because you aren't German. It has become a hot topic here right now and is just a matter of weeks for people to show up with EEBus capable devices.
There's more out there already than you might think. It's just that usage has been very much optional and without an energy management system it's of little use so that's why nobody showed up yet.
Then again. most major OH "competitors" like HA and EVCC already jumped onto the bandwagon.

BUT! Our ministry of economics has just released new funding conditions for heat pump.
They won't be fundable without a digital control interface. Plus, first smart meter vendors announced to roll out CLS gateways and potentially provide EEBus with them so people will have their EEBus endpoint to test against at home.

@mstormi how do you want to proceed about this i just let the ai take the OpenMUC repo and come up with a binding ?

Yes please! Unless you have a better idea, of course. I'm a layman when it comes to that.

[stamateviorel]

so I let the ai take a first pass at this using the OpenMUC jeebus libraries. repo is here: https://github.com/stamateviorel/openhab-eebus-binding

worth being clear about scope - openmuc only published the java sdk for the controllable system side so far (the device being limited), not the cem/controller side, so this only lets openhab present itself as a cs and accept lpc/lpp limits from a real cem or cls gateway. can't control a real wallbox/heat pump with this yet, that would need a different sdk that doesn't exist as a published library as far as I can tell.

no eebus hardware here either so I got a go simulator running (meisel2000/eebus-cbsim, uses the enbility stack) and tested against that instead. pairing works, mdns discovery both ways, tls handshake, spine finds the lpc use case and reads state both ways. found and fixed a couple of real bugs doing that - missing ski cert extension that broke the handshake, and jeebus rejecting the entity type I'd originally picked as the default. still didn't get a full accepted active limit through end to end because the simulator's own heartbeat mechanism never actually ticks even after starting it, seems like a limitation in the demo tool itself rather than something on my end.

not a PR yet, just the repo for now so people can look at it / poke holes in it. happy to take it further if it's useful, or if anyone with real eebus hardware (or access to a cls gateway) wants to try pairing against it that would tell us a lot more than the simulator can.

[mstormi]

Wow great work @stamateviorel thanks for your initiative

I don't know how good Claude is at transcoding which is why I proposed to take the Java OpenMUC stack as the basis.
If it can do, it might be worth to attempt transcoding' the enbility stack that you already found yourself.
The EVCC software actually uses that stack, too. The stack developer actually is one of the EVCC owners in fact.

I've also found this https://github.com/volschin/eebus-ha-bridge for the EMS -> heat pump part, not sure of the scope it really covers
or its quality, but if I'm not mistaken they also seem to have used Claude to transcode a Go stack (i.e. enbility most likely).

On testing, we might be able to get an openHAB implementation tested for free by official certification entity
https://www.livinglabcologne.com/zertifizierung-de/
They claim to be doing the testing for free, just some certificate would be $$$ but that we would not need I guess (or could ask if we as a non profit organisation get it for free).

We could also announce availability of your binding in the openHAB community forum, however I doubt there's many users with EEBus CLSGWs so feeback will be sparse if any at all.

Sorry I didn't realize upfront that OpenMUC can only do the grid side.
Also Having the other hand side, i.e. have the openHAB EMS talk EEBus to heat pumps and ev chargers, would be a big plus for sure.
Asking for testers on the community for that one would very likely get us some volunteers that own such devices (like Elli chargers or Stiebel Eltron heat pumps).

[kaikreuzer]

openmuc only published the java sdk for the controllable system side so far (the device being limited), not the cem/controller side, so this only lets openhab present itself as a cs

If I understand this correctly, this feature should then not be a binding (i.e. openHAB controls other devices), but rather an IO-add-on, i.e. openHAB exposes itself through a specific protocol. We could simply add eebus metadata to items and those would then operate as lpc/lpp limits.

some volunteers that own such devices (like Elli chargers or Stiebel Eltron heat pumps).

I actually do have an VW ID. Charger Pro, which is Elli, but it's only 1. Gen and while I read in firmware updates from 31.05.2022 that they have built in EEBus, I somehow doubt that this works as expected since there are no further firmware updates released anymore...