referring to closed Request Wolf CHA Support #23401

[Thias66]

This request was for an EEBus support for the Wolf CHA heat pump with Wolf SmartSet Cloud.
andig closed this request until Wolf brings the EEBus-Support to market.
Now it is ready. Its would be nice to control the Wolf CHA via EEBus Integration.
https://www.wolf.eu/de-de/professional/wissensmanagement/heizung/energiemanagement-waermepumpe#toc2

Thanks!
Thias

[andig]

WOLF hat die EEBUS Pilot-Qualifizierung im Living Lab Cologne erfolgreich abgeschlossen. Getestet wurden die Use Cases LPC (Leistungsbegrenzung bzw. Dimmen nach §14a) und MPC (Überwachung der Leistungsaufnahme). Damit wird WOLF ab sofort auf der Liste der qualifizierten Geräte unter livinglabcologne.com gelistet.

That's the EEbus meter- it would be nice if you could give it a try.

ts would be nice to control the Wolf CHA via EEBus Integration.

Wolf doesn't offer any control except limiting power for DSO use.

/cc @premultiply

[andig]

Energie liefert die Vaillant nicht.

Leider scheint sie das zu behaupten. Ticket beim Hersteller…

[andig]

Fehlt da nicht die db:12 Referenz?

Bitte issue oder DB an info@evcc.io

[CiNcH83]

Leider scheint sie das zu behaupten. Ticket beim Hersteller…

Vaillant weiß ja bereits darüber Bescheid. Bei der Konfiguration über den Loadpoint wurde das ja glaub mit diesem PR umschifft.

[CiNcH83]

... verschwindet dieser Zähler nach Neustart immer wieder.

Wie es aussieht, hat da das 2. Speichern eine Ebene höher im Loadpoint gefehlt.

[CiNcH83]

Leider scheint sie das zu behaupten. Ticket beim Hersteller…

Vaillant weiß ja bereits darüber Bescheid. Bei der Konfiguration über den Loadpoint wurde das ja glaub mit diesem PR umschifft.

Another periodic error while boost is active:

[lp-1 ] ERROR 2026/02/02 14:47:04 charge rater: charge total import: not available

Will hopefully get fixed in the stack used by Vaillant..

[sniesen]

Hi there!

I got a Wolf CHA-10 heatpump with the correct firmware. It sees evcc and vice versa.
I can't set the heatpump up as an SGready device, since it seems SGready in evcc doesn't support eebus as a protocol.

Since evcc can do both: SGready heatpumps and eebus as a protocol, shouldn't it be possible to use the CHA-10 with it?

[andig]

EEBus and SGReady are just different things. Not related at all.

SGready heatpumps and eebus as a protocol, shouldn't it be possible to use the CHA-10 with it?

No (and to keep repeating myself):

#25058 (reply in thread)

[sniesen]

Please excuse my ignorance, I am a complete layman when it comes to these protocols.

It seems to me that evcc already understands the eebus protocol for chargers and can communicate with them.

I understand that the topic annoys you when it is brought up again and again – I also looked at the link you referred to.

What specifically would you need to implement the necessary functionality in evcc? Or is your suggestion to simply abandon eebus and use MQTT to communicate with Wolf heat pumps?

[andig]

Wie Andi oben schrieb- aktuell gibts die Softwarebasis dafür nicht.

Es braucht eine passende EEBus Library. Mit MQTT hat das absolut nichts zu tun, ebensowenig mit SGReady.

[DerAndereAndi]

EEBUS is a foundation to be able to talk. But to actually communicate in a meaningful way both devices need to support the same so called usecases in the corresponding roles (one is some kind of a client, the other some kind of server).

The usecases that would be needed to talk to heatpumps are currently not implemented in the eebus-go project which evcc uses. Without that, applications would have to implement this themselves, which is not always possible.

[premultiply]

I keep repeating it:
Simply connect an external meter to the heat pump. Done.
Internal ‘measurements’ are usually unreliable anyway.

Optionally, you can connect up to two relay outputs to the connection terminals of almost any heat pump.

1. SGReady Boost mode on/off
2. Dimming mode on/off – Very device-dependent. If necessary (!), this can also be achieved with a locking contact or external contactor to shut down the system completely.

That's all there is to it. There are no other useful control options for a heat pump. It simply runs according to demand and configuration.

There is also no real added value in integrating heat pumps and other heating systems with much more complicated interfaces.

[andig]

@sniesen if your WOLF supports OHPCF I'd be happy to spend a little time playing with it (found a fork of @DerAndereAndi's great library that seems to offer some support, maybe worth testing). If you can make it available for remote access please feel free to reach out to info@evcc.io

[andig]

I could also provide support with my Vaillant aroTHERM plus. Either build and test branches or provide VPN and SU access to my Raspberry Pi.

@CiNcH83 first something needs to be built and that requires test access.

@DerAndereAndi are you aware if/which VPN solution works for forwarding EEBUS devices? I had the impression, that this will only work if we can make mDNS function across forwarding. It did not seems to help if I tied the remote device to a specific IP using

c.service.RemoteServiceForSKI(ski).SetIPv4(ip)

[DerAndereAndi]

mDNS is mandatory and required. You have to make that work via VPN.

[CiNcH83]

So what exactly do you need? I have a Raspberry Pi 4 strictly for experimental use (can already build evcc). So no worries if something breaks. I can give you VPN (WireGuard) access to it with full privileges. Or do want evcc to run on your side of the VPN tunnel? Guess you have debugger and everything in place? So that would be an advantage...

[andig]

mDNS is mandatory and required. You have to make that work via VPN.

Is that per library or enforced protocol? Wondering if we could support ip/port for cases where mDNS doesn't work?

[DerAndereAndi]

Enforced protocol that is enforced by the library as well. You can not establish a trust in a device to another device without it being visible via mDNS and therefor not establish a communication.