wichtiges UPDATE für controller 7.2.2 im stable

[in2itiv]

Nochmals Danke für die Rückmeldungen, Screenshots der Konfiguration und Fragen.
Vorab noch eine Info zur Netzwerkarchitektur: Alle Teilnehmer meiner "Heim-Solar" Lösung habe ich ins Gast-Netzwerk der Fritzbox eingebunden und untereinander / miteinander gekoppelt. @mcu daher auch die .179 in der IP.

@homoran Die Adapter laufen separat voneinander auf :1883 (mqtt) und :1887 (sonoff). Auch wenn ich mir gewünscht hätte, dass ich nur den mqtt auf :1883 benötigte um Daten einzusammeln.

@skvarel Die teleperiod ist ebenfalls auf 10 eingestellt; weiter runter lässt sich der Wert nicht stellen. Die Konfiguration des sonoff Adapters sieht bei mir identisch aus.

16:52:16.998 RSL: STATUS5 = {"StatusNET":{"Hostname":"stromzaehler-2096","IPAddress":"192.168.179.12","Gateway":"192.168.179.1","Subnetmask":"255.255.255.0","DNSServer1":"192.168.179.1","DNSServer2":"0.0.0.0","Mac":"D4:8A:FC:2E:68:30","Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":17.0}}

16:52:47.574 RSL: STATUS6 = {"StatusMQT":{"MqttHost":"192.168.179.4","MqttPort":1887,"MqttClientMask":"WattWaechter","MqttClient":"WattWaechter","MqttUser":"mqtt-user","MqttCount":0,"MqttTLS":0,"MAX_PACKET_SIZE":1200,"KEEPALIVE":15,"SOCKET_TIMEOUT":20}}

ioBroker Log zum sonoff:

sonoff.0	2026-05-15 17:56:05.019	info	Client [WattWaechter] connection closed: closed
sonoff.0	2026-05-15 17:55:44.775	debug	stateChange sonoff.0.info.connection: {"val":"WattWaechter","ack":true,"ts":1778860544773,"q":0,"from":"system.adapter.sonoff.0","user":"system.user.admin","lc":1778860544773}
sonoff.0	2026-05-15 17:55:44.762	debug	stateChange sonoff.0.info.clients.WattWaechter: {"val":true,"ack":true,"ts":1778860544760,"q":0,"from":"system.adapter.sonoff.0","user":"system.user.admin","lc":1778860544760}
sonoff.0	2026-05-15 17:55:44.713	debug	process task: {"type":"addObject","id":"sonoff.0.WattWaechter.alive","data":{"_id":"sonoff.0.WattWaechter.alive","common":{"type":"boolean","role":"indicator.reachable","read":true,"write":false,"name":"WattWaechter alive"},"type":"state"}}
sonoff.0	2026-05-15 17:55:44.711	debug	process task: {"type":"addObject","id":"sonoff.0.WattWaechter","data":{"_id":"sonoff.0.WattWaechter","common":{"name":"WattWaechter","desc":""},"native":{"clientId":"WattWaechter"},"type":"channel"}}
sonoff.0	2026-05-15 17:55:44.710	info	Client [WattWaechter] connected with secret 1778860544709_4299

Hier noch als Bsp. ein Auszug vom ioBroker mqtt Adapter zu den anderen Teilnehmer..

