Ich hatte das Problem, dass ich einem Fenecon Home System lokale Leistungs- und Energiewerte meiner Wallbox und eines Heizstabes zur Verfügung stellen wollte. Man kann natürlich separate Energiezähler kaufen und bei Fenecon App Lizenzen für eben diese Energiezähler. Das kostet am Ende erklecklich viel Geld. Es gibt aber auch die kostenlose Shelly DIY App. Damit erlaubt Fenecon das lokale einbinden einfacher Shelly Wifi Stecker. Allerdings ist meine Wallbox kein Shelly Gerät und 3-phasig. Und der Heizstab läuft mit Tasmota. Also lag die Idee nahe, genau die offen dokumentierte Shelly API zu emulieren, so dass die Fenecon Shelly DIY App die Geräte erkennt.
Inzwischen habe ich dafür zwei funktionierende Ansätze aufgebaut. Beide emulieren einen Shelly Plug S Gen3 auf einem ESP32 und stellen die nötigen HTTP-Endpunkte lokal im Netz bereit. FENECON kann das Gerät dann wie einen echten Shelly einbinden.
Die beiden Varianten sind:
- ESPHome + eigene C++ Komponente. Damit kann man mittels Home Assistant beliebige Energie / Leistungswerte errechnen und an das Fenecon System melden.
- Tasmota32 + Berry Scripting. Erweitert Tasmota, so dass Tasmota Geräte in das Fenecon System eingebunden werden können.
Die Projekte liegen hier auf GitHub:
Worum geht es technisch?
FENECON erwartet bei der Shelly-DIY Einbindung bestimmte lokale HTTP-Endpunkte und JSON-Antworten. Wenn man diese ausreichend passend bereitstellt, akzeptiert FENECON das Gerät als Shelly und liest daraus die Leistung. Akutell errechnet das FEMS (Fenecon Energy Management System) daraus die Energie (zeitliches Integral). Die Einbindung meldet Leistung und Energie – wer weiß, was Fenevon ggf noch erweitert.
Die wichtigsten Endpunkte sind dabei:
- /shelly
- /rpc/Shelly.GetDeviceInfo
- /rpc/Shelly.GetStatus
Ich habe noch weitere Endpunkte erzeugt, wie sie in der offenen Shelly API Doku nachzulesen sind:
- /rpc/Switch.GetStatus
- /status
- /meter/0
- /relay/0
Entscheidend ist also nicht, dass da wirklich ein Shelly steckt, sondern dass sich das Gerät aus Sicht von FENECON ausreichend so verhält.
Variante 1: ESPHome Emulator
Die erste Variante basiert auf ESPHome. Die Daten kommen dabei aus Home Assistant, konkret aktuelle Leistung und kumulative Gesamtenergie. Eine eigene C++ Komponente innerhalb von ESPHome erzeugt daraus die nötigen Shelly-Endpunkte.
Das ist dann interessant, wenn die Messwerte sowieso schon in Home Assistant vorliegen oder dort berechnet werden.
Repository:
Der Charme an dieser Lösung ist, dass man auf vorhandene Home-Assistant-Daten aufsetzen kann. Die Shelly-Emulation ist dabei relativ nah an ESPHome und für mich gut kontrollierbar. Die Lösung läuft auf einem ESP32-C3 (Wroom geht auch – Änderungen in der yaml beachten!).
Besonderheit bei der ESPHome Variante: die YAML muss angepasst werden
Bei der ESPHome Variante reicht es nicht, einfach nur den Code zu übernehmen. Man muss die YAML Konfiguration an die eigene Umgebung anpassen.
Das betrifft vor allem diese Punkte:
- WLAN Zugangsdaten
- API und OTA Zugangsdaten
- die Home-Assistant Entität für die aktuelle Leistung
- die Home-Assistant Entität für die kumulative Energie
Im Repository liegt dafür eine Beispielkonfiguration:
Wichtig ist insbesondere, dass die richtigen Home-Assistant Sensoren eingetragen werden. Einer davon muss die aktuelle Leistung liefern, der andere die gesamte Energie als fortlaufenden Zähler.
Die entscheidende Stelle sieht dabei ungefähr so aus:
sensor:
- platform: homeassistant
id: power_from_ha
entity_id: sensor.wallbox_aktuelle_leistung
internal: true
- platform: homeassistant
id: energy_from_ha
entity_id: sensor.wallbox_geladen_total
internal: true
filters:
- multiply: 1000.0Worauf man achten muss:
- power_from_ha muss einen aktuellen Leistungswert liefern, typischerweise in W
- energy_from_ha muss einen fortlaufenden Gesamtenergiezähler liefern
- wenn dieser Energiewert bereits in Wh vorliegt, darf der multiply: 1000.0 Filter natürlich nicht verwendet werden
- wenn er in kWh vorliegt, ist genau diese Umrechnung nötig
- die entsprechenden Entitäten muss man ggf über Helfer errechnen.
Die ESPHome Konfiguration lädt die eigentliche C++ Komponente dann direkt aus dem GitHub Repository nach. Man muss also nicht den Komponenten-Code lokal in den ESPHome Konfigurationsordner kopieren. Das Anlegen einer YAML auf Basis der Beispiel-Datei und das Anpassen der Einträge reicht aus.
Erst wenn diese YAML sauber zur eigenen Home-Assistant Installation passt, liefert der Emulator auch die richtigen Werte an FENECON – und das kann man im Debug Userinterface (s.o.) testen
Variante 2: Tasmota Emulator
Die zweite Variante basiert auf Tasmota32 und Berry. Hier kommt die Energie direkt aus einem Tasmota Gerät mit aktivem Energiemodul. Das Berry Skript emuliert darauf lokal die nötigen API-Endpunkte eines Shelly Plug S Gen3.
Das ist praktisch, wenn bereits ein passendes Tasmota Energiegerät vorhanden ist und man keine zusätzliche ESPHome/Home-Assistant-Kette aufbauen möchte.
Repository:
Die Installation ist extrem simpel. Für die Installation auf Tasmota müssen lediglich diese beiden Dateien in das Tasmota Dateisystem hochgeladen werden:
- fenecon_shelly_emulator.be
- autoexec.be
Danach reicht ein Reboot des Geräts.
Endpunkte im Browser testen
Bevor man das Ganze in FENECON einbindet, sollte man die Endpunkte einmal direkt testen. Am einfachsten geht das im Browser, alternativ auch mit curl oder wget.
Die drei wichtigsten Tests sind:
- http://<ip-des-geraets>/shelly
- http://<ip-des-geraets>/rpc/Shelly.GetDeviceInfo
- http://<ip-des-geraets>/rpc/Shelly.GetStatus
Wenn dort JSON-Antworten kommen, ist die Emulation grundsätzlich aktiv.
Wichtig ist dabei nicht, dass alles “schön” aussieht, sondern dass gültiges JSON zurückkommt und die Felder für Leistung und Energie enthalten sind.
Einbindung in FENECON / FEMS Portal
Die Einbindung in FENECON ist bei beiden Varianten identisch.
- Im FENECON Portal im FEMS App Center die App Shelly DIY auswählen.
- Keinen Autodetect verwenden.
- Das Gerät per manueller IP hinzufügen.
- Als Gerätetyp Shelly Plug S Gen3 verwenden.
- Sicherstellen, dass das Gerät im Heimnetz immer dieselbe IP bekommt, zum Beispiel per DHCP-Reservierung.
Der entscheidende Punkt ist die manuelle IP-Einbindung. Autodetect ist in den Emulationen nicht implementiert. Wenn es geklappt hat, sieht es in FEMS so aus:
Was ist der Unterschied zwischen beiden Ansätzen?
Beide Lösungen verfolgen denselben Zweck, aber die Datenquelle ist unterschiedlich.
Bei ESPHome:
- Daten kommen aus Home Assistant
- gut geeignet, wenn die Messwerte dort ohnehin schon vorliegen
- eigene C++ Komponente in ESPHome
Bei Tasmota:
- Daten kommen direkt aus einem Tasmota Energiegerät
- kein zusätzlicher Umweg über Home Assistant nötig
- sehr kompakt über Berry Skripting
Unterm Strich hängt die bessere Variante also stark davon ab, wo die relevanten Leistungs- und Energiewerte bereits vorhanden sind.
Mehrphasige Geräte
Meine Wallbox ist ein dreiphasiges Gerät und kann bis zu 11kW Leistung ziehen. Da Fenecon diese DIY Integration bewusst auf einphasige Geräte limitiert, bleiben zwei Möglichkeiten:
- Man nimmt 3 Emulatoren, meldet 3 Geräte in FEMS an und sendet die Leistung dann auf L1, L2 und L3.
- Aktuell mache ich es mir einfach und nutze nur einen Emulator mit der Shelly DIY App. Die gesamte Leitung wird dann auf einer Phase (bei mir L3) gemeldet. Das scheint problemlos zu sein. Nur wenn man in der Historie im Untermenü Verbrauch auf „phasengenau“ klickt, dann stimmt es nicht. Für die Gesamtstatistik ist das bisher ohne Belang.
(Leider kann man bei einem Emulatorgerät nicht mit mehreren Ports arbeiten. FEMS erlaubt in der Eingabemaske keine Ports – nur Port 80 geht).
Fazit
Es jetzt zwei offene Bastelwege um Verbraucher einzubinden. Meine Wallbox und mein Heizstab erscheinen jetzt in FEMS, sowohl unter den Live Werten als auch in der Historie.
Die Nutzung der Emulatoren für Erzeugungszähler habe ich noch nicht probiert. Es sollte problemlos gehen. In FEMS dann einfach Erzeugungszähler in der Konfiguration wählen (und nicht Verbrauchszähler).