search

iobroker-community-adapters / ioBroker.shelly

Integrate your Shelly devices into ioBroker via MQTT or CoIoT
Other
162 stars 65 forks source link

[Bug]: Shelly 2.5: Roller-Switch: Datapoints OPEN/CLOSE/PAUSE are not updated -- relates #770 #977

Open 2Moon4 opened 5 months ago

2Moon4 commented 5 months ago

I'm sure that

Shelly device

shelly 2.5 (Version1)

Shelly firmware version

20230913-112234/v1.14.0-gcb84623

Protocol

MQTT

The problem

Das Problem habe ich bereits einmal in Issue #770 beschrieben. An dem Verhalten hat sich noch nichts geändert. Die Werte für Shutter-Objekte OPEN, CLOSE und PAUSE werden vom Adapter nicht mehr aktualisiert bei allen Adapter-Versionen > 6.0.0 Eigentlich muss der Wert für diese Objekte immer wieder auf "false" zurückgehen, wenn ein anderer Wert auf "true" geht.

Ein Beispiel: Ausgangszustand der Shutter-Objekte ist:

Klickt man nun bei geöffnetem Rollo den Button CLOSE sollte der Zustand aller dieser Datenpunkte wie folgt geändert werden:

Ist das Rollo fertig mit dem Vorgang (in dem Fall Schließen), sollten sich alle Datenpunkte wieder automatisch in den Ausgangszustand bewegen.

Das passiert aber nicht. Alle diese Status werden - einmal in true geändert - nicht mehr zurück nach false geändert und bleiben dann alle auf "true" stehen.

iobroker.current.log (in debug mode!)

iobroker.log

Version of nodejs

v18.19.0

Version of ioBroker js-controller

5.0.17

Version of adapter

7.0.0

github-actions[bot] commented 5 months ago

Thanks for reporting a new issue @2Moon4!

  1. Please make sure your topic is not covered in the documentation
  2. Please attach all necessary log files (in debug mode!), screenshots and other information to reproduce this issue

  3. Search for the issue topic in other/closed issues to avoid duplicates!

    Otherwise this issue will be closed.

2Moon4 commented 5 months ago

Bezüglich dem gesetzten Label "no debug log attached" kann ich nur sagen: Ich habe das Log genommen, was iobroker unter /opt/iobroker/log/ vom heutigen Datum erstellt hat. Auch hatte ich VOR dem Start der Aktionen (Update auf Adapter-Version 6.9.0) das Loglevel im IOBroker auf "silly" geändert - wobei ich glaube das das nur zum Filtern für die interne Anzeige relevant ist).

klein0r commented 5 months ago

Im Log ist aber kein einziger Log-Eintrag mit Debug Loglevel zu finden

2Moon4 commented 5 months ago

