Neues YouTube-Video: Visualisierung im Devices-Adapter

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

[da_Woody]

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

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.

sorry, das kann aber nicht sinn der sache sein.
dann bräuchten wir keine adapter und könnten alles über scripts laufen lassen...

[BananaJoe]

@da_woody gebe ich dir recht. Aber der Adapter "packt es halt nicht". Zudem hatte ich Extrawünsche wie z.B. die Erfassung von Laufzeiten oder ein Info an welchen AP die Dinger gerade hängen.
Und da gleich einen eigenen Adapter zu schreiben, soweit war ich da noch nicht (und bin ich auch noch nicht denke ich).

Eigentlich müsste man dem Adapter beibringen das er sich mehr aufteilt und ggf. pro Gerät einen Unterprozess startet - aber ich hab keine Ahnung ob das technisch geht.

[da_Woody]

@bananajoe hast aber schon einige "spezial" wünsche... ;)
die uptime sehe ich im sonoff adapter. zwar nur die tage, aber immerhin. wobei, gibt auch uptimesec...
an welche AP das ding hängt ist mir eigentlich tögal, solange online. kann mir aber über meine top denken an welchem AP der nuckelt.
hab allerdings nur mehr 7 SP112 und im mom 2 D1-mini im sonoff hängen. der rest ist bei mir nur mehr shelly. ca. 80stk.

[Ulli1]

@bananajoe das klingt plausibel! Ehrlich gesagt habe ich ein externes Backup der SD-Card gemacht; gefühlt fing der Ärger danach an. Insgesamt sind etwa 25 Clients am sonoff-Adapter.