Neues YouTube-Video: Visualisierung im Devices-Adapter

[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!

[skvarel]

@in2itiv .. der Sonoff Adapter hat den Vorteil, das er dir alle Daten als einzelne Datenpunkte zur Verfügung stellt. Bein mqtt Adapter wirst du die json erst 'zerpflücken' müssen.

[in2itiv]

@skvarel Danke für den Hinweis. Das hatte ich bisher noch nicht gesehen. Ein Grund, es in den nächsten Tagen dann noch testen. Aktuell extrahiere ich die Werte über ein Skript - was für meine Zwecke im Moment genügt. Einzelne Werte sind natürlich deutlich komfortabler!

[skvarel]

@in2itiv .. das hier ist jetzt nur mal meine Messsteckdose mit Tasmota

Es passten nicht alle Datenpunkte auf den Screenshot ;)

[in2itiv]

@skvarel Ich habs' bei mir auch gerade mal noch getestet, weil die Neugier größer ist, als der Wunsch nach einem stabilen System

Nach all der negativen Erfahrung bisher mit dem Tasmota Gerät und dem Sonoff adapter bin ich jetzt wirklich positiv überrascht.

Jetzt müsste ich diese Werte lediglich noch ins 0.mqtt.xxx mappen, damit sie über diesen Adapter mit veröffentlicht werden. Praktisch. - Danke!

[skvarel]

@in2itiv .. ich spiele mittlerweile seit rund 8 Jahren mit Tasmota und dem SONOFF Adpater, der eigentlich Tasmota Adapter heißen müsste ;)

Das kommt noch aus den Anfängen als es Tasmota nur für SONOFF gab. Mittlerweile kann man ja Tasmota auf jeden ESP spielen.

[crunchip]

@in2itiv sagte:

Der ioBroker läuft auf einem Raspberry 4b in der aktuellen Software-Version und sammelt bereits Daten von anderen Sensoren im Netzwerk über den MQTT Adapter.

@in2itiv sagte:

Der MQTT Adapter ist mit mehreren Geräten verbunden und kommuniziert / tauscht Daten aus.

und jetzt

@in2itiv sagte:

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.

verstehe ich nicht ganz, aber egal, wenns nun läuft