How to actually contribute to enbility/devices using eebus-go?

[wimleers]

@wimleers would you be interested in providing EEBUS data for your devices to https://github.com/enbility/devices ? Feel free to open a discussion in that Repo if so and you need help on how to do that
— @DerAndereAndi at enbility/eebus-go#54 (comment)

I responded I have a Vaillant 75/5 and VR921 gateway since last week. And I'd love to contribute that!

https://github.com/enbility/devices says:

The data can be collected by using the eebus-go library and follow its usage details. It does not matter if the EVSE or HEMS variant is used.

So I follow the instructions at https://github.com/enbility/eebus-go/#first-run, only to discover there already is keys/hems.crt and keys/hems.key, so I'll use those instead..

Per the instructions the next step would be:

go run cmd/hems/main.go <serverport> <remoteski> <certfile> <keyfile>

… and I've read a big part of the SHIP spec so I know I can easily get other SKIs from mDNS/DNS-SD advertisements, so I can imagine I'd do:

go run cmd/hems/main.go 4715 <remoteski> keys/hems.cert keys/hems.key

… but I have no idea what that would do? Reading https://github.com/enbility/eebus-go/blob/dev/cmd/hems/main.go doesn't really help either, since it seems to have mostly placeholder logic, no logic to log NodeManagementDetailedDiscoveryData and NodeManagementUseCaseData responses, and not even logic to request those responses? 😅

I'd like to avoid generating connections that my EEBus devices will remember and potentially complain about in the future.

So: any chance you could add a new cmd/discover/main.go that generates a discovery-data.json, usecase-data.json and device.json that leaves no state behind on my EEBus devices, that is always safe to run?

[wimleers]

Ah, https://enbility.net/blog/20230412-devices/# seems to contain documentation missing from the two GitHub repos:

