Closed kopierschnitte closed 2 years ago
klein0r
commented
2 years ago There was a request for 5.3.1 to avoid sending the same value again. See #571
Just to be sure
truetrue
kopierschnitte
commented
2 years ago Well, not sure if it's a good idea to handle it like that because it effectively disables such watchdog-functionalities.
It's a little bit different:
wigumde
commented
2 years ago Hallo, kurzer Nachtrag / Nachfrage bzgl. diesem Issue: Das Verhalten des Adapters wurde ja von der Version 5.3.2 auf die Version 6.0.0 dahin gehend geändert, dass der Wert "wahr" nur dann zum Shelly gesendet wird, wenn dieser im Shelly nicht bereits auf "wahr" steht. Die Argumentation für diese Änderung war ja unter anderem, (ich zitiere aus dem Issue Eintrag #571 vom 10. März), "Ansonsten müsste man ja drüber sprechen, ob man den Befehl überhaupt nochmal zum Gerät sendet, wenn der Wert eh schon gleich ist. Wird ja eh nichts passieren."
Diese Aussage ist so nicht ganz korrekt. Wenn der Wert "wahr" nochmals zum Shelly gesendet wird, auch wenn dieser bereits "wahr" ist, wird die "Auto off" Time des Shellys erneut gestartet. Das bedeutet, das Unterdrücken des erneuten Sendens des Wertes hat sehr wohl eine Auswirkung. Mit der Änderung des Verhaltens in der Version 6.0.0 ist der Neustart der "Auto off" Time nun nicht mehr möglich.
Frage: Wie ist denn der Stand diesbezüglich? Kann diese Funktion bzw. wird diese Funktion in einer der nächsten Versionen des Shelly Adapters wieder aufgenommen?
kopierschnitte
commented
2 years ago Gut zusammengefasst... +1 von meiner Seite aus. Vielleicht wäre es besser, dies optional zu machen.
chris299
commented
2 years ago IMHO sollte es nicht optional sein. wenn das Device etwas tut, wenn man einen Wert "nochmal" schickt, dann sollte das immer erfolgen, wenn es getriggert wird....
Apollon77
commented
2 years ago Das ist halt ein echt "scheiss dilemma".
Shelly bestätigt nicht wenn der wert der gesendet wird bereits gesetzt ist, also weiss der Adapter nicht ob die meldung überhaupt angekommen ist - aber ggf werden dennoch darauf Shelly intern logiken ausgeführt.
Also selbst wenn man die logik anpasst das man immer sendet aber bei "wert ist der gleiche" der adapter selbst ein ack setzt, dann weiss man dennoch nicht obs angekommen ist aber es ist geackt ....
klein0r
commented
2 years ago Das Verhalten des Adapters wurde ja von der Version 5.3.2 auf die Version 6.0.0 dahin gehend geändert, dass der Wert "wahr" nur dann zum Shelly gesendet wird, wenn dieser im Shelly nicht bereits auf "wahr" steht.
Fast richtig. Das verhalten gilt für alle Versionen seit 5.3.2 und neuer.
Frage: Wie ist denn der Stand diesbezüglich? Kann diese Funktion bzw. wird diese Funktion in einer der nächsten Versionen des Shelly Adapters wieder aufgenommen?
Du kannst ja mal einen Vorschlag machen, wie sich die Geräte in allen genannten Situationen verhalten sollen 😄
klein0r
commented
2 years ago Vielleicht wäre es besser, dies optional zu machen.
Noch mehr Optionen = mehr Variablen = mehr Issues und mehr Aufwand beim Support. Ihr schaut hier immer nur rein, wenn für euch etwas nicht funktioniert, aber es gibt ja dazwischen hunderte Tickets. Eine neue Option schließe ich daher aus. Viele sind jetzt schon mit den Einstellungen überfordert.
Apollon77
commented
2 years ago Also meiner Meinung nach geht es nur in dem man in einen sauren apfel beisst:
klein0r
commented
2 years ago wenn das Device etwas tut, wenn man einen Wert "nochmal" schickt, dann sollte das immer erfolgen, wenn es getriggert wird....
Das Ganze wurde ja (lustigerweise) eingeführt, weil der Shelly das erneute schreiben nicht bestätigt, wenn der Wert identisch zum vorigen ist. Das heißt in diesem Fall jetzt, dass zwar intern etwas passiert, aber das ganze nicht per MQTT rausgeht. Somit gab es gar kein ack in manchen Fällen.
Die Frage ist jetzt, wieviele Optionen das wirklich betrifft. Sonst müsste man es wirklich so machen, wie @Apollon77 vorschlägt. Und dann kann man sich die ganze ack-Geschichte auch komplett sparen irgendwie.
Apollon77
commented
2 years ago Wie gesagt, in jedem Fall ists irgendwie ein "komischer Hack" weil irgendeinfall ist immer blöd. Alternativ sollte Shelly FW einfach auch bestätogen wenn der wert schon anliegt da ja scheinbar ggf andere aktionen ausgeführt werden ... aber keine Ahnung was die sagen ;-)
chris299
commented
2 years ago @Apollon77 evtl. könnte da einer der Entwickler (mit etwas mehr technischem Wissen zu MQTT ACK als ich) mal ein support ticket bei Allterco aufmachen mit einer Fragen nach "missing Ack on value send" oder so...: https://ticket.shelly.support/open.php ich habe die dort als recht kooperativ erlebt....
wigumde
commented
2 years ago Würde mich Apollon77 und chris299 anschließen:
kopierschnitte
commented
2 years ago Ja, dem schließe ich mich natürlich auch an. Für mich ganz persönlich ist das erneute, erzwungene Senden wichtiger als ein plausibles ACK.
Shelly device
Shelly1PM
Protocol (CoAP / MQTT)
CoAP
The problem
I'm using the Shelly1PM to open a water valve. For security reasons, I've set the Auto-Off value to 20sec and used a script to set the switch value to TRUE every 5sec in a loop. This cleared the timer in every loop and I could ensure that the valve gets closed if the script fails or something else goes wrong. It's more or less a watch-dog functionality.
Starting with adapter 6, the timer doesn't get reset anymore. I guess that the adapter doesn't send the "true" value for the switch if the value is already "true".
I've reverted to v5.3.0 and everything is working as expected.
Version of nodejs
16
Version of ioBroker js-controller
4.0.23
Version of Adapter
6.0.0
Operating system running ioBroker
Ubuntu
Checklist of files to include below
Additional information & file uploads
No response