Damit die Wärmepumpe auch weiß, wie sie auf die SG-Ready Signale des Fenecons reagieren soll, müssen noch einige Einstellungen im Sensocomfort Regler gemacht werden:
Diese Funktionen sollen bei der der EVU-Sperre deaktiviert werden: Wärmepumpe und Zusatzheizung.
Außerdem soll der Heizungs-Pufferspeicher geladen werden, wenn Überschuss da ist.
Der FB/OT-Eingang ist ein Multifunktionseingang, der kann für verschiedene Dinge genutzt werden. Hier soll er für PV genutzt werden:
Der Fenecon Home hat ein paar eingebaute Relais, die die (optionale) App auf- und zumachen kann. Die Wärmepumpe hat ein paar Klemmen, die im Normalzustand unbelegt und offen sind. Wenn man ein Relais da rantüdelt und dieses schließt, sieht die Wärmepumpe eine 1, da dann die beiden Pins dann verbunden sind. Wenn die Pins offen sind, ist es eine 0.
SG-Ready hat zwei Bits, was vier Zustände ergibt:
0
0
Normalbetrieb
0
1
Einschaltempfehlung
1
0
Sperre
1
1
Einschaltbefehl
Die Sperre ist für den Heimgebrauch irgendwie Quatsch. Warum sollte eine PV der Wärmepumpe eine Sperre schicken? Für einen Netzbetreiber ergibt das Sinn, aber für zuhause eher nicht. Oder für ganze Harte: wenn ich keinen selbstproduzierten Strom mehr habe und ich absolut keinen kaufen will, friere ich lieber. Oder wenn er bei dynamischen Strompreisen gerade sehr teuer ist. Es mag Anwendungsfälle dafür geben.
Normalbetrieb ist der Zustand wie ohne SG-Ready Anbindung. Es liegt kein Signal an, da keine Pins verbunden sind.
Die Einschaltempfehlung scheint der sinnvolle Status für eine PV-Überschussladung zu sein. In diesem Zustand bringt unsere Vaillant erst den Warmwasserspeicher und anschließend den Heizungsspeicher auf maximale Temperatur, jedenfalls solange das Signal anliegt. Die Heizung unterbricht dabei aber keine definierten Aus-Zeiten oder Nachtabsenkungen.
Der Einschaltbefehl bringt zwangsweise den Warmwasserspeicher und anschließend den Heizungsspeicher auf maximale Temperatur und ignoriert dabei definierte Aus-Zeiten oder Nachtabsenkungen. Das mag für einen Netzbetreiber sinnvoll sein. Wenn ich weiß, daß ich die Anlage heute drosseln muss (Sperre), dann ergibt es Sinn, die Wärme vorher zu speichern, damit es dann beim Kunden nicht kalt wird und er noch Warmwasser im Tank hat. Für den Heimgebrauch finde ich das Ignorieren der hinterlegten Programmierung nicht sinnvoll.
Letztendlich braucht man für zuhause eigentlich nur zwei Modi: Normalbetrieb und Einschaltempfehlung. Da reicht eine Klemme und ein Relais. Dann kann man die anderen Relais noch für was anderes benutzen. Das Setzen des hinteren Bits reicht: dann kann man Normalbetrieb und Einschaltempfehlung ansteuern.
Die Vaillant ArothermPlus kann beides: 1 Signal aka PV-Ready oder 2 Signale aka SG-Ready.
Für SG-Ready braucht man dann noch ein zweites Kabel. Die erste Leitung ist unverändert. Das zweite Relais kommt an den S21 ran.
Die Konfiguration der App ist etwas versteckt. Auf dem Fenecon die FEMS-App-Übersicht öffnen:Die App auswählen, den Cookie-Hinweis einfach ignorieren und rechts den Button „App Bearbeiten“ auswählen. Dahinter versteckt dich die Konfigurations-Ebene; wer immer sich das wohl ausgedacht hat.
Da kann man dann auswählen, welches Relais wofür verwendet wird.
Wann der Fenecon die Zustände auslöst, lasst sich in der GUI konfigurieren:
Wenn der Wechselrichter das nicht kann, könnte man die beiden Kontakte in der Vaillant auch an ein Shelly-Relais verbinden und den Shelly aus dem Home-Assistent ansteuern.
Merkwürdigerweise exportieren nicht alle Schnittstellen am Fenecon Home die gleichen Informationen. Die Rest-API hat mehr als Modbus, ist aber leider nur unvollständig dokumentiert. Die internen Temperaturen, die Netzfrequenz oder die Alterung der Batterie z.B. scheint es nur über Rest zu geben. Home Assistant kann Rest von Haus aus:
Die Sensoren kommen aus der Modbus-Integration, Man muss aus der Menge der Sensoren nur die erwischen, die genau das liefern, was Home Assistant erwartet.
Für einige Sensoren sind noch Details verfügbar, z.B: die Preise oder die Solar-Wettervorhersage (die ziemlich ungenau ist).
Das ergibt dann eine schöne Übersicht über Verbrauch, Produktion und Kosten von Strom, Gas, Wasser, …
Es gibt für den Fenecon Home ein Addon, welches die WebSocket-Schnittstelle anzapft und die Daten per MQTT in den Home Assistant bringt. Teilweise ist diese Schnittstelle ausführlicher als die Modbus-Schnittstelle. Modus bietet z.B. nicht die Einzelwerte der Strings an, sondern nur die Summe.
Die Installation ist recht simpel: downloaden, Benutzer/Passwort und zwei IPs eintragen. Die eine IP ist die des MQTT-Brokers (normalerweise der Home Assistant), die andere IP ist die des Fenecons.
Den Fenecon Home in Home Assistant einzubinden ist nicht wirklich kompliziert. Der Fenecon bietet Modbus an, welches im lokalen Netz zu erreichen ist.
In der configuration.yaml reicht ein Eintrag wie
modbus: !include fenecon-modbus.yaml
In der fenecon-modbus.yaml sind dann die ganze Sensoren drin. Vorlagen dafür finden sich in diversen Foren. Die Konfiguration hängt sicherlich immer von der konkreten Hardware ab. Bei mir sieht das so aus.
- name: „fems“ delay: 5 timeout: 5 type: tcp host: 192.168.168.99 port: 502 sensors: #INT - name: "FEMS_EssSoc" # Battery SoC scan_interval: 60 data_type: uint16 input_type: input device_class: battery state_class: measurement unit_of_measurement: „%“ address: 302 slave: 1 unique_id: fems_modbus_302 #FLOAT32 - name: "FEMS_EssActivePower" # Combined Power of PV + Battery unit_of_measurement: W scan_interval: 10 data_type: float32 input_type: holding device_class: power state_class: measurement address: 303 slave: 1 unique_id: fems_modbus_303 - name: "FEMS_GridActivePower" # Grid Power unit_of_measurement: W scan_interval: 10 data_type: float32 input_type: holding device_class: power state_class: measurement address: 315 slave: 1 unique_id: fems_modbus_315 - name: "FEMS_ProductionDcActualPower" # PV Power unit_of_measurement: W scan_interval: 10 data_type: float32 input_type: holding device_class: power state_class: measurement address: 339 slave: 1 unique_id: fems_modbus_339 - name: "FEMS_ConsumptionActivePower" #House Power unit_of_measurement: W scan_interval: 10 data_type: float32 input_type: holding device_class: power state_class: measurement address: 343 slave: 1 unique_id: fems_modbus_343 - name: „FEMS_EssActivePowerL1“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 391 slave: 1 unique_id: fems_modbus_391 - name: „FEMS_EssActivePowerL2“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 393 slave: 1 unique_id: fems_modbus_393 - name: „FEMS_EssActivePowerL3“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 395 slave: 1 unique_id: fems_modbus_395 - name: „FEMS_GridActivePowerL1“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 397 slave: 1 unique_id: fems_modbus_397 - name: „FEMS_GridActivePowerL2“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 399 slave: 1 unique_id: fems_modbus_399 - name: „FEMS_GridActivePowerL3“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 401 slave: 1 unique_id: fems_modbus_401 - name: „FEMS_ConsumptionActivePowerL1“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 409 slave: 1 unique_id: fems_modbus_409 - name: „FEMS_ConsumptionActivePowerL2“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 411 slave: 1 unique_id: fems_modbus_411 - name: „FEMS_ConsumptionActivePowerL3“ unit_of_measurement: W scan_interval: 20 data_type: float32 input_type: holding device_class: power state_class: measurement address: 413 slave: 1 unique_id: fems_modbus_413 - name: "FEMS_EssDischargePower" #Battery Discharge Power unit_of_measurement: W scan_interval: 5 data_type: float32 input_type: holding device_class: power state_class: measurement address: 415 slave: 1 unique_id: fems_modbus_415 #Energy (Float64) - name: "FEMS_EssActiveChargeEnergy" #not sure what this is, I think its the Energy the battery has been charged form AC/the Grid, should not be too high, because its normally not possible/allowed (in Germany at least) to charge from the Grid. unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 351 slave: 1 unique_id: fems_modbus_351 - name: "FEMS_EssActiveDischargeEnergy" #not sure what this is, I think its the total amount of Energy the System has put out to AC, so basicially the the amount of PV minus what is currently stored in the battery plus the amount that you have charged from the Grid (so FEMS_EssActiveChargeEnergy), but that is normally not possible, so this is not very useful. unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 355 slave: 1 unique_id: fems_modbus_355 - name: "FEMS_GridBuyActiveEnergy" #Total Consumption from Grid unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 359 slave: 1 unique_id: fems_modbus_359 - name: "FEMS_GridSellActiveEnergy" #Total Energy Sold to Grid unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 363 slave: 1 unique_id: fems_modbus_363 - name: "FEMS_ProductionActiveEnergy" # Total PV Production Energy unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 367 slave: 1 unique_id: fems_modbus_367 - name: "FEMS_ConsumptionActiveEnergy" # Total Energy Usage unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 379 slave: 1 unique_id: fems_modbus_379 - name: "FEMS_EssDcChargeEnergy" # Total Battery Charge Energy unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 383 slave: 1 unique_id: fems_modbus_383 - name: "FEMS_EssDcDischargeEnergy" # Total Battery Discharge Energy unit_of_measurement: Wh scan_interval: 60 data_type: float64 input_type: holding device_class: energy state_class: total_increasing address: 387 slave: 1 unique_id: fems_modbus_387
Wenn das alles eingebunden ist, kann man das im Energie-Dashboard einrichten:
Im Fenecon-Webinterface sind noch weitere Modbus-Register aufgeführt, aber da kommen keine Werte. Vermutlich sind die nur aktiv, wenn man mehrere Batterie-Türme oder die optionalen Relais-Boards hat, …
Die Vaillant ArothermPlus benutzt eBus zur Kommunikation zwischen den Komponenten: Bedienpanel, Hydraulikstation, Solarthermie, …
eBus ist eine Art RS232-Bus, was natürlich kein normaler Rechner beherrscht. Aber es gibt einige wenige Adapter, wie z.B. den eBus Adapter.
Der Anschluss des Adapters an den eBus ist relativ simpel. An den eBus ranzukommen ist dagegen nicht so ganz einfach. Im Bedienpanel ist kein Platz für ein weiteres Kabel. Die Wärmepumpe ist draußen, da müsste wieder ein weiteres Kabel durch die Wand. Und die Hydraulikstation muss man aufmachen und an die reichlich beengte Steuerplatine ran. Im SensoNet liegt der eBus nicht als normale Klemme an, sondern ein komischer Spezialstecker welcher mit einem vergossenen Kabel an die Hydraulikstation geht. Bei uns liegt der eBus aber im Vaillant VR70 Mischer gut zugänglich an.
Da die Klemme für ein weiteres Kabel zu klein war, mussten zwei Wago-Klemmen als kleine Verteiler herhalten. Die Polung ist egal. Von dort aus geht ein Kabel (ca 5 Meter, Schlauchleitung H03 VVH2-F 2×0,75 mm² ) in den Netzwerk-Schrank. Dort ist der eBus-Adapter eingebaut; da liegt er sicher, hat Strom, … und baumelt nicht irgendwo an der Wand rum.
Der Adapter selber hatte eine alte Firmware, die bei mir nicht stabil lief. Das Flashen ist auf der WebSeite beschrieben, aber etwas merkwürdig (Webbrowser, serielle Schnittstelle, …) ging dann aber nach mehreren Versuchen. Seitdem läuft der Adapter (überwiegend) stabil, wobei mir noch nicht ganz klar ist, ob der Adapter oder der eBusD manchmal hängt.
Zum Einrichten baut er ein kleines WLAN auf, bei dem man sich anmeldet und die Erstkonfiguration macht. Im Prinzip braucht er nur die Zugangsdaten zum Haus-Wifi und für das Webinterface einen Benutzer und ein Passwort.
Wichtig ist der eBus Device String, der angezeigt wird.
Zur Integration des eBusD in den Home Assistant gibt es verschiedene Varianten. Ich habe dieses AddOn benutzt, das sich über den HACS installieren lässt.
Für die Konfiguration dieses Addons braucht man wieder den eBus Device String von oben. Für das AddOn muss dann noch der Autostart aktiviert werden.
Danach den Adapter und den Home Assistant einmal neu starten. Wenn alles klappt, zeigt der Adapter bei eBusD connected ein Yes an. Und bei eBus acquired natürlich auch.
Das Addon richtet die Datenübertragung per MQTT ein:
Danach bekommt man wirklich viele Entitäten in den Home Assistant gespült:
Viele von den Werten bekommt man auch über Vaillant-API, aber nicht alle. Die Temperaturen aus dem Solarthermie-Mischer VR70 z.B. hat die API nicht. Einige fehlen aber auch, z.B. die Arbeitszahlen. Die errechnet sich der Vaillant-Service vermutlich aus den Rohdaten, denn der VR921 hängt ja auch am eBus und sollte daher nicht mehr Daten zur Verfügung haben.
Die App auswählen, den Cookie-Hinweis einfach ignorieren und rechts den Button „App Bearbeiten“ auswählen. Dahinter versteckt dich die Konfigurations-Ebene; wer immer sich das wohl ausgedacht hat.