[#](https://enbility.net/blog/20230412-devices/#) process

The [repository](https://github.com/enbility/devices) contains the required EEBUS messages for this overview. To get these details, the data can either be provided by an existing EEBUS compatible system, if it provides access to this data.

Alternatively the [eebus-go repository](https://github.com/enbility/eebus-go) already provides everything that is needed. Download the source code and install [golang](https://golang.org/) for your system and follow the [usage instructions](https://github.com/enbility/eebus-go#usage).

This will print the whole communication into the console window. Now either provide the full output or extract the messages with the responses for the above mentioned message types and create a PR :)

[DerAndereAndi]

https://ebusd.de/

[wimleers]

That's not the protocol Loxone uses to communicate. Impossible. Because ebus is not network-connected, and Loxone is not connected (aka physically) directly to Vaillant's ebus, only to the network.

The only plausible explanation I see is that Loxone paid/worked closely with Vaillant to get access to the custom EEBus API spec that Vaillant implemented.

[DerAndereAndi]

Loxone has some limited EEBUS support implemented, yes. But that doesn't not provide any meaningful data and has a very limited functionality. But your link to ebusd is NOT about EEBUS :)

[wimleers]

Ahhh … I see now that you were referring to my john30/ebusd-configuration#155 (comment) link — but that issue was specifically about not having to use the weird/ancient/brittle ebus and instead use Ethernet + EEBus. Which sadly — as you're implying — is a a pipe dream 😔

[DerAndereAndi]

So far sadly yes. But anyway the possible options, if I would get it somehow working, are very limited when checking the corresponding EEBUS use case documents. Some power shifting (roughly speaking), that's it.

There are updated and new EEBUS use cases for heat pumps, but these are not implemented by these devices yet.

[wimleers]

What I would be curious about is the data of your dryer and dishwasher. But you probably will need to unpair them from the SHM as well to be able to grab the data.

I will run it again later today to gather these.

P.S.: Thank you for your help so far, and HUGE thanks for publishing these libraries under a permissive license, like you wrote at https://enbility.net/blog/20221205-introduction/! This will have a huge impact for sure. I will learn go to be able to contribute.
P.P.S.: I see at https://enbility.net/blog/20230411-version-0-2/ that you added Visualization of Aggregated Photovoltaic Data 1.0.0 RC1 — I can't wait for SMA to have their inverters publish this information via EEBus. That'd allow me to get rid of all the Modbus craziness in https://github.com/wimleers/homebridge-sma-home-manager!
P.P.P.S.: unless Vaillant has hardcoded calls to SMA's APIs, it must be possible to observe PV production via EEbus too, since I see this in Vaillant's multiMATIC app:

[DerAndereAndi]

Sadly it is unknown what they do. This repo is for collecting the reported features und usecases by their devices, because that is supposed to be the way to figure out if they support compatible features or not. The EEBUS implementations in your devices are quite ... ancient I would say and as I mentioned likely require internal knowledge to get anything done with them. Sadly.

[wimleers]

Right, it feels like they all use Generic either to:

• not have to wait for specs to be finalized (positive explanation)
• be secretive… 😬 (negative explanation)

[wimleers]

Dryer: it appears it's only advertising via mDNS/DNS-SD for a handful of seconds … and then it disappears again 😳 It took me five tries to get the DNS records and the SKI, I'm now struggling to connect to it…

Have you seen this before?

[DerAndereAndi]

The SKI should be available in a web interface or maybe the manual.

Some devices only show their mDNS record if they are not already paired or if the paired device is not connected.

[wimleers]

They actually do announce their mDNS record, but it seems they immediately remove it again as soon as they've confirmed a re-connection with the SMA Home Manager:

$ dns-sd -Z _ship._tcp.
Browsing for _ship._tcp.
DATE: ---Tue 30 May 2023---
 8:40:41.928  ...STARTING...

; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp                                 PTR     @

; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.

_ship._tcp                                      PTR     SEMPSHIPGW._ship._tcp
SEMPSHIPGW._ship._tcp                           SRV     0 0 4712 SMA3012882851.local. ; Replace with unicast FQDN of target host
SEMPSHIPGW._ship._tcp                           TXT     "model=Sunny Home Manager 2.0" "type=Energy Manager" "brand=SMA" "ski=15b0409ebc54a88ca507731dfc8474bd68050e13" "register=false" "path=/ship/" "id=SEMPSHIPGW" "txtvers=1"

_ship._tcp                                      PTR     vr921_21224800202609620933091877N3._ship._tcp
vr921_21224800202609620933091877N3._ship._tcp   SRV     0 0 12480 vr921-21224800202609620933091877N3.local. ; Replace with unicast FQDN of target host
vr921_21224800202609620933091877N3._ship._tcp   TXT     "model=VR921" "type=Gateway" "brand=Vaillant" "ski=447e29b062500e87eb7cf004f604a6bda5ff20da" "register=false" "path=/ship/" "id=21224800202609620933091877N3" "txtvers=1"

_ship._tcp                                      PTR     Dryer\032BOSCH\032WTX8HE40FG._ship._tcp
Dryer\032BOSCH\032WTX8HE40FG._ship._tcp         SRV     0 0 443 BOSCH-WTX8HE40FG-68A40E476473.local. ; Replace with unicast FQDN of target host
Dryer\032BOSCH\032WTX8HE40FG._ship._tcp         TXT     "txtvers=1" "id=BOSCH-WTX8HE40FG-68A40E476473" "path=/ship" "ski=596BE8E442BE4D761583844674C646F398A75BFC" "register=false" "brand=BOSCH" "type=Dryer" "model=WTX8HE40FG"

_ship._tcp                                      PTR     Washer\032BOSCH\032WAV28EHPFG._ship._tcp
Washer\032BOSCH\032WAV28EHPFG._ship._tcp        SRV     0 0 443 BOSCH-WAV28EHPFG-68A40E46BDA6.local. ; Replace with unicast FQDN of target host
Washer\032BOSCH\032WAV28EHPFG._ship._tcp        TXT     "txtvers=1" "id=BOSCH-WAV28EHPFG-68A40E46BDA6" "path=/ship" "ski=2439C2C4FB31F1192FFFF536A4BD22E7B98F6D60" "register=false" "brand=BOSCH" "type=Washer" "model=WAV28EHPFG"
^C

$ dns-sd -B _ship._tcp.
Browsing for _ship._tcp.
DATE: ---Tue 30 May 2023---
 8:41:45.167  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
 8:41:45.168  Add        3  11 local.               _ship._tcp.          SEMPSHIPGW
 8:41:45.168  Add        3  11 local.               _ship._tcp.          vr921_21224800202609620933091877N3
 8:41:45.168  Add        2  11 local.               _ship._tcp.          Dryer BOSCH WTX8HE40FG
 8:41:45.503  Add        2  11 local.               _ship._tcp.          Washer BOSCH WAV28EHPFG
 8:41:48.090  Rmv        0  11 local.               _ship._tcp.          Washer BOSCH WAV28EHPFG
 8:41:55.638  Rmv        0  11 local.               _ship._tcp.          Dryer BOSCH WTX8HE40FG
^C

I may unpair my washer and dryer in a few weeks, when I'll have more time. For now, this is the only information I can provide unfortunately.

[wimleers]

Tangentially related:

Version 2.12.5.R (May 2023)

Performance features:

• Optimization of EEBUS applications (including when using the Vaillant VR 920 or VR 921 communication units)

— https://www.sma.de/en/products/monitoring-control/sunny-home-manager

There's a tiny chance that this means the beginning of better conformance to the EEBus spec by both SMA and Vaillant … 🤞

[DerAndereAndi]

Back in the day when these products provided EEBUS support, UseCases did not exist if I understand this correctly.

I do not think that this is mostly a problem of the SMA HM, but rather of the Vaillant implementation.

[wimleers]

Well, both are pretty terrible, since both report only Generic, right?

You're probably right that I'm being too optimistic 😬 😇 😄

[DerAndereAndi]

The EEBUS initiative recommends to implement all client features in a Generic feature, as I learned. But as clients can't talk to clients, Vaillant should provide a server feature. And they don't. I am trying to find out how this actually can work this way, but so far nobody knows.

[DerAndereAndi]

I am working on an app at https://github.com/enbility/devices-app that you might want to test out. You can find binaries for various platforms at https://github.com/enbility/devices-app/releases/tag/v0.1-20230604

This app lets you pair with an EEBUS device and it will provide the data used in this repository. Would be curious to see what your devices will show.