Tasmota-Clients werden im IOBroker disconnected

[crunchip]

@ralla66 richtig, soweit ich das nun verfolgt habe, das Gerät zu dieser Zeit alive=false
ich werde das mal beobachten und den DP mitloggen

[Ralla66]

@crunchip

wobei false ja auch eine Falschinformation sein kann.
Im Router nachschauen oder mit Wireshark mitschneiden

[crunchip]

@ralla66 im Router sind und bleiben sie verbunden, genauso sehe ich es in Tasmo Admin....seit x Tagen verbunden, nur eben soweit ich es sehen konnte, der alive auf false ging und entsprechend scheinbar telePeriod nicht greift, sprich keine Daten übertragen werden.
man sieht auch in den Objekten, Zeitstempel und letzte Änderung, das da nichts mehr übertragen wurde

[Ralla66]

@crunchip

dann halten wir fest, Geräte sind Online senden aber keine Daten.
Dann schau was die Console sagt, da muß ja was drinstehen.
Am besten ein Mitschnitt machen.
Zeitstempel und letzte Änderung oder Watt sind ja Angezeigete Werte die ja durchaus
gesendet werden konnten. Falsche Anzeige ? Deswegen der Log der Console.

[crunchip]

@ralla66 ich habe/wollte gerade den ein oder anderen DP in der History aktivieren, bekam folgedessen nun einiges im Log, hab das mal zusammen gefasst

2021-10-30 10:59:58.753 - warn: sonoff.0 (30147) Client [Brunnen] Received puback for unknown message ID: 8762
2021-10-30 10:59:58.758 - warn: sonoff.0 (30147) Client [Brunnen] Received pubcomp for unknown message ID: 50434

2021-10-30 11:02:13.897 - warn: sonoff.0 (30147) Empty packet received: undefined
2021-10-30 11:05:55.034 - info: history.0 (6471) enabled logging of sonoff.0.PC-Server.alive, Alias=false