mqtt.0	2026-05-15 17:59:07.241	debug	stateChange mqtt.0.JKBMS.Current: {"val":5.89,"ack":false,"ts":1778860747238,"q":0,"c":"script.js.Skript2","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1778860747238}
mqtt.0	2026-05-15 17:59:07.198	debug	onStateChange mqtt.0.JKBMS.Power: {"val":159.239,"ack":false,"ts":1778860747195,"q":0,"c":"script.js.Skript2","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1778860747195}
mqtt.0	2026-05-15 17:59:07.197	debug	stateChange mqtt.0.JKBMS.Power: {"val":159.239,"ack":false,"ts":1778860747195,"q":0,"c":"script.js.Skript2","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1778860747195}

und

mqtt.0	2026-05-15 17:59:06.743	debug	stateChange mqtt.0.hm800.114190929759.2.power: {"val":2.8,"ack":true,"ts":1778860746740,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1778860495913}
mqtt.0	2026-05-15 17:59:06.742	debug	stateChange mqtt.0.hm800.114190929759.2.current: {"val":3.62,"ack":true,"ts":1778860746739,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1778860746739}
mqtt.0	2026-05-15 17:59:06.742	debug	stateChange mqtt.0.hm800.114190929759.2.voltage: {"val":0.8,"ack":true,"ts":1778860746738,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1778859455198}

Ich vermute mehr und mehr den Fehler auf seitens Tasmota. Wobei ich hier sowohl mit Version 14.4.1 als auch mit der 15.3.0 keinen erfolgreichen mqtt Datenaustausch realisieren konnte.

[MCU]

@in2itiv sagte:

:1883 (mqtt) und :1887 (sonoff)

Verstehe ich nicht du willst an 1887 sonoff schicken, bekommst aber in mqtt ein log?
Also doch erstmal ein iob diag, wie schon @homoran vorgeschlagen.
Und die Einstellungen von MQTT, SONOFF und Tasmota (MQTT).
Für Sonoff:

[Homoran]

@MCU sagte:

bekommst aber in mqtt ein log?

Aber von

@in2itiv sagte:

den anderen Teilnehmer..

Hat mich auch ziemlich verwirrt

[in2itiv]

iob diag hier: 20260515_iobDiagRaspberryPi4b.txt

oben hatte ich die Logs aus dem ioBroker eingefügt zum jeweiligen Adapter. sonoff zum sonoff und mqtt zu den mqtt Teilnehmern.

mqtt config:

sonoff:

Vielleicht findet ihr Profis hierzu etwas.
Ich bin inzwischen etwas überfragt.

[MCU]

@in2itiv MQTT EInstellung von Tasmota im Gerät fehlt.
Konsolen Befehle:

Status 10
TelePeriod
Sensor53
Script

[crunchip]

@MCU sagte:

im Gerät

ich frag mich die ganze Zeit, was für ein Gerät das überhaupt ist

[MCU]

@crunchip

[in2itiv]

Danke @mcu ! Sorry, die Info hatte ich vergessen zu schreiben. Das ist ein IR-Lesekopf für den Stromzähler, wie abgebildet. https://docs.wattwächter.de/wifi-usb/

22:50:03.087 CMD: Status 10
22:50:03.097 RSL: STATUS10 = {"StatusSNS":{"Time":"2026-05-15T22:50:03","SML":{"Verbrauch_T1":0.2280229,"Verbrauch_T2":10181.4143867,"Energy":10181.6424096,"Einspeisung_Summe":641.1005303,"Watt_L1":23.97,"Watt_L2":167.48,"Watt_L3":187.13,"Power":378.60,"Volt_L1":235.6,"Volt_L2":235.9,"Volt_L3":235.5}}}

22:51:41.840 CMD: Teleperiod
22:51:41.845 RSL: TELEPERIOD = {"TelePeriod":10}

22:52:17.281 CMD: Sensor53
22:52:17.286 RSL: SENSOR = {"Command":"Error","Input":"SENSOR53"}

Sensor53 und Script sind unbekannte Befehle.
Das hinterlegte Skript zum Auslesen der Zählerdaten liefert mir im Webinterface und per HTTP Get die korrekten Sensordaten.

[MCU]

@in2itiv Configuration / MQTT

[in2itiv]

Hier aus dem Tasmota Gerät die mqtt config:

Ich habe auch mit der Standard-Topic %topic% dasselbe Verhalten gehabt.

[MCU]

@in2itiv Konsole

WebLog 4

30 Sekunden warten bis ein Eintrag MQT: tele/<topic>/SENSOR kommt?

Status 10 liefert SML-Werte, also liest der WattWächter den Zähler korrekt.

Auffällig ist aber:
Sensor53 und Script sind unbekannte Befehle. Damit würde ich aktuell nicht weiter mit Sensor53 testen.

Bitte einmal prüfen

Status 2  
Status 4  
Status 6

posten.

Als Trennungstest:

Publish tele/<topic>/SENSOR {"Time":"2026-05-16T00:00:00","SML":{"Power":123.45,"Test":1}}

Wenn dieser manuelle Publish unter sonoff.0 ankommt, ist MQTT/Sonoff grundsätzlich okay und es fehlt nur die automatische SML-Telemetrie.
Wenn er nicht ankommt, liegt das Problem noch vor der SML-Ausgabe.

Konsole, ist Script enabled?

Tools → Edit Script

1. Ist "Script enable" aktiv?
2. Ist überhaupt ein Zähler-Skript eingetragen?
3. Enthält das Skript einen >M-Block?
4. Enthält es im >B-Block typischerweise ->sensor53 r?

Hattest du das gemacht?
https://docs.wattwächter.de/wifi-usb/skripte/

[skvarel]

@in2itiv .. ich würde trotzdem das Topic wieder zurücksetzen, wenn du den Sonoff Adapter nutzt.

EDIT:

Der Sonoff-Adapter arbeitet nicht wie ein völlig „dummer“ MQTT-Broker, sondern erwartet bei Tasmota-Setups oft eine konsistente Struktur aus cmnd, stat und tele rund um das Gerätetopic. Wenn einzelne Geräte andere Topic-Namen oder Sonderzeichen/Muster haben, kann das zu Konflikten, nicht gefundenen Datenpunkten oder inkonsistentem Reconnect-Verhalten führen.

[crunchip]

@skvarel sagte:

ich würde trotzdem das Topic wieder zurücksetzen, wenn du den Sonoff Adapter nutzt.

Ist sogar Pflicht, da gab es ab einer bestimmten Version nen break.

@MCU sagte:

Ist überhaupt ein Zähler-Skript eingetragen?

Deswegen hatte ich nach dem Gerät gefragt

[in2itiv]

Nochmals Danke für die ganzen Rückmeldungen.
die Topic habe ich wieder auf den Default Wert %topic% gesetzt.

11:06:34.203 CMD: Status 2
11:06:34.209 RSL: STATUS2 = {"StatusFWR":{"Version":"15.3.0(tasmota)","BuildDateTime":"2026-04-12T09:58:05","Boot":31,"Core":"2.7.8","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8285H16","CR":"403/699"}}

11:07:00.782 CMD: Status 4
11:07:00.792 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":614,"Free":388,"Heap":16,"ProgramFlashSize":1024,"FlashSize":2048,"FlashChipId":"1540A1","FlashFrequency":40,"FlashMode":"DOUT","Features":["0809","17400582","04080001","00000003","00000000","00000808","00100000","00000000","04000000","00000000","00000000"],"Drivers":"1,2,!4,9,10,11,12,29,62,!68","Sensors":"1,2,53,75"}}

11:07:51.903 CMD: Status 6
11:07:51.909 RSL: STATUS6 = {"StatusMQT":{"MqttHost":"192.168.179.4","MqttPort":1887,"MqttClientMask":"WattWaechter","MqttClient":"WattWaechter","MqttUser":"mqtt-user","MqttCount":0,"MqttTLS":0,"MAX_PACKET_SIZE":1200,"KEEPALIVE":15,"SOCKET_TIMEOUT":20}}

Der manuelle Publishversuch blieb leider erfolglos. Ich erhalte nur in Dauerschleife den rc- 4

11:12:22.764 CMD: Weblog 4
11:12:22.765 SRC: WebConsole from 192.168.179.39
11:12:22.767 CMD: Grp 0, Cmd 'WEBLOG', Idx 1, Len 1, Pld 4, Data '4'
11:12:22.769 RSL: WEBLOG = {"WebLog":4}
11:12:23.618 CFG: Saved to flash at F5, Count 121, Bytes 4096
11:12:25.224 WIF: Sending Gratuitous ARP
11:12:27.788 WIF: Checking connection...
11:12:28.211 RSL: STATE = {"Time":"2026-05-16T11:12:28","Uptime":"0T00:07:04","UptimeSec":424,"Heap":19,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Wifi":{"AP":1,"SSId":"fbxGuest","BSSId":"E2:08:55:24:CF:D7","Channel":6,"Mode":"11n","RSSI":100,"Signal":-25,"LinkCount":1,"Downtime":"0T00:00:03"},"Hostname":"xtopic--2096","IPAddress":"192.168.179.12"}
11:12:28.217 RSL: SENSOR = {"Time":"2026-05-16T11:12:28","SML":{"Verbrauch_T1":0.2280229,"Verbrauch_T2":10183.0796572,"Energy":10183.3076801,"Einspeisung_Summe":641.1014878,"Watt_L1":33.07,"Watt_L2":-12.83,"Watt_L3":27.16,"Power":47.79,"Volt_L1":236.3,"Volt_L2":235.3,"Volt_L3":235.1}}
11:12:31.614 HTP: Command
11:12:31.617 SRC: WebCommand from 192.168.179.2
11:12:31.619 CMD: Grp 0, Cmd 'STATUS', Idx 1, Len 1, Pld 8, Data '8'
11:12:31.626 RSL: STATUS8 = {"StatusSNS":{"Time":"2026-05-16T11:12:31","SML":{"Verbrauch_T1":0.2280229,"Verbrauch_T2":10183.0796974,"Energy":10183.3077204,"Einspeisung_Summe":641.1014878,"Watt_L1":33.87,"Watt_L2":-12.03,"Watt_L3":27.17,"Power":49.01,"Volt_L1":236.2,"Volt_L2":235.7,"Volt_L3":235.0}}}
11:12:36.034 MQT: Attempting connection...
11:12:36.035 WIF: DNS resolved '192.168.179.4' (192.168.179.4) in 0 ms
11:12:56.357 MQT: Connect failed to 192.168.179.4:1887, rc -4. Retry in 80 sec
11:12:56.413 HTP: Command
11:12:56.416 SRC: WebCommand from 192.168.179.2
11:12:56.418 CMD: Grp 0, Cmd 'STATUS', Idx 1, Len 1, Pld 8, Data '8'
11:12:56.424 RSL: STATUS8 = {"StatusSNS":{"Time":"2026-05-16T11:12:56","SML":{"Verbrauch_T1":0.2280229,"Verbrauch_T2":10183.0800402,"Energy":10183.3077742,"Einspeisung_Summe":641.1014878,"Watt_L1":33.30,"Watt_L2":-12.85,"Watt_L3":27.34,"Power":47.79,"Volt_L1":235.3,"Volt_L2":235.1,"Volt_L3":235.7}}}
11:12:56.462 HTP: Command
11:12:56.465 SRC: WebCommand from 192.168.179.2
11:12:56.467 CMD: Grp 0, Cmd 'STATUS', Idx 1, Len 1, Pld 8, Data '8'

Skript ist "enabled". Nach meinem Verständnis würde ich ohne aktives Skript auch keine Werte über das Webinterface angezeigt bekommen, bz.über Status8 ausgeben.

[crunchip]

@in2itiv ich hab den ganzen Text mal zusammenkopiert
Der WattWächter sendet die SML-Daten nicht automatisch per MQTT, weil das Gerät ein eigenes Tasmota-Build ohne Sensor53-Unterstützung verwendet – und das Script vermutlich das automatische Publisieren nicht triggert. Es gibt zwei funktionierende Wege:
Weg 1: Tasmota-Script korrigieren (empfohlen)
Der WattWächter sendet Telemetrie-Daten nur dann per MQTT, wenn das Script korrekt konfiguriert ist. � Unter Tools → Edit Script muss folgendes Script aktiv sein: �

D
B
->sensor53 r
M 1
+1,3,s,16,9600,ED300L,1
1,77070100010800ff@1000,Netzbezug,kWh,Bezug,3
1,77070100020800ff@1000,Einspeisung,kWh,Einspeisung,3
1,77070100100700ff@1,akt. Leistung,W,Leistung,0

Da Sensor53 auf diesem Gerät jedoch ein unbekannter Befehl ist, funktioniert ->sensor53 r möglicherweise nicht. Stattdessen gibt es aber einen Trick für Echtzeit-Updates bei jeder Wertänderung: Die letzte Zahl in der Zeile (Nachkommastellen) um +16 erhöhen, z.B.: �
1,77070100100700ff@1,akt. Leistung,W,Leistung,16
Damit werden die Daten unabhängig von TelePeriod bei jeder Änderung gesendet. �
Weg 2: Auf Port 1883 (mqtt-Adapter) wechseln
Da der mqtt.0-Adapter auf :1883 bereits läuft und andere Geräte (openDTU, JK BMS) dort problemlos Daten liefern, ist der einfachste Fix:
Im WattWächter unter Configuration → MQTT den Port von 1887 auf 1883 ändern
Den Sonoff-Adapter für dieses Gerät weglassen
Die Daten kommen dann unter mqtt.0.tele.WattWaechter.SENSOR als JSON an
Per JavaScript-Adapter oder Alias die einzelnen SML-Werte (Power, Volt_L1 etc.) auslesen
Warum rc -4 entsteht
Der rc -4-Fehler in Tasmota bedeutet "Connection refused – bad username or password" � – das heißt, der Sonoff-Adapter auf :1887 lehnt die Credentials (mqtt-user) ab oder erwartet andere. Im mqtt.0-Adapter auf :1883 sind die Zugangsdaten bereits für andere Geräte konfiguriert und funktionieren.
Empfehlung: Direkt auf Port 1883 wechseln und den mqtt-Adapter nutzen – das ist der sauberere Weg und vermeidet das Portchaos zwischen 1883 und 1887.

Edit
rc -4 ist also ein Timeout, d.h. das Gerät erreicht den Broker entweder gar nicht oder der Broker antwortet nicht innerhalb der Zeitgrenze. � Das ist kein Credentials-Problem – das wäre rc 4 (positiv, ohne Minus!). �
Es kann sich auch um einen Tasmota-Bug in v12.0 handeln, der in v12.0.2 gefixt wurde.

[Shadowhunter23]

@skvarel sagte:

FYI

Das kann man im Script sogar noch schneller machen, als Beispiel:

1,77070100100700ff@1,akt. Leistung,W,Power,16

16 = sofortige Übertragung, 0 Nachkommastellen
18 = sofortige Übertragung, 2 Nachkommastellen

Allerdings muss man dann den übertragenen Wert per Script abfragen da das Topic nicht mehr als gesamte Zeile an mqtt gesendet wird. Wenn man es braucht oder möchte hat man keine Verzögerung.

[MCU]

@in2itiv Die client zu client Verbindung in der FritzBox ist freigeschaltet?
Nicht Sensor53, sondern sensor53

sensor53 d0

Auf der Server Console

nc -vz 127.0.0.1 1887
nc -vz 192.168.179.4 1887

Auf einem Windows Gerät innnerhalb vom Netz 192.168.179.X PowerShell(Admin)

tnc 192.168.179.4 -Port 1887

@chrunchip Im mqtt.0-Adapter auf :1883 sind die Zugangsdaten bereits für andere Geräte konfiguriert und funktionieren.

MQTT und SONOFF sind mit keinem Gerät verbunden, beide sind gelb

[in2itiv]

Die Clients im Gast-Netzwerk der FritzBox dürfen miteinander kommunizieren.

Bzgl. des Test der TCP connection:

raspberry@Raspi4b:~ $ nc -vz 127.0.0.1 1887
Connection to 127.0.0.1 1887 port [tcp/*] succeeded!
raspberry@Raspi4b:~ $ nc -vz 192.168.179.4 1887
Connection to 192.168.179.4 1887 port [tcp/*] succeeded!

Der MQTT Adapter ist mit mehreren Geräten verbunden und kommuniziert / tauscht Daten aus. Den Sonoff-Adapter habe ich gerade testweise deaktiviert (erst nach dem Test der TCP Verbindung).

sensor53 bleibt ein unbekanntes Kommando.

Edit: Nächste Woche möchte ich noch das Verhalten im "normalen" Netzwerk testen.. Vielleicht liegt es an den (wenig dokumentierten) Eigenheiten des Fritz Gastnetzwerks.

[MCU]

@in2itiv
Passwort hast du mal vereinfacht auf 1234 gesetzt im sonoff, nur um zu testen, anderen User sonoff?

Hast du mal den Port auf 1883 gesetzt ( @crunchip ) in Tasmota, sonoff deaktiviert?

[in2itiv]

Nachdem ich jetzt sowohl den Raspberry mit dem MQTT Server, als auch den Tasmota Lesekopf ins Heimnetz umgezogen habe, kann ich selbst ohne sonoff Adapter die Werte per MQTT auslesen. Und nach Einbindung der openDTU (on Battery) ebenfalls ins Heimnetz, werden hier ebenfalls alle Werte zuverlässig per MQTT übertragen bzw. angezeigt.

Ich folgere daraus, dass der Fehler im Gastzugang der Fritzbox liegt bzw. dessen Nutzung zur instabilen MQTT Verbindung führte. Ich möchte noch kein vorschnelles "Heureka" rufen, jedoch scheint aktuell alles so zu laufen wie es soll.

Ich danke allen Beteiligten für Eure Zeit und Geduld bei der Fehlersuche und die freundliche Kommunikation!