Das stimmt. Aber ich habe nicht das gesamte Logfile angehangen, sondern nur den Ausschnitt des Logs, ab dem Moment wo ich das Upgrage des Shelly-Adapters von Version 6.0.0 auf 6.9.0 gemacht habe. Danach habe ich einen Test ausgeführt, der das besagte Fehlerbild ergab. Danach habe ich dann noch das Update auf 7.0.0 ausgeführt - und einen weiteren Test gemacht (selbes Fehlerbild) Dann habe ich wieder das Downgrade auf 6.0.0 gemacht und der Fehler war wieder weg bei einem Test. In dieser Zeit ist leider kein einziger Debug-Eintrag entstanden :(

Kann ich da etwas anders machen, damit passende Logmeldungen entstehen?

Edit: Im IOBroker selbst stand das Loglevel die ganze Zeit auf "silly". Ich habe dann aber das Logfile runtergeladen und im Editor beschnitten.

2Moon4 commented 5 months ago

Wenn das irgendwie in Frage kommen könnte, könnte ich auch anbieten eine Teams oder Webex-Session zusammen machen um das Problem direkt zu zeigen.

2Moon4 commented 2 weeks ago

Hallo, kann ich denn noch irgendwas machen, damit es mit diesem - aus meiner Sicht Bug - weiter geht? Solange dieses Problem besteht kann ich ansonsten keine Updates mehr installieren. Und ob die Version (bei der bei mir alles noch läuft: 6.0.0) noch mit zukünftigen nodejs/npm oder js-controller Versionen zusammenarbeitet ist vermutlich auch ungewiss.

mcm1957 commented 2 weeks ago

Kannst du mal die ROLE der fraglichen States zeigen?

Beispiel (hier von eine Shelly plug) image

Kann es sein, dass diese States die ROLE BUTTON haben?

Wenn ja, dann ist das Verhalten völlig normal und OK. Buttons haben keinen Wert. Der Adapter sollte bei BUTTONS nur auf einen Schreibzugriff mit ACK=FALSE reagieren. Ob ein Adapter den Wert zurücksetzt oder nicht ist nicht definiert. Der Wert eines Buttons kann dir auch egal sein da er wie gesagt nichts aussagt. Gibt es eine Fehlfunktion (Rollo bewegt sich nicht o.a.)?

2Moon4 commented 2 weeks ago

Hi, ja du hast recht: Die Role der betreffenden Objekte ist "Button". Aber das hat doch auch seine Richtigkeit, denn es sind ja auch Buttons. Ein Button zum Öffnen, Schließen und Pausieren des (Rollo)Motors. Die gibt es auch alle drei in physisch am Rollo-Motor-Schalter. Und wenn einer davon gedrückt wird, müssten die anderen beiden in den "false" Wert wechseln, weil diese zwei dann nicht mehr gedrückt werden und mir das auch so mitgeteilt werden müsste.

Bis zur Version 6 des Adapters ist das ja auch so. Ansonsten kann man damit ja überhaupt nicht mit Rolladenmotoren arbeiten, wenn mir der Adapter nicht sagt, welche 2 Buttons gerade die deaktiven sind, und welcher der aktive. Wenn ich das alles nur über Software steuern würde, könnte ich die Status der Buttons ja alle selbst schreiben: ABER: Man kann solche Buttons ja auch in echt, am echten Button, am Rollo drücken. Dann muss mir der Adapter das natürlich mitteilen - sonst habe ich ja keine Chance das mitzubekommen.

Die "Fehlfunktion" (ab 6.x des Adapters) gibt es, nachdem man 1x einen Button (erfolgreich) geklickt hat und das Rollo dann diese Aktion ausgeführt hat. Danach sind nämlich die Status der geklickten Buttons auf true und gehen nicht mehr auf false zurück. Somit kann ich kein zweites mal ein Rollo öffnen oder schließen. Der Rolladenmotor hört natürlich mit der letzten Aktion dann alleine auf, wenn er ein Rollo geöffnet oder geschlossen hatte. Aber da dann alle Buttons den Status "true" haben, kann ich keine Änderung mehr vornehmen, auch nicht am echten Button des Rollos.

mcm1957 commented 2 weeks ago

Hi, ja du hast recht: Die Role der betreffenden Objekte ist "Button". Aber das hat doch auch seine Richtigkeit, denn es sind ja auch Buttons. Ein Button zum Öffnen, Schließen und Pausieren des (Rollo)Motors. Die gibt es auch alle drei in physisch am Rollo-Motor-Schalter. Und wenn einer davon gedrückt wird, müssten die anderen beiden in den "false" Wert wechseln, weil diese zwei dann nicht mehr gedrückt werden und mir das auch so mitgeteilt werden müsste.

NEIN müssen sie nicht, da BUTTONS per Definition KEINEN Wert haben bzw. Liefern. Buttons sind INPUT only States die nur auf das Schreiben mit ACK=FALSE reagieren. Nicht umsonst wird im non-expert Mode auch kein Wert angezeigt,

Bis zur Version 6 des Adapters ist das ja auch so. Ansonsten kann man damit ja überhaupt nicht mit Rolladenmotoren arbeiten, wenn mir der Adapter nicht sagt, welche 2 Buttons gerade die deaktiven sind, und welcher der aktive. Wenn ich das alles nur über Software steuern würde, könnte ich die Status der Buttons ja alle selbst schreiben: ABER: Man kann solche Buttons ja auch in echt, am echten Button, am Rollo drücken. Dann muss mir der Adapter das natürlich mitteilen - sonst habe ich ja keine Chance das mitzubekommen.

Wie geschrieben ist ein BUTTON ein Input Only State. Der muss / wird dir nichts vom Gerät mitteilen.

Die "Fehlfunktion" (ab 6.x des Adapters) gibt es, nachdem man 1x einen Button (erfolgreich) geklickt hat und das Rollo dann diese Aktion ausgeführt hat. Danach sind nämlich die Status der geklickten Buttons auf true und gehen nicht mehr auf false zurück. Somit kann ich kein zweites mal ein Rollo öffnen oder schließen. Der Rolladenmotor hört natürlich mit der letzten Aktion dann alleine auf, wenn er ein Rollo geöffnet oder geschlossen hatte. Aber da dann alle Buttons den Status "true" haben, kann ich keine Änderung mehr vornehmen, auch nicht am echten Button des Rollos.

Wieso kannst du einen State der die Role BUTTON hat nicht nochmal beschreiben? Natürlich sollte der Adapter auf ein weiteres Beschreiben reagieren, wenn er das nicht tut wäre das ein Bug. Und warum der State irgendeinen Einfluss auf physikalische Taster des Rollos haben? Die sind ja von ioBroker unabhängig.

Generell stellt sich hier eher die Frage ob die entsprechenden States BUTTONS oder SWITCHES sein sollten. Buttons leifern keine Informationen vom Gerät und besitzen keinen Wert. Buttons in ioBroker sind so definiert. Wenn du eine Rückmeldung vom Adapter bzw. eine Anzeige eines Status haben willst, dann sollten die States die Role Switch haben.

@klein0r Irgendein Input dazu?

klein0r commented 2 weeks ago

Wieso kannst du einen State der die Role BUTTON hat nicht nochmal beschreiben? Natürlich sollte der Adapter auf ein weiteres Beschreiben reagieren, wenn er das nicht tut wäre das ein Bug.

Das wäre auch meine Frage. Gerne eine Debug-Log dazu, sobald auf den Button gedrückt wird / bzw. true geschrieben

2Moon4 commented 1 week ago

shelly6.0.log shelly7.0.log

Hallo, ein paar Neuigkeiten von mir: Zunächst habe ich mal gesehen, dass ich in den Einstellungen des Adapters das Loglevel auf "Debug" ändern müsste - damit der Adapter auch in Debug logt... sorry - das hatte ich vorher übersehen! Das hab ich nun getan und 2 neue Logfiles angehangen:

Hier habe ich für den Shelly Switch shelly.0.SHSW-25#483FDA8278DC#1 jeweils einen Test durchgeführt, indem ich am Rollo-Shalter die physischen Tasten betätigt habe. Beim shelly 7.0 Adapter ändert eine Role "Switch" leider nichts am beschriebenen verhalten: Der State von Open, Close, Pause wird für nicht geklickte Elemente nicht zurück geändert in false, wenn ein Element geklickt wird. Beim shelly 6.0 Adapter ist das aber der Fall.

Das Ändern der Role "Buttons" in "Switch" geht zwar im Expertenmodus - wird nach einem Adapter-Neustart aber automatisch auch wieder auf "Button" zurück-geändert. Diese Änderung hat aber wie gesagt keinen Erfolg gebracht.

2Moon4 commented 5 days ago

Hi, jetzt sollte der Anhang ein Debug-Log darstellen - oder? Kann damit jetzt etwas angefangen werden? Auch mit meinen letzten Erläuterungen dazu?