Nach Mosquitto-update nur noch ein Wert von 6 am Stromzähler verfügbar

[HelmutS]

Um meinen Stromzähler eBz DD3 ... SMZ1 an Openhab anzubinden nutze ich seit ca. 3 Jahren einen IR-Lesekopf (Bitshake), der an ein WT32-ETH01 angeschlossen ist. Auf dem WT32-ETH01 läuft Tasmota 12.4. Tasmota überträgt die Daten an einen Mosquitto-Server. Dort holt Openhab sie dann ab. Das hat bis Mitte Mai 2025 super funktioniert. Dann wurden plötzlich vom Stronzähler die Werte Energie Bezug, Energie Export, Leistung, Leistung L1 und Leistung L2 nicht mehr übertragen. Nur der Wert Leistung L3 wird aktualisiert.
Im Tasmota Hauptmenü erfolgt die Aktualisierung der Werte nach wie vor. Laut Console werden die Werte auch an MQTT übermittelt. Am Mosquitto-Server kommt aber nur noch der letzte Wert Leistung L3 an.
Wenn ich im Tasmota-Script die Zeile für die Anzeige von Leistung L3 auskommentiere, dann wird Leistung L2 an den MQTT-Server übertragen. Wenn ich alles, außer dem Wert Energie Bezug auskommentiere, dann wird der Wert Energie Bezug übertragen.
Wenn ich mich richtig erinnere, dann wurden die Messwerte damals alle in einer Zeile übertragen. Zumindest kamen sie am Mosquitto-Server so an. Laut Console gibt es jetzt für jeden Wert eine Zeile. Nur die letzte Zeile jedes Übertragungspakets finde ich im MQTT-Explorer unter SENSOR wieder.
Der Fehler ist vermutlich nach einem automatischen Update von Mosquitto aufgetreten.

Openhab und Mosquitto laufen bei mir als Podman-Container, die sich automatisch updaten. Mir ist der Fehler erst aufgefallen, weil ich plötzlich keinen Verbrauch mehr hatte.
Inzwischen habe ich Tasmota am WT32-ETH01 auf 15.01 upgedatet, einen neuen Mosquitto-Server zum Testen eingerichtet und diverse Veränderungen am Script ausprobiert. Leider alles ohne Erfolg! Was hat sich seit meiner Erstinbetriebnahme an Mosquitto geändert?
Bin für jeden Tipp dankbar!

Mit freundlichen Grüßen
Helmut

[peter-pan]

Ich habe einen einfachen Stromzähler mit einem Hichi-Smartmeter verbunden. Ich habe die Tasmota-Version 15.0.1 laufen.

Die Web-UI gibt mir folgenden Konsolen-Wert aus:

Code: Alles auswählen

23:42:55.937 MQT: tele/smartmeter/SENSOR = {"Time":"2025-08-21T23:42:55","Strom":{"Meter_Number":"0a01495452000350652c","Total_in":8971.0000,"Power_curr":0,"Total_out":0.0000}}

Über MQTT.fx (mein Explorer) sehe dass folgender JSON-String im Broker ankommt:

Code: Alles auswählen

 {"Time":"2025-08-21T23:42:25","Strom":{"Meter_Number":"0a01495452000350652c","Total_in":8971.0000,"Power_curr":0,"Total_out":0.0000}}

Die Auflösung in Einzelwerte erfolgt in OH5 durch Auflösung des JSON-Strings in Einzelwerte:

.things

