Schalten und kontrollieren
-
@paul53 sagte in Schalten und kontrollieren:
"wiederhole solange" erzeugt eine Endlosschleife, die die Javascript-Instanz zum Absturz bringt. Verwende ein Intervall.
Ups, ich dachte die Pause verhindert die Endlosschleife. Aber das die nicht hilft hatte ich dann ja ebenso bemerkt.
OK ich veruche das mit dem Intervall wie @Paul53 vorgschlagen. -
@actionbyte sagte: veruche das mit dem Intervall
Eleganter geht es mit einer Funktion und einem Wiederholungszähler.
-
@actionbyte Ob Geräte erreichbar sind, kann man mit dem Ping-Adapter auf Netzwerk-Ebene testen.
Bei Geräten, die auch Daten senden (z .B. Steckdosen die aktuelle Leistung) kann man auch über ein Skript prüfen, ob diese Daten regelmäßig aktualisiert werden ... im obigen Skript könnte man natürlich auch detektieren, ob es beim ersten Versuch geklappt hat oder Wiederholungen nötig waren.Bezüglich Qualitätssicherung würde ich da schon versuchen, einen Überblick zu erhalten, wie oft die Devices aus dem WLAN fliegen ...
-
@martinp sagte in Schalten und kontrollieren:
@actionbyte Ob Geräte erreichbar sind, kann man mit dem Ping-Adapter auf Netzwerk-Ebene testen.
Hatte ich auch schon probiert, aber egal ob mit Radar/ping oder tr064 ist das Ergebnis ernüchternd, außer ich müsste den Ping-Intervall sehr kurz setzen weil die Devices manchmal nur 1-2 mal per Ping nicht antworten.
Wenn ich ausgerechnet dann Schalten möchte klappt das eben nicht.
Die Kontrolöle ob tatsächlich geschaltet wurde und es beim Fehlverusch nochmal zu probieren finde ich da eleganter. -
Wenn da wirklich die MQTT-Clients regelmäßig aus dem WLAN fliegen, sollte das doch auch im iobroker Logging Spuren hinterlassen, z. B. so etwas:
2023-10-29 01:12:37.127 - [32minfo[39m: sonoff.0 (143497) Client [Bewaesserung] reconnected. Old secret 1698533797112_7834. New secret 1698534757126_239 2023-10-29 01:13:28.099 - [32minfo[39m: sonoff.0 (143497) Client [Bewaesserung] reconnected. Old secret 1698534757126_239. New secret 1698534808098_3308 2023-10-29 01:13:31.281 - [32minfo[39m: mqtt.0 (143482) Client [esp8266-cf6d7a] reconnected. Old secret 1698534744585_719. New secret 1698534811281_3005 -
@actionbyte sagte in Schalten und kontrollieren:
der ein oder andere Shelly genau dann ein FW-Update genommen
? update wird manuell gemacht!
-
@da_woody sagte in Schalten und kontrollieren:
? update wird manuell gemacht!
Wenn man ab einer gewissen Anzahl von Shellys und Tasmotas im Netzwerk mit einem Update manuell "stundenlang" beschäftigt ist, nutzt man die Funktion des automatischen Updates vom Shelly Adapter gerne.
-
@actionbyte Muss man aber doch wohl nicht dauerhaft aktiviert haben. Da schaltet man die automatischen Updates scharf, schaut später, ob alles durch ist, und schaltet das Feature wieder ab ..
-
@actionbyte ich hab selber ca. 90 Shelly, Update nur über die App.
Da weiß ich wann das passiert. Beim Adapter hast du keinen Einfluss.
Es hat schon Updates gegeben die kurz später zurück gezogen wurden weil ein Bug entdeckt wurde.
Aber jeder wie er mag... -
@actionbyte Eine Frage: kann der Shelly Adapter auch "markenfremdes" Tasmota-Gedöns aktualisieren?
Bei mir gibt es nur "umgeflashte" Tasmota ESP Hardware anderer Hersteller und selbst zusammengebastelte ESP-basierte Hardware, keine Shellys...
Eine zweite Frage - die Tasmota-Firmware meines ESP8266 am Infrarot-Port des Stromzählers habe ich selber kompiliert - da fehlt mir die Vorstellungskraft, wie da ein automatischer Update über den Shelly Adapter bewerkstelligt werden kann...
-
@martinp Shelly Adapter, wie soll der mit Tasmota?
Es gibt Leute, die flashen einen Shelly sinnlos auf Tasmota um. Jeder wie er mag. -
@da_woody Ich habe die folgende Aussage wohl falsch interpretiert
Wenn man ab einer gewissen Anzahl von Shellys und Tasmotas im Netzwerk mit einem Update manuell "stundenlang" beschäftigt ist, nutzt man die Funktion des automatischen Updates vom Shelly Adapter gerne
Das klingt doch erstmal so, als ob er Shellys und Tasmotas automatisch über den Shelly Adapter updaten würde... falsche Fährte