2021-10-30 11:07:36.539 - warn: sonoff.0 (30147) Cannot parse data "STATE": _{"Time":"2021-10-30T11:07:25","Uptime":"37T16:29:27","UptimeSec":3256167,"Heap":17,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":14,"POWER":"OFF","Wifi":{"AP":1,"SSId":"VIRUSNoT","BSSId":"22:E8:29:17:2C:6A","Channe0�stat/tasmota/STATUS{"Status":{"Module":1,"DeviceName":"Tablet-_ - SyntaxError: Unexpected token  in JSON at position 228
2021-10-30 11:07:36.541 - warn: sonoff.0 (30147) Client [Tablet-Steckdose] Received puback for unknown message ID: 29547
2021-10-30 11:07:36.629 - warn: sonoff.0 (30147) Empty packet received: undefined

2021-10-30 11:08:25.703 - info: history.0 (6471) enabled logging of sonoff.0.Brunnen.alive, Alias=false

2021-10-30 11:09:23.318 - warn: sonoff.0 (30147) Client [Kuehlschrank] Received pubcomp for unknown message ID: 28516
2021-10-30 11:09:23.319 - warn: sonoff.0 (30147) Client [Kuehlschrank] Received puback for unknown message ID: 8762
2021-10-30 11:09:25.111 - warn: sonoff.0 (30147) Client [Waschmaschine] Received pubcomp for unknown message ID: 28005

2021-10-30 11:10:55.027 - warn: sonoff.0 (30147) Empty packet received: undefined
2021-10-30 11:10:55.028 - warn: sonoff.0 (30147) Empty packet received: undefined

bekomme auch ein data is empty in TasmoAdmin angezeigt, wenn ich mit der Maus drüber fahre

[Ralla66]

@crunchip

in der Tasmota Console steht den was zu der Zeit ?
Da erkennt der Adapter ja die message ID nicht.
Gerät mal im Sonoff Adapter löschen und neu suchen lassen.
Du gehst immer von Daten aus die auch Falsch sein können, die Tasmota Console ist besser.

[crunchip]

@ralla66 sagte in Tasmota-Clients werden im IOBroker disconnected:

Gerät mal im Sonoff Adapter löschen und neu suchen lassen.

gaaaaaaaaaaaanz schlechte Idee das is ne Menge Arbeit wieder alles einzustellen

@ralla66 sagte in Tasmota-Clients werden im IOBroker disconnected:

Du gehst immer von Daten aus die auch Falsch sein können, die Tasmota Console ist besser.

ich guck mir das später mal genauer an

[Ralla66]

@crunchip

einer zum Test, Fehler erkennen, dann Wege suchen

[Ulli1]

@crunchip hast du das gleiche Problem wie Ich? Im übrigen: 1885 umstellen hat nichts verändert.

[crunchip]

@ulli1 sagte in Tasmota-Clients werden im IOBroker disconnected:

hast du das gleiche Problem wie Ich

möglicherweise

ich hab jetzt mal mein Unifi upgedatet, die einzelnen Geräte neu gestartet, das logging für ein paar aktiviert und nun mal beobachten.
Ne Vermutung wäre noch...ein Netzwerkproblem, dass das 2.4 auf diesen Kanal ausgelastet ist und deshalb zu Fehlern führt

[Ulli1]

@crunchip ich habe das letzte SW-Update des nahen AP`s vorsichtshalber auf die letzte Version zurückgesetzt. Hat auch nichts gebracht. Deine Tasmota-Clients kannst du immer und jederzeit über IP im Browser steuern? Das ist bei mir so. Somit ist ja eigentlich WLAN an sich nicht das Problem. Wie bereits geschrieben konnte ich tatsächlich feststellen, Wenn alive "false" war, ging über IOBroker kein Steuerbefehl mehr an den Client (über IP Tasmota Browser aber sehr wohl). In der Anlage ein aktuelles Bild meiner alive-Zustände.

[Ulli1]

@ulli1 Aktuell am UAP AC LR 5.43.38. In der Netzwerkliste sind alle Geräte ohne Verbindungsverlust.

[Jens Meyer]

@ulli1
Das selbe Problem habe ich auch… nur das im AP paar Geräte auch verschwinden
Wenn ich den ap neu starte verbindet sich wieder alles
Ich werde das mal beobachten…. Bei meinem UniFi ap pro schmeißt es aber auch den harmonyhub mit raus, nicht nur die tasmota… sind meistens 6 Geräte…
Ich bin mir noch nicht sicher… aber ich schiebe das mal auf die FRITZ!Box wo die ac Points dran hängen… ich werde das mal noch mit der udm pro testen…wenn die ac points daran hängen.. wird aber noch etwas dauern..

[crunchip]

@ulli1 hab die 5.43.46 beim AC LR und M, beim NanoHD hab ich die 5.60.16
Controller 6.4.54, siehe changelog, vllt hängt das auch damit zusammen

[Ulli1]

@crunchip 5.43.46 war vor kurzer Zeit bei mir auch upgedatet worden. Hatte ich schon verdrängt. Daher hab ich downgegraded, was aber auch nicht die Lösung darstellte. ich habe mqtt oder was anderes im Verdacht. Wenn ich doch nur das mqtt-Protokoll loggen könnte..

[crunchip]

@ulli1 sagte in Tasmota-Clients werden im IOBroker disconnected:

ich habe mqtt oder was anderes im Verdacht

hast du den mqtt Adapter laufen, bzw shelly?

[Ulli1]

@crunchip sonoff-Adapter im iobroker, clients von shelly, sonoff, gosund, tuya uw. Alle zeigen das gleiche Verhalten. Über welchen Adapter mqtt im iobroker sprichst du die Clients an?

[BananaJoe]

Ich gebe hier jetzt auch mal allgemein meinen Senf dazu, eventuell liegt es bei euch nämlich einfach an der Anzahl der Geräte.

Ich habe um die 44 Shelly 1 mit Tasmota-Firmware + noch mal 20 Tasmota-Geräte, in der Masse schaltbare Steckdosen für Strommessungen, aber auch ein paar Wemos D1 Mini mit Tasmota z.B. für die Türklingelüberwachung oder für eine selbstgebaute Musiksteuerung mit Display.

Ich hab das von Anfang an mit MQTT gemacht - und zwar einen Mosquitto-Broker mit auf dem ioBroker Server und den ioBroker per MQTT-Adapter als Client am Mosquitto.

Ich hatte aber zwischendurch auch mal getestet den Sonoff-Adapter zu nehmen und den MQTT-Adapter als Server/Broker (und nicht als Client).
Beides war eine ganz schlechte Idee - und zwar aus folgendem Grund:
Beim Einrichten war noch alles gut, ich hab meine Tasmota-Geräte nacheinander Stück für Stück umgestellt und es lief alles prima. Dann hab ich den ioBroker mal neu gestartet ...
Die Tasmota-geräte waren natürlich alle getrennt und haben verzweifelt versucht sich mit den Sonoff oder den MQTT-Server zu verbinden. Und zwar kamen da ziemlich alle auf einmal. Und das war zuviel für die Adapter, die waren damit überlastet und die Verbindung brach dauern wieder ab, schlicht weil die Adapter bei über 60 Geräten denen nicht schnell genug Antworten konnten. ioBroker läuft bei mir in einer VMware VM mit 3 CPU-Kernen und 4GB RAM auf einer NVMe, von Außen war das schnell genug. Aber ich habe das Gefühl das die Adapter halt "seriell" arbeiten und mit zu vielen gleichzeitigen Anfragen überfordert sind.

Seitdem arbeite ich da angesichts der Anzahl der Geräte wieder mit dem Mosquitto, der schluckt das Problemlos weg. Der MQTT-Client Adapter aktualisiert die Datenpunkte wenn er es schafft und gut ist.

[crunchip]

@bananajoe sagte in Tasmota-Clients werden im IOBroker disconnected:

Und zwar kamen da ziemlich alle auf einmal. Und das war zuviel für die Adapter,

das befürchte ich auch, das bei vielen gleichzeitugen Anfragen die Verbindung wegbricht.
mit mqtt kann ich mich nicht so recht anfreunden, blick das irgendwie nicht so richtig.
habe zwar den mqtt Adapter laufen, jedoch eigentlich nur ein einziges Gerät(RFid) damit verbunden und wenn ich mir die Instanz dabei ansehe, verbraucht der mqtt Adapter rund 110MB und liegt bei Ereignissen ca Eingang 1200/Ausgang 11

letztendlich bin ich am überlegen ob ich nicht auf esphome mit meinen Tasmota umziehe, da muss ich mich allerdings auch erst einmal einlesen

[BananaJoe]

@crunchip gib dich nicht auf, lerne MQTT! Für ich war es am Anfang auch erst einmal unverständlich und Abstrakt. Aber dann hat es irgendwann "ping" gemacht und ich möchte es als Austausch-System nicht mehr missen.

Der erste Clou ist ja das die Geräte einfach ihre Statusmeldungen und Zustandsänderung an den MQTT-Broker pushen, das steht ganz ähnlich wie bei den Datenpunkten des ioBroker immer was gerade Sache ist.

Der zweite Clou ist das du den Status von bestimmten Pfaden abonnieren kannst (nutze ich z.B. in Bash-Skripten). Dann sagt der Broker dir bescheid, hey, hier hats sich Wert X geändert, den wolltest du doch haben. Und schon musste ich nichts mehr pollen und hatte alle Daten und Reaktionen quasi in Echtzeit.

Tasmota macht das von Haus aus sehr gut, der pusht in bestimmten Pfaden seine Daten und horcht wiederum auf einem anderen. Der Sonoff-Adapter macht eigentlich nichts anderes, der Simuliert einen MQTT-Broker und baut dir die JSON-Meldungen schön in Einzelwerte um.

Der 3. Clou ist für mich - wegen des Mosquitto-Brokers - das ich da auch alles andere was MQTT dranhängen kann, wenn es ein muss auch am ioBroker vorbei oder parallel.

Nachteil ist ganz klar das der Sonoff-Adapter dir zum Schalten (Power) einen schönen True/False-Datenpunkt baut. Den hats du im ersten Moment in MQTT nicht.
Ich habe dazu für jedes Tasmota-Gerät ein eigenes JavaScript laufen was mir das nachbaut. Im Prinzip was der Sonoff-Adapter macht. Weil es aber für jedes Gerät ein eigenes Skript gibt (also 64 Stück) und die quasi Parallel laufen gibt es keine Probleme, der Adapter wäre ein Skript was versucht alle 64 zu händeln.