wichtiges UPDATE für controller 7.2.2 im stable

[mickemup]

Der Cronjob sieht so eigentlich ok aus.
Hast du Meldungen im Log?
Ansonsten mal ein DEBUG Block einsetzen, um zu schauen, ob der Cronjob auch auslöst.
Um ganz sauber zu sein, sollte am anfang ein "stoptimeout" rein. (Sollte aber hier keinen Einfluss haben, da die Gefahr von zu vielen Timeout Blöcken hier nicht bestehen sollte...

Der DP Switch wurde auch nicht angepasst nehme ich an?

[Hans_M]

@mickemup

Habe das jetzt mal so gemacht und einen Test gestartet.
Hat funktioniert...mal schauen ob es dann morgen früh um 5 Uhr auch so ist.

DP wurde nicht geändert.

[Hans_M]

Also es funktioniert immer noch nicht.
Der Trigger an sich funktioniert.
Habe jetzt den History Adapter benutzt.
Anscheinend kommt von der Shelly Instanz regelmäßig ein ein Befehl für "false", was ich mir bisher aber nicht erklären kann.

[Asgothian]

Anscheinend verweigert das Device den Schaltbefehl und bestätigt den vorherigen (aktuellen) Zustand des Gerätes. Du solltest mal prüfen was passiert wenn du den DP manuell schaltet - wir der bestätigt (blau) oder bleibt er unbestätigt (rot) (Die Farbangaben gelten für Admin 7, vorher sah das glaub ich anders aus)

A.

[Hans_M]

@Asgothian

Habe den DP jetzt mal manuell betätigt (die beiden Einträge von der cloud.0)

[da_Woody]

@Hans_M
will dir jetzt nicht unterstellen, daß du shelly scheisse findest.
deine screenshots sagen genau nichts aus.
0 aussage, wie der shelly eingebunden ist, wann welche updates gemacht wurden, was der shelly über ip sagt, wird die app verwendet?

[Asgothian]

@da_Woody sagte:

deine screenshots sagen genau nichts aus.

So weit würde ich nicht gehen.

Die Screenshots zeigen ganz deutlich das das Skript an sich funktioniert. Was nicht funktioniert ist das Schalten des Gerätes über den Shelly Adapter. Letztendlich zeigt auch der letzte Screenshot das der steuere Befehl von Cloud.0 (false, Ack:false) vom Shelly Adapter mit true (Ack:true) bestätigt wird - sprich das Gerät schaltet nicht und bestätigt den Schaltbefehl auch nicht.

Bliebe die Frage warum. Dazu sind Informationen die @da_woody abgefragt hat wichtig:

• wie ist das Gerät angebunden ?
• wird es im Adapter als verbunden angezeigt ?
• lässt es sich direkt im Adapter schalten (wenn der Adapter das anbietet)
• hängt es an der Shelly Cloud ? Wenn ja, lässt es sich da schalten ?

und
so
weiter.

A.

[Hans_M]

@Asgothian

Ich habe zwei Instanzen am laufen.
Die erste läuft für die Geräte, die per CoAP eingebunden sind.
Das komische ist, dass in der Nacht anscheinend jede volle Stunde ein false von der App, oder der Instanz kommt. Und genau das verhindert ein Einschalten der Pumpe.
Der Rest schein soweit zu funktionieren, aber jeder Schaltbefehl vom Script wird irgendwie nochmal von der Instanz oder der App bestätigt.

Adapter ist übrigens grün und wird alle 24 Std. neu gestartet.
Gerät lässt sich sowohl am DP als auch in der App schalten.
Ich weis nicht wo dieser Schaltbefehl herkommt, habe keinerlei Zeitpläne oder Szenen in der Shelly Cloud bzw. App.

[Asgothian]

@Hans_M sagte:

Ich weis nicht wo dieser Schaltbefehl herkommt, habe keinerlei Zeitpläne oder Szenen in der Shelly Cloud bzw. App.

Das was du da siehst ist kein Schaltbefehl sondern eines der folgenden:

• die Reaktion des Gerätes auf einen Schaltbefehl via insert andere Anbindung hier
• ein Reporting des Devices welches seinen Status an den ioBroker meldet, weil es das sowieso regelmässig tut
• ein Reporting des Devices welches seinen Status an den ioBroker meldet weil es gerade mitbekommen hat das es verbunden ist.

Was es davon ist kann ich dir nicht sagen - da fehlen die Infos.

Ansonsten fehlen in Deinen Angaben leider weiter entscheidenden Informationen:

• in welcher Instanz ist das betroffene Gerät angebunden ?
• wie ist das betroffene Gerät angebunden ?
• hängt das betroffene Gerät in der Shelly cloud ?
• sind auf dem Gerät / in der Cloud Verbindungsabbrüche protokolliert ?
• kommt der Schaltbefehl vom cloud.0 oder javascript.0 am Gerät an (sprich, wenn du es manuell - direkt am ioBroker via schalten des Datenpunktes im Objektbaum - NICHT über cloud.0 oder javascript.0 oder insertYourInstanceName.here) versuchst zu schalten, reagiert es dann ? (ich vermute: nein)

Bei der Informationslage ist das alles stochern im Dunkeln

A.

[Hans_M]

@Asgothian

@Asgothian sagte:

in welcher Instanz ist das betroffene Gerät angebunden ?

shelly.0

@Asgothian sagte:

wie ist das betroffene Gerät angebunden ?

Der Adapter kann über MQTT (empfohlen) oder CoAP/CoIoT mit den Geräten kommunizieren.
In diesem Fall ist das Gerät per CoAP/CoIoT eingebunden.

@Asgothian sagte:

hängt das betroffene Gerät in der Shelly cloud ?

Ja, es ist mit der Cloud verbunden.

@Asgothian sagte:

sind auf dem Gerät / in der Cloud Verbindungsabbrüche protokolliert ?

Das kann ich nicht ermitteln.

@Asgothian sagte:

kommt der Schaltbefehl vom cloud.0 oder javascript.0 am Gerät an (sprich, wenn du es manuell - direkt am ioBroker via schalten des Datenpunktes im Objektbaum - NICHT über cloud.0 oder javascript.0 oder insertYourInstanceName.here) versuchst zu schalten, reagiert es dann ? (ich vermute: nein)

Ja, der Schaltbefehl kommt an.

Ich denke, ich habe den Fehler jetzt eventuell gefunden.
Ich lasse den Adapter regelmäßig neu starten. Habe hierzu im Zeitplan "alle 1440 Minuten" eingestellt, also alle 24 Stunden.

Nachdem ich mir jetzt das Log mal genau durchgeschaut habe, habe ich festgestellt das der Adapter zur jeder vollen Stunde neu startet und da genau um 5 Uhr die Pumpe einschalten soll, wurde der Schaltbefehl anscheinend nicht an das Gerät weitergegeben.
Ich kann mir zwar nicht erklären wieso er das macht, aber habe jetzt mal "jeden Tag um 2 Uhr" eingestellt.
Mal schauen ob es dann passt.

[Asgothian]

Mal ganz blöd gefragt - warum soll der Adapter alle X Stunden neu starten ? Was ist dafür der Grund ?

A.

[Hans_M]

Hatte da in letzter Zeit Probleme, dass ich keine Daten von den Shelly Geräte reinbekommen habe.
Als ich den Adapter neu startete war die Verbindung wieder da.
Deshalb habe ich das so eingestellt, quasi als vorbeugende Maßnahme.

[mickemup]

@Hans_M
Mein Verdacht.
Für den CRON mit alle N minuten ist wohl 1440 nicht valid.
Darum hat er jede Stunde neu gestartet (Darum auch die Einträge ca. jede Stunde)

Aber generell...Adapter immer frisch starten ist nur Symptombekämpfung.
Man sollte versuchen der Fehlerquelle auf den Grund zu gehen.

[Hans_M]

@mickemup sagte:

Aber generell...Adapter immer frisch starten ist nur Symptombekämpfung.
Man sollte versuchen der Fehlerquelle auf den Grund zu gehen.

ich weis, wenn ich mal etwas Zeit habe möchte ich sowieso alle Shelly Geräte auf mqtt umstellen. Dann dürfte das Problem behoben sein.