How to subscribe to remote device?

[lukx]

Hey Andi,
thank you for the excellent work on making EEBUS available to the people :-)
I am succeeding already in using it for a HVAC Use case with my Heat Pump (and have already added a couple of features on my local branch to make this possible).

I am struggling to understand a part of the code base: How do I subscribe (as a client) to a remote data point?
I could only find the subscription implementation for when we are acting as a server... Could you point me to the right places, please?

Thanks again
Lukas

[DerAndereAndi]

Hi Lukas,

I haven't had a lot of time lately to continue working on this. The interface for this library to be used e.g. in a HEMS is far yet and we are open to suggestions. I am working on a generic HEMS implementation as an example to explore this. I need to wrap some things up to commit a bunch of changes I only have locally. The repo for that is https://github.com/DerAndereAndi/eebus-go-cem

Could you elaborate on what exactly you want to subscribe to, or what it is that you need? Maybe describe the use-case/scenario?

Thanks,
Andreas

P.S.: There is not really such a thing as a client or server in EEBUS

[lukx]

Hey,
sure thing!
See my draft #21 - it is a draft and buggy.

My use case is as follows:

• Viessmann VitoConnect offers an EEBUS connection, which is officially merely for communicating with other Viessmann Devices (thanks, open standard, I guess)
• The EEBUS implementation for Viessmann Vitoconnect does expose measurement values (like "current power"), and allows to overrun the hvac SGReady State, which would allow the user to force heating the device (e.g. because the sun is shining, right?)

I want to subscribe to the measurement values, rather than polling them every x Seconds.

I am also looking into the Binding mechanisms, as this is required for the HVAC Overrun Control
Further, I am sending a Control Signal to the remote device, to actually control the HVAC Overrun (which is why I introduced the Sending methods)

About the Client/Server: True, of course. I was referring to the Roles that one side of a communication holds for a specific feature.

[DerAndereAndi]

Thanks Lukas, I saw the PR. Awesome!

Working with the data, e.g. measurements, shouldn't be done in this library as that is a use case implementation. Use Cases differ from the HEMS perspective and the actual device, I'd like to separate this from this "core".

I will have the same task in the HEMS when implementing the measurements use case for e-mobility. As I am not there yet, I haven't decided on how this could/should work. I am very open for suggestions on this.

Binding usually means that the device should check if the HEMS registered a binding and only allow writing of that is done (as far as I remember it). So that is "basically" a management and control feature, and an interface needs to exist for doing that. Maybe it makes sense to be able to define in the stack of a binding has to exist for writing and implement the check for that in the stack instead of requiring the use-case implementation to do that. But yes, adding writing (sending) is needed :)

Regarding the Use-Case:

• The problem with VitoConnect and other devices is maybe only that most manufacturers didn't implement these EEBUS use cases into their heat pumps? I think Wolf has some which do, but I am not sure if they are doing it the same way. SMA isn't using the HVAC use cases in the Home Manager 2.0 but some other way (Use Case), for which there is no documentation available.
• I haven't looked into the Hvac use cases at all yet, so I can't say anything about the specifics, sadly (I don't have a heat pump with an EEBUS interface, sadly only with SEMP)
• Are you trying to implement a HVAC device for your existing heat pump so the VitoConnect can control it?

[DerAndereAndi]

@lukx For getting updated data, please check spine/events.go. The EventPayload struct is used to pass updated data to all subscribers. I just pushed the current WIP state of the CEM and you can see how to use event handling here: https://github.com/DerAndereAndi/eebus-go-cem/blob/dev/cem/evse.go#L84-L131

Implement the HandleEvent interface and you'll get the data updates and (hopefully) everything else that is relevant to react to.

[lukx]

Hey @DerAndereAndi , thank you for the elaboration!
Of course, this is a library, and the interfaces should be used to run a use case. I started off my implementation from an old version of your -cem repository. To be more clear, I have pushed the current state and some findings and roadmap to my repo:
https://github.com/lukx/vitobridge-sidecar

This repository still contians a lot of copy-pasted code that need to be deleted, obviously; but I am finding it convenient to read your code in the same window. at this early investigation stage, while getting acquainted with EEBUS, Vitoconnect (and go, for that matter :-/ )

The "Sending" Part is needed not so much for the binding (the Binding seems to behave completely like subscriptions, the specifications and interfaces look very alike), so it should similarly work on the special NodeManagement Feature.
The Writing is required to set a HVAC Overrun State ("SmartGrid Ready")
You'll see the usage in https://github.com/lukx/vitobridge-sidecar/blob/main/cem/hvac.go#L169

[DerAndereAndi]

I know. The CEM side needs to bind to a feature to be allowed to write (set). The recipient side needs to check when receiving a write if the sender established a binding on the corresponding feature. It is the same in the e-mobility use case. The special feature in NodeManagement does not require a binding to exist.

So what you are trying to do is implement a bridge device, so the VitoBridge can control hvac devices that do not speak EEBUS, right?

[lukx]

No, Vitobridge is the name of my project.
The Viessmann unit is called Vitoconnect.
Vitoconnect speaks EEBus to control the heatpump.
My project wants to talk EEbus to the Vitoconnect, to read measurements and to set HvacOverrun.
So no, it is not Vitoconnect who is in control, but my Vitobridge.
The intelligence will need to come from a third party system though, like SMA SHM2.0 or Home Assistant; but that part is not the hard bit once the Communication through Vitobridge -> Vitoconnect -> Heatpump works

[DerAndereAndi]

Ich schreib mal kurz in Deutsch, denn ich glaube wir meinen das gleiche.

Vitoconnect ist ein HEMS, es gibt dir keine Measurements, die kommen von der Heizung. Schreib doch mal bitte genau was du vor hast. Denn dass du jetzt noch das SMA SHM 2.0 reinbringst, irritiert. Welches Szenario willst du hier ermöglichen?

Update: diese Produktnamen immer. Ok, das ist das Modul das eine EEBUS Schnittstelle zur Heizung gibt.

[DerAndereAndi]

@lukx Ok, du macht dass etwas ähnliches wie ich. Du hast ein Endgerät mit EEBUS aber andere Energiemanagementsysteme die kein EEBUS können. Also baust du eine HEMS Komponente welche die HVAC Use-Cases kann und dann eine API nach außen zur Verfügung stellt. Das gleiche habe ich mit https://github.com/DerAndereAndi/eebus-go-cem vor, momentan hatte ich aber nur an die e-mobility use-cases gedacht.

Aber das sollte eine API für evcc, io.broker, Home Assistent oder andere bieten. In evcc könnte man es direkt integrieren, für die anderen müsste es als Daemon laufen. Evtl. sollten wir uns dort auch zusammen tun?

P.S.: Ich suche ja noch immer nach nem "gescheiten" Namen für die Lib und dann das HEMS.

[DerAndereAndi]

Der Code ist nicht Vito spezifisch, müsste identisch mit einer Wolf Anlage gehen, wenn diese die gleichen Use-Cases unterstützt. Das SMA Home Manager HEMS kann keine dieser Use-Cases, sondern nur etwas undokumentiertes. Die Brücke zu dem HEMS müsste man über SEMP abbilden, evcc hat das bereits für Wallboxen gemacht.

Measurements und ElectricalConnection Features sind bei e-mobility auch notwendig, ich hab das in evcc schon mal gebaut, d.h. das werde ich sowieso demnächst ins cem einbauen. APIs nach außen, für discovery, registration, etc. pp muss ich ja auch machen.

Wenn du Interesse hast das zusammen in ein HEMS zu gießen, kannst mich gerne mal per email anschreiben.