So lässt sich der Fenecon Home in das Home Assistant Energie-Dashboard einbinden:
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.
mqtt_broker_host: 192.168.0.xyz
mqtt_broker_port: 1883
mqtt_broker_user: FeneconUser
mqtt_broker_passwd: FeneconPasswort
Den Benutzer und Passwort muss man vorher im Home Assistant in den Einstelllungen anlegen.
fems_ip: 192.168.0.abc
fems_password: user
Das Passwort user ist das Standard-PW des Fenecons.
Danach einmal den HA durchstarten und über die vielen neuen Sensoren freuen:
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.
Wenn man in Home Assistant den Wasser- oder Gasverbrauch pro Tag erfassen will, muss man die Impuls-Zähler um Mitternacht zurück setzen. Ansonsten zählt der einfach immer weiter und man hat keine Unterscheidung zwischen den Tagen sondern den Gesamtverbrauch über alle Tage.
Dafür braucht man eine Automatisierung. Der Auslöser ist die Uhrzeit und die Aktion ist der Service counter.reset. Dort dann die beiden Wasser- und Gaszähler auswählen:
Grmpf. Ich habe die letzten Tage beim Basteln ein paar mal die Konfiguration des Shelly Plus i4 DC verloren, war einfach so weg. Keine Ahnung warum.
Heute ist mir bei einem Basteln mit einem anderen Shelly Plus i4 klar geworden, was da passiert: ein automatisierter Reset auf die Werkseinstellungen.
Beim i4 löst man einen Factory-Reset aus, in dem man den höchsten Eingang mehrfach schnell auf An zieht. Eigentlich sind die Dinger ja für Lichtschalter gedacht und da passiert das in der Geschwindigkeit eher nicht. Es hämmert ja niemand per Dauerfeuer auf einem Lichtschalter rum. Na gut, Kleinkinder vielleicht wenn sie die Sache mit dem Lichtschalter entdecken.
Aber eine Wasseruhr bekommt das hin, wenn da pro Liter ein Impuls kommt. Und in so eine Toilettenspülung gehen ein paar Liter rein; und schon geht die Konfiguration in die Kanalisation.
Also nicht Eingang 4 nehmen. Oder in der Konfiguration den externen Factory-Reset abschalten. Aber dann bekommt man ihn extern nicht mehr zurückgesetzt; auch doof.
Ich wollte meinem Home Assistant noch das Messen des Wasser- und Gasverbrauches beibringen. Wie immer, wenn man es fertig hat, ist es im Kern einfach; aber der Weg war etwas beschwerlich. Daher hier mein funktionierendes Setup.
Komponenten:
Mit der original Shelly-Firmware habe ich es nicht hinbekommen, keine Ahnung warum
Die Abnehmer kann man auch preiswerter machen, aber insbesondere der für die Wasseruhr sitzt mechanisch stabil auf drauf. Kein Wackeln, kein Kleben, … einfach draufstecken und er rastet auf diesen Zapfen ein.
Der Gas-Abnehmer hat nur zwei Kontakte, bei dem Wasserabnehmer braucht man Weiß und Braun, der Rest kann weg.
Beim Tasmota-Shelly müssen die Eingänge auf Switch_n stehen. Die beiden Abnehmer habe ich an Eingang 1 und 4 dran:
Die Konfiguration als Switch erzeugt zwei Signale: Schalter an und Schalter aus, jedesmal wenn der Reed-Kontakt ein Signal sendet. Das zweite Signal kann man im HA einfach ignorieren. Die Konfiguration als Button wäre eigentlich korrekter, aber Buttons in HA sind umständlich, da die nicht als Entität in den Automatisierungen auftauchen; warum auch immer.
Beim Tasmota-Shelly läuft die Datenübertragung per MQTT an den Home Assistant:
Jetzt braucht es noch etwas Konfiguration im Home Assistant. Für Gas und Wasser wird je eine Automatisierung benötigt: wenn der Schalter sich öffnet, muss ein Zähler erhöht werden; wir zählen die Impulse.
Die Zähler für Gas und Wasser legt man als Helfer an:
In der Automations.yaml sieht das dann so aus:
- id: ‚1698295769848‘
alias: WasserUhrEvent
description: WasserUhrEvent
trigger:
- platform: state
entity_id:
- binary_sensor.energo_switch1
from: ‚off‘
to: ‚on‘
condition: []
action:
- service: counter.increment
data: {}
target:
entity_id: counter.wasserzahler
mode: single
- id: ‚1698295894472‘
alias: GasEvent
description: GasEvent
trigger:
- platform: state
entity_id:
- binary_sensor.energo_switch4
from: ‚off‘
to: ‚on‘
condition: []
action:
- service: counter.increment
data: {}
target:
entity_id: counter.gaszaehler
mode: single
Jetzt müssen wir uns noch Sensoren basteln, damit diese in Diagrammen und im Energie-Dashboard verwendet können. Die werden in der Configuration.yaml erzeugt:
template:
- sensor:
- name: „Sensor_Gas_m3“
unit_of_measurement: „m³“
device_class: gas
state_class: total_increasing
state: >
{% set gas = states('counter.gaszaehler') | int %}
{{ ((gas) * 0.01) | round(1, default=0) }}
- sensor:
- name: „Sensor_Gas_kwh“
unit_of_measurement: „kWh“
device_class: energy
state_class: total_increasing
state: >
{% set kwh = states('sensor.Sensor_Gas_m3') | float %}
{{ ((kwh) * 10.48) | round(1, default=0) }}
- sensor:
- name: „sensor_Wasser_L“
unit_of_measurement: „L“
device_class: water
state_class: total_increasing
state: >
{% set water = states('counter.wasserzahler') | int %}
{{ ((water) * 1) | round(1, default=0) }}
Die Umrechnungswerte sind bei mir pro Impuls 0,01 qm Gas und pro Liter Wasser. Der Brennwert des Gases findet sich auf der letzten Gas-Rechnung und unterscheidet sich von Netzbetreiber zu Netzbetreiber. Bei uns sind es 10,48.
Danach lassen sich dann Diagramme definieren:
Und auch im Energiedashboard aufnehmen:
Das Einbinden einer Vaillant ArothermPlus in den Home Assistant ist im Kern trivial:
Danach bekommt man diverse Messwerte der Wärmepumpe in den Home Assistant gespült: Energieverbräuche für Heizung und Warmwasser, Umweltgewinne, … aber auch viele Anlageneigenschaften wie aktueller Wasserdruck oder die hinterlegten Konfigurationen (Heizkurve, …).
Zur Installation braucht man allerdings eine native Home Assistant Installation, keine die im Docker läuft.
Leider dokumentiert Vaillant die API nicht offiziell, sodaß Signalkraft mittels myVaillants Android-App und MITM-Proxies den Datenverkehr beobachtet um zu sehen, was da passiert.
Wer die Integration am Laufen hat, kann helfen, indem er seine Anlagenkonfiguration mittels Testscript ausliest und hochlädt:
So ein dämlicher Bug. Ich habe bei einem Ausstor den Hostnamen geändert. Leider waren die MDNS-Ankündigungen danach immer noch auf den alten Namen. Das Asustor-OS vergisst einfach den Eintrag in der entsprechenden Config-Datei zu ändern.
Ich habe bestimmt eine halbe Stunde gesucht, bis ich endlich den Order gefunden habe, wo Asus die Avahi-Konfigurationsdateien versteckt:
/volume0/usr/builtin/etc/avahi
Wieso lassen die die Datei nicht da, wo sie hingehört?
Ich habe unsere Vaillant Heizung über das VR921 Internet-Modul in den Home Assistant eingebunden bekommen:
Bis dato hatte ich den Home Assistant als Docker-Container auf meinem Raspi laufen (der auch Pi-Hole etc macht). Aber das Vaillant-Plugin ist nicht in der HA-Standard-Distribution und damit auch nicht im Container enthalten.
Es gibt bei Github das myVaillant Plugin (https://github.com/signalkraft/mypyllant-component#readme) welches, man über HACS (Home Assistant Community Store) installieren kann. Aber auch der HACS ist nicht im Container drin. Und einen neuen Container zu bauen und zu pflegen war mir zu viel Arbeit.
Also habe ich einen zweiten Raspi genommen, die native HA-Distribution geladen und konnte dann das HACS und das myVaillant Plugin installieren. Das lief völlig problemlos und bringt wirklich viele Entitäten in das System:
Der einzige Krampf war, aus dem Container die ganzen Messwerte zu holen und in die native Installation zu bekommen. Ich wollte ja nicht die gesamte Historie (Stromverbrauch, …) verlieren. Das ging dann aber auch irgendwann. HA hat eine Backup-Funktion, die das Backup-Archiv dann aber irgendwo lassen muss. Und dann wollte die native Installation das Backup nicht restoren und brach immer ab. Nach dem x-ten Versuch und diversen SW-Updates ging es dann trotzdem.
Das Plugin geht an die API von Vaillant ran, daß heißt, die Daten gehen über das VR921 erstmal raus und kommen dann wieder rein. Im Kern Quatsch, aber einfach einzurichten. Die Vaillant-App stört sich nicht dran, daß da noch jemand mitlauscht.
Das nächste Vorhaben ist jetzt die lokale Anbindung über den eBusD. Dafür liegt hier schon der Adapter (https://adapter.ebusd.eu/).
Wenn das klappt, bekommt die Lüftungsanlage Vaillant Recovair auch noch einen ebus-Adapter verpasst. Die Recovair dürfte im Kern langweilig sein, da gibt es nicht nur wenige Sensoren und noch weniger Aktoren. Aber: Because we can.
Bis dato macht sich die Wärmepumpe nicht großartig im Stromverbrauch (gemessen mit dem Shelly 3EM) bemerkbar:
Warten wir mal ab, wie das im Winter wird.