Code: Alles auswählen

    Thing mqtt:topic:danny:smame01 "Hichi Smartmeter 01"  (mqtt:broker:danny )     @ "MQTT2" [
         availabilityTopic="tele/smartmeter/LWT",
         payloadNotAvailable="Offline",
         payloadAvailable= "Online"
         ]
    {
    Channels:
        Type number : rssi        "WiFi Signal Strength"     [ stateTopic="tele/smartmeter/STATE", transformationPattern="JSONPATH:$.Wifi.RSSI"]
        Type string : version     "Firmware Version"         [ stateTopic="stat/smartmeter/STATUS2", transformationPattern="JSONPATH:$.StatusFWR.Version"]
        Type switch:  reachable   "Reachable"                [ stateTopic="tele/smartmeter/LWT", on="Online", off="Offline" ]
        Type string : hardware    "Chip Set            "     [ stateTopic="stat/smartmeter/STATUS2", transformationPattern="JSONPATH:$.StatusFWR.Hardware"]
        Type string : ipaddress   "IP Address          "     [ stateTopic="stat/smartmeter/STATUS5", transformationPattern="JSONPATH:$.StatusNET.IPAddress"]
        Type string : ssid        "WiFi"                     [ stateTopic="tele/smartmeter/STATE",   transformationPattern="JSONPATH:$.Wifi.SSId"]
        Type string : grouptop    "Group Topic"              [ stateTopic="stat/smartmeter/STATUS1", transformationPattern="JSONPATH:$.StatusPRM.GroupTopic"]
        Type string : serviceid   "Zähler Nr"                [ stateTopic="tele/smartmeter/SENSOR",  transformationPattern="JSONPATH:$.Strom.Meter_Number"]
        Type number : total_in    "Gesamtverbrauch"          [ stateTopic="tele/smartmeter/SENSOR",  transformationPattern="JSONPATH:$.Strom.Total_in", unit="kWh"]
        Type number : power_curr  "Leistung"                 [ stateTopic="tele/smartmeter/SENSOR",  transformationPattern="JSONPATH:$.Strom.Power_curr", unit="W"]
        Type number : total_out   "Erzeugung"                [ stateTopic="tele/smartmeter/SENSOR",  transformationPattern="JSONPATH:$.Strom.Total_out", unit="kWh"]
        Type datetime : time      "Zeit"                     [ stateTopic="tele/smartmeter/STATE",   transformationPattern="JSONPATH:$.Time"]
 

    }

Wie sieht denn deine Web-UI-Konsolenausgabe aus ?

[peter-pan]

Noch eine Frage !

Hast du dir deine Tasmota-Version selbst kompiliert oder hast du die Standard-Version aufgespielt ?

hauptmenue.jpg

[HelmutS]

Hallo Peter-Pan,
ich habe Tasmota kompilieren müssen, weil ich ja SML für meinen Stromzähler aktivieren musste und auch die Funktionionalität für das WT32-ETH01-Board sonst nicht vorhanden wäre. Ich benötige den LAN-Anschluss, weil ich in einem Mehrfamilienhaus wohne und im Keller weder WLAN noch Mobilfunkversorgung vorhanden ist. Deshalb habe ich mir einen LAN-Anschluss über Power-LAN eingerichtet. Das funktioniert erstaunlich gut.

Bis der Fehler aufgetreten ist, sah mein Eintrag für den Stromzähler im MQTT-Explorer so aus:

Code: Alles auswählen

SENSOR = {"Time":"2022-05-18T17:06:04","SML":{"1_8_0":5521.096475,"2_8_0":223.163507,"16_7_0":164,"36_7_0":85,"56_7_0":68,"76_7_0":6}}

Jetzt sieht es so aus:

Code: Alles auswählen

SENSOR = {"Time":"2025-08-21T22:09:08","SML":{"76_7_0":10.10}}

Auf der Tasmota-Console sieht die Ausgabe für jedes Messintervall so aus:

