Verzögerter STATUS UPDATE von SHELLY zu OPENHAB

[Vero Beach]

Hallo Experten

Ich benutze Openhabian 3.3.0 Release build auf einem Raspberry Pi 4. Mein Setup läuft schon seit mehreren Jahren praktisch unverändert und hat mit Openhab 2.5 und den früheren 3er Versionen immer bestens funktioniert. Seit einem der letzten Updates (Openhab3) habe ich aber folgendes Problem im «Zusammenspiel» ausschliesslich mit Shelly Devices. Mit Aktoren oder Bindings anderer Systeme habe ich das Problem nicht:

Nach wenigen Minuten Betriebsdauer des Raspis benötigt eine Statusänderung eines Shellys (z.B. Shelly 1, 1PM oder 2.5) von ON zu OFF oder vice versa mehrere Sekunden (typischerweise ca. 20 bis 30s.) bis der Status auch in Openhab geändert bzw. ersichtlich ist. Da ich mit der Statusänderung in Openhab Aktionen bei anderen Systemen (z.B. Licht) auslöse, ist dies für mich völlig unbrauchbar.

Wird der Raspi allerdings neu gestartet (z.B. sudo reboot) ist das Problem für eine kurze Zeit behoben und die Zeitverzögerung (Shelly -> Openhabian) liegt unter 1 Sekunde was perfekt ist (und so wie es früher immer war). Nach wenigen Minuten "Up-time" des Raspis ist "der Delay" aber bereits schon wieder wie oben beschrieben (>20s).

Hat jemand eine Idee?

Vielen Dank & beste Grüsse

Remo

PS (am Update Intervall habe ich schon herumprobiert, ohne dauerhafte Lösung)

[udo1toni]

Welche Anbindung nutzt Du, das Shelly Binding oder mqtt?

Da scheint ein Prozess zu spinnen.
Das Verhalten als solches habe ich auch früher schon mit verschiedenen Bindings beobachtet, dies betraf aber immer nur einzelne Snapshots.
Im Zweifel, falls hier niemand eine konkrete Idee dazu hat, empfehle ich das englische Forum.

[Vero Beach]

Danke, ich benutze das Shelly Binding.

[Vero Beach]

gäbe es alternativ eine einfache Möglichkeit auf Version 3.2.x zu "downgraden"? Dort hat nämlich alles einwandfrei funktioniert.

[vviereck]

HI,

bin neu hier im Forum, setze openhab schon seit Jahren ein, wenn auch auf eher geringem Komplexitaetslevel.

Zum Thema:
ich habe mit openhab4 und den Eingängen des Shelly Dimmer 2 das gleiche Phänomen. Habe deshalb gerade auf openhab4 geupdated, das Phänomen besteht aber weiterhin.

Ich habe bisher mqtt im ShellyDimmer nicht aktiviert, folglich wird meines Wissens ColoT verwendet (kenne ich so nicht). Die Einbindung der Shelly‘s läuft über das ShellyBinding.

Hat jemand eine Lösung für dieses Thema gefunden?
Bei mir ändert sich der Status erst nach ca. 60s.

Danke für Tipps.

Gruß Volker

[vviereck]

Kurze Ergänzung:
Setze ich die Thing Status Update Zeit herunter auf 10s, das ist der minimale Wert, erfolgt die Stausaenderung auch entsprechend nach ca. 10s.

Das ist allerdings noch immer deutlich zu lange. Ein Update <1sec brauche ich.

Viele Grüße Volker

[Harka]

Moin,
eine Lösung kann ich Dir nicht anbieten. Wir haben auch einen Dimmer 2, welcher keine Probleme macht. Kannst ja mal die Konfiguration abgleichen. Beim Binding ist "Auto-CoIoT" aktiv, Versionen vom Binding und OH ist auf 4.2.2

Code: Alles auswählen

UID: shelly:shellydimmer2:3c6105fe6fbd
label: Dimmer_Küche
thingTypeUID: shelly:shellydimmer2
configuration:
  eventsCoIoT: true
  deviceIp: 192.168.178.116
  brightnessAutoOn: true
  updateInterval: 60
  eventsButton: false
  eventsPush: false
  eventsSwitch: false

[vviereck]

HI,

danke für die Rückmeldung.
Da es bei meinem Thema um die zeitnahe Rückmeldung der Statusaenderung von SW1 und SW2 geht, habe ich diese Events natürlich aktiviert und wie beschrieben die Status-Update-Zeit auf 10s herabgesetzt, weniger wird leider nicht unterstützt.

Ansonsten sieht die Config absolut genauso aus.

LG Volker

[Harka]

Moin,
ok, jetzt hab ich es auch gesehen
Wir haben nur ein Taster dran. Der Trigger-Channel (relay#button1) reagiert sofort, aber wenn das nicht reicht ...