SML über MQTT und Ethernet

[Stromzähler]

Auch in unserer Straße wurden inzwischen vom Energieversorger die sog. "Intelligenten Messeinrichtungen" installiert, mit denen man über eine Infrarot-Schnittstelle die Zählerstände auslesen kann. Die Geräte sind vom Typ Itron OpenWay 3.HZ-AC-D1-A1.

Jetzt sollte ich bei den üblichen Kopplungen meinen FHEM-Server neben den Zähler stellen, damit dort der IR-Lesekopf (z.B. per USB) eingesteckt werden kann. Das passt mir aber wegen der im Raspberry noch eingesteckten Funkmodule (CUL etc.) nicht. Die wären dann ungünstig platziert. Ein LAN-Kabel liegt aber in der Nähe des Zählers. Man könnte also eine weitere Fhem-Instanz auf einem zweiten RPI installieren. Aber nur extra dafür?

Das Problem ist ja nicht neu und so habe ich schnell einen Arduino-Sketch gefunden, der den SML-Stream nicht byteweise in's Ethernet weiterleitet, sondern zuerst zu einem kompletten, syntaktisch richtigen "SML-File" zusammensetzt. Was im Sketch noch fehlte, waren ein CRC (damit kein"Müll" verschickt wird) und die anschließende Publikation per MQTT. Durch MQTT ist diese Lösung auch nicht FHEM-spezifisch und kann von mehreren "Abonnenten" erhalten werden. Zum Erhalt der Zählerwerte des Zählers muss dieses File allerdings noch "zerlegt" werden. In späteren Versionen ist es denkbar, dass diese gleich die Zählerwerte senden.

Das Ganze passt derzeit nur zu einem spontan sendenden Zähler. Die SML-Files werden zyklisch publiziert. Die Zyklusdauer kann vom MQTT-Broker geändert werden. Ebenso ist ein sofortiger Abruf realisiert, wenn man Zwischenwerte haben will. Der Aufbau der "Schaltung" ist im Sketch beschrieben sowie im anhängenden PNG. Man sollte also ein paar Drähte anlöten können

Das dazu passende MQTT2 Device wäre in FHEM etwa so zu definieren.

Code Auswählen Erweitern

defmod ItronOpenWay MQTT2_DEVICE
attr ItronOpenWay IODev MQTT2_Server
attr ItronOpenWay autocreate 0
attr ItronOpenWay devicetopic Sensoren/ItronOpenWay
attr ItronOpenWay event-on-update-reading SmlFile
attr ItronOpenWay icon mqtt_device
attr ItronOpenWay readingList $DEVICETOPIC/SmlFile:.+ SmlFile\
$DEVICETOPIC/Intervall:.+ Intervall\
$DEVICETOPIC/Information:.+ Info
attr ItronOpenWay setList interval:selectnumbers,5,5,90,0,lin $DEVICETOPIC/Intervall:r\
command:select,read $DEVICETOPIC/Command

Das angehängte File enthält den Sketch für einen WeMos D1 mini bei analog angeschlossener Fotodiode BPW40 und einem 1kOhm Widerstand. Diese Lösung kostet im günstigen Fall keine 7 Euro. Man kann also nicht viel "in den Sand setzen". Der Zugang zum Ethernet geschieht per WLAN. Eine LAN-Lösung für einen Arduino Uno gibt es inzwischen auch.

EDIT 9/2022: Sketch-Datei gelöscht. Nach weiteren, eigenen Verbrauchsmessungen habe ich doch wieder einen RPI2 im Einsatz. Der ist ähnlich sparsam und natürlich flexibler.

[gvzdus]

Moin, ich sehe mich nicht als "Gott der FHEM-Entwicklung", aber *eigentlich* sollte das Ganze ja simpel in FHEM im 47_OBIS-Modul erweiterbar sein.

Skizze:
- ein eingehendes MQTT-"SmlFile"-Reading wird per notify als Event an 47_OBIS geschickt.
- 47_OBIS implementiert die X_Notify-Funktion und reagiert damit auf das Reading. Wenn Du in den Source von 47_OBIS guckst, dann findest Du die Definition

Code Auswählen Erweitern

sub OBIS_Read
die eigentlich nur an

Code Auswählen Erweitern

OBIS_Parse
weiterleitet. Zusammen mit der API-Doku von

Code Auswählen Erweitern

https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify
sollte das eigentlich flott gehen.

Angebot:
Wenn Du mir ein "Kommandozeilenbeispiel" schickst, wie ich mit "mosquitto_pub" das Gleiche einspeisen kann, was von Deinem Arduino-Sketch gesendet wird, dann kann ich auch mal gucken, ob ich das in meine OBIS-Modul-Variante einbauen kann. Ich finde, die Welt braucht nicht noch einen SML-Parser

[gvzdus]

So, wie folgt kriege ich Deinen Kram dekodiert:

Code Auswählen Erweitern


define testzaehler OBIS none

define smlfilereader MQTT2_DEVICE
attr smlfilereader readingList Sensoren/ItronOpenWay/SmlFile:.* smlfile
attr smlfilereader IODev MQTT2_FHEM_Server

define smlreadertransfer notify smlfilereader:smlfile.* setreading testzaehler smlfile $EVTPART1


(Bin für jede Kritik, wie dämlich und durch die Brust ins Auge das so aufgesetzt ist, offen).

Anbei das OBIS-Modul, dass ich noch ganz dreckig angepasst habe (klinkt sich in den kompletten Notify-Strom rein, lauscht auf fest kodiert auf "smlfile"-Reading (Zeile 322). Und weil Deine CRC-Berechnung inkompatibel oder falsch ist, habe ich sie in Zeile 352 auskommentiert. (war mein Fehler)

[gvzdus]

Widerruf!!
Mein Fehler - ich hatte an den Daten rumgespielt. Die CRC-Berechnung kann drin bleiben... Ich lade jetzt aber keine angepasste Version nochmal hoch, bevor die Lösung nicht "hübsch" ist.