12:20:04.961 MQT: ebz/STATE = {"Time":"2025-08-22T12:20:04","Uptime":"0T20:02:30","UptimeSec":72150,"Heap":146,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":38}}
12:20:04.968 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:04","SML":{"1_8_0":5523.69606024,"2_8_0":223.16391533,"16_7_0":138.54,"36_7_0":72.12,"56_7_0":59.64,"76_7_0":6.78,"96_1_0":"090145425a01001ddb61"}}
12:20:05.658 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:05","SML":{"16_7_0":137.47}}
12:20:05.662 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:05","SML":{"36_7_0":71.86}}
12:20:05.707 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:05","SML":{"56_7_0":59.66}}
12:20:05.711 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:05","SML":{"76_7_0":5.95}}
12:20:06.658 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:06","SML":{"16_7_0":137.34}}
12:20:06.662 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:06","SML":{"36_7_0":70.96}}
12:20:06.707 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:06","SML":{"56_7_0":60.13}}
12:20:06.711 MQT: ebz/SENSOR = {"Time":"2025-08-22T12:20:06","SML":{"76_7_0":6.25}}

Eigentlich wäre die Übertragung der ersten fett gedruckten Zeile vollkommen ausreichend. Warum die anderen Zeilen mit den einzelen Werten nochmal übermittelt werden erschließt sich mir nicht. Laut MQTT-Explorer kommt auch nur die letzte Zeile an. Mein Tasmota Haupt-Menü sieht so aus:

[peter-pan]

So aus dem Stand habe ich da auch keine Lösung. Es könnte evtl. am Konsol-Skript liegen, oder evtl. auch an möglichen Änderungen im Programm-Code selbst.

Was ich aber sehe ist, das der erste JSON-String etwas anders aussieht, als die anderen.

Code: Alles auswählen

 {"Time":"2025-08-22T12:20:04","SML":{"1_8_0":5523.69606024,"2_8_0":223.16391533,"16_7_0":138.54,"36_7_0":72.12,"56_7_0":59.64,"76_7_0":6.78,"96_1_0":"090145425a01001ddb61"}}

Vielleicht lässt sich daraus etwas extrahieren. Möglich wäre evtl. die Werte

1. 1_8_0
2. 090145425a01001ddb61

Wie das genau geht, müsste ich wahrscheinlich erst mühsam "erarbeiten". Aber vielleicht kann ja @udo1toni Hilfstellung leisten. Da habe ich schon einiges an Hilfe bekommen.
Ein ähnliches Beispiel könnte vielleicht so aussehen:
transformationPattern="REGEX:(.*DC:0D:30:16:CF:1A.*)∩JSONPATH:$..[?(@.id=='DC:0D:30:16:CF:1A')].rssi"

Das ist aber nur ein Ansatz. Wie das genau mit dem Regex und den JSONPATH-Parametern ist weiss ich leider auch nicht.

Wenn allerdings nur die letzte Konsol-Zeile an den Broker geschickt werden sollte, ist das natürlich obsolet. Das ist aber eigentlich nicht möglich (oder doch ??! )

[Harka]

Moin,
wenn Du JavaScript Scripting installiert hast und mindestens OH 4 nutzt, kannst Du auch mal dies bei transformationPattern probieren

Code: Alles auswählen

JS:|var data = JSON.parse(input); data?.SML?.["96_1_0"] !== undefined ? data.SML["1_8_0"] : undefined;
JS:|var data = JSON.parse(input); data?.SML?.["1_8_0"] !== undefined ? data.SML["1_8_0"] : undefined;

Das erste liest nur wenn die ServerID dabei ist und das zweite auch die Zwischenwerte.
Das letzte undefined kann auch gegen null getausch werden. Bei mir funktioniert es mit beiden Varianten.

[udo1toni]

Wenn Du mit dem mqtt Explorer das Sensor-Topic anschaust, sollte es eine Historie geben. In dieser Historie sollte jeweils auch die vollständige Zeile (also mit allen Messwerten in einem JSON) gelistet werden. Dass Du diese "nie" im Sensor-Topic siehst, liegt eventuell einfach daran, dass das Topic so schnell aktualisiert wird.
Sollte das Topic zwischendrin korrekt in mosquitto landen (und entsprechend auch an openHAB übertragen werden), müsstest Du lediglich die falschen Zeilen herausfiltern, z.B. indem Du per REGEX auf 1_8_0 filterst REGEX:(.*1_8_0.*) Also nur solche Nachrichten werden durchgereicht, die auch diese Zeichenkette enthalten. Anschließend kannst Du dann wie gewohnt die Einzelwerte per JSONPATH abgreifen, einfach beide Transformations verketten.

Falls das Topic nie in Mosquitto ankommt, hat Mosquitto ein grundsätzliches Problem, das deutet dann darauf hin, dass der Container zu langsam ist, um die schnelle Abfolge von Nachrichten zu verarbeiten. Allerdings kann ich mir das nicht so recht vorstellen, mosquitto kann selbst auf "oller" Hardware locker dutzende oder gar hunderte Nachrichten pro Sekunde verarbeiten.

[HelmutS]

Vielen Dank für Eure Antworten!
Es ist tatsächlich so, dass die vollständige Zeile in längeren Abständen ebenfalls übertragen wird. Ich habe die Zeile in der History gefunden. Jetzt muss ich mich mal darum kümmern, wie ich den Stromzähler wieder in Openhab einrichte. So einfach, wie damals scheint das nicht mehr zu sein.
Aus meinen Aufzeichnungen geht hervor, dass ich in Tasmota einfach die Homeassistantfunktion mit

Code: Alles auswählen

#define USE_HOME_ASSISTANT

eingebracht habe und dann an der Tasmota-Console mit

Code: Alles auswählen

SetOption19 1

aktiviert habe. Dann tauchte der Stromzähler in Openhab in der Inbox auf und ich konnte ihn als Thing einrichten und die 6 Channel als Items aktivieren. So einfach geht es wohl nicht mehr.
Ich habe auch bereits mehre Tasmota-Steckdosen in Openhab eingerichtet. Die Items habe ich auch manuell eingerichtet. Jetzt muss ich mich erstmal wieder mit der Openhab-Doku beschäfftigen und nachvollziehen, wie ich das vor 3 Jahren gemacht habe. Dann werde ich hoffentlich auch den Tipp mit REGEX von udo1toni ausprobieren können.

[udo1toni]

Dann tauchte der Stromzähler in Openhab in der Inbox auf und ich konnte ihn als Thing einrichten und die 6 Channel als Items aktivieren. So einfach geht es wohl nicht mehr.

Oh. Doch, das sollte nach wie vor funktionieren. Mutmaßlich ist das auch des Rätsels Lösung, der Zähler hat das "schon immer" so gemacht, und da Du über die HA-Automatik gegangen bist, hat sich das Binding selbst darum gekümmert.
Das Stichwort lautet hier Autodiscovery. Schau mal im MQTT Explorer nach, ob es im Zweig homeassistant einen Eintrag für Deinen Zähler gibt (mutmaßlich unterhalb sensor...). Falls das nicht der Fall ist, wäre es einen Versuch wert, SetOption19 auf 0 zu setzen, den Adapter neu zu starten und erneut auf 1 zu setzen.
Weiterhin könntest Du versuchen, einen vorhandenen Eintrag unterhalb des homeassistant Topics zu löschen (Eintrag auswählen und rechts oben im Topic-Bereich den Mülleimer anklicken).
Es kann auch sein, dass openHAB den Eintrag ignoriert, weil er in der Autodiscovery entsprechend markiert ist (Main UI->Administration->Einstellungen->Things->Inbox->Show ignored)
Allerschlimmstenfalls ist tatsächlich momentan irgendwas im Code kaputt, weshalb die Autodiscovery nicht funktioniert, dann musst Du tatsächlich über den beschriebenen Umweg gehen und das Thing manuell anlegen.

[HelmutS]

SetOption19 auf 0 zu setzen, den Adapter neu zu starten und erneut auf 1 zu setzen.

Genau das wollte ich nochmal ausprobieren. Jetzt meldet sich der Adapter (WT32-ETH01) nicht mehr. Das Ding ist nicht mehr über die LAN-Buchse erreichbar. Da ich WLAN über die Console, aus Sicherheitsgründen, ausgeschaltet habe, hilft nur neu flashen!
Das ist in einem Mehrfamilienhaus, in dem nicht jeder Zugang zum Heizungskeller hat, etwas aufwendig. Da ist jetzt der Hausmeister gefragt.