openhabforum.de

Hallo Zusammen,

bisher war ich stiller Mitleser und habe mittlerweile auch eine Reihe von Rules im Openhab hinterlegt. Bisher hat das auch alles ganz prima geklappt, bis ich heute morgen das Openhab kurz herunterfahren musste. Seitdem es wieder gestartet ist, bekomme ich keine "LONG_PRESSED" Events der Shelly's mehr im Openhab. Ich habe mit diesen LONG_PRESSED viele meiner physischen Taster im Haus doppelt belegt und bin nun am verzweifeln.

Weiß jemand, ob sich da irgendwas im Hintergrund geändert haben könnte? Habe mal versuchshalber einen der Shelly's auf MQTT umgestellt, dort bekomme ich die LONG_PRESSED Events noch angezeigt.

Mein bisheriges Setup ist:

OH 3.1
Shelly Binding 3.1

Ich habe eigentlich vor dem Herunterfahren des OH auch nichts geändert, mit der Ausnahme, dass ich die Persistenz auf JDBC mit MariaDB umgestellt habe (könnte mir aber ehrlich gesagt nicht erklären, was es damit zu tun haben sollte).

Vielleicht kann mir ja jemand helfen,

Danke und Grüße

Mir wäre jetzt nicht bekannt, dass es Änderungen gab. Insbesondere bist Du aber ohnehin auf einer (relativ) alten Version unterwegs, da müsstest Du schon selbst Hand anlegen, damit sich dort etwas am Verhalten ändert.

Leider habe ich spontan keine Idee, was diesen Effekt auslösen könnte.
Hast Du eine Sicherung der Konfiguration?

Hast Du mit openHABian aufgesetzt? Wenn ja, was steht bei Dir in der Datei /etc/apt/sources.list.d/openhab.list? Der Name der Datei kann leicht variieren, openhab sollte im Dateinamen vorkommen, Pfad und Endung .list sind hingegen fix.

Danke für die schnelle Antwort. Mein Openhab läuft in einem Docker Container auf Synology. Die Configuration ist entsprechend ins Dateisystem vom NAS gemappt.

Was ich komisch finde ist, dass ich die Shelly auch noch aus Openhab heraus bedienen kann, lediglich keine Trigger Events oder ähnliches im event LOG mehr auftauchen. Ebenso schlagen Änderungen die ich über die Shelly App (z.B. Licht anschalten) sehr spät erst im Event Log landen. Ich könnte ja mal versuchen einen zweiten Docker Container aufzusetzen und dort die Config Files entsprechend rein zu mappen, ob das evtl. etwas hilft.

Was hätte ich in der Datei /etc/apt/sources.list.d/openhab.list finden können? Und gibts was äquivalentes auch im Docker Setup.

Eine Docker Installation funktioniert grundlegend anders.

Hast Du den Container schon mal neu erstellt? Das ist ja mit wenigen Handgriffen erledigt.

Das werde ich die Tage mal machen.

Ist halt wie so oft, man setzt was auf und hat eigentlich nicht recht durchstiegen wie das Konzept (in dem Fall Docker) grundlegend funktioniert. Aber wenn ich es richtig verstehe, muss ich nur die "gleichen" Config Ordner wieder in den neuen Container mappen und dann starten oder? Das könnte ich auch gleich mit dem neuen Image von Openhab machen (also ein Upgrade von 3.1 auf die aktuelle Version)?!

Davor hatte ich bisher so ein wenig Respekt, weil mittlerweile doch etwas an Konfiguration in der Installation steckt. Aber die Config Files kann ich ja vor der Aktion einmal weg sichern.

Hi,

Aber wenn ich es richtig verstehe, muss ich nur die "gleichen" Config Ordner wieder in den neuen Container mappen und dann starten oder? Das könnte ich auch gleich mit dem neuen Image von Openhab machen (also ein Upgrade von 3.1 auf die aktuelle Version)?!

genau das ist das Schöne am Container einfach stoppen, neues Image nehmen und wieder starten, die Konfigurationen werden ja als Volumes gemappt und bleiben daher gleich. Vorher ein Backup ist immer gut! Ich bin damit problemlos inzwischen auf openHAB 3.3.0.M2.
Wenn's nicht klappt könntest Du ja auch wieder mit dem alten Image starten ("downgrade"), die Konfigurationen scheinen sich seit 3.1 nicht verändert zu haben...

Meine (wenigen) Shelly laufen über MQTT, daher kann ich Dir zum Shelly Binding leider nicht weiterhelfen

rfu

Wenn Du einen Docker Container beendest und neu startest, so wird er immer so geöffnet, als wäre er neu.
Deshalb müssen Konfiguration und weitere Daten außerhalb des Containers geparkt werden, das geschieht über Volumes.
Letztlich sind das Ordner des Host Systems, welche in den Containern verfügbar sind, und zwar an einer beliebigen Stelle im Dateisystem des Containers. Dafür gibt es das Mapping in der Konfigurationsdatei für den Container.

Gewöhnlich wird man zur Verwaltung der Container z.B. Portainer einrichten (gibt‘s als Docker Container…). Mit Portainer gehst Du in die Liste der Container, klickst auf Deinen openHAB-Container und wählst „neu erstellen“ aus, dann wird der Container runtergefahren und wieder gestartet. Wenn Du die entsprechende Option auswählst, holt Portainer bei der Gelegenheit auch den aktuellen Container von DockerHUB ab. Mit Docker ist also das Upgrade von Version zu Version mit einem Klick zu erledigen. Lediglich Änderungen der Konfiguration, die durch das Upgrade notwendig werden, muss man dann noch händisch erledigen.


Gesendet von iPad mit Tapatalk

Danke für die Viele Unterstützung. Ich werde das ausprobieren und berichten.

Trotzdem verstehe ich nicht, warum die Long_Pressed Trigger Events nicht mehr durchkommen (ganz generell sehe ich nur noch sehr wenig Aktivität der Shelly's im Event log im Vergleich zu bevor). Es sieht für mich fast so aus, als würden die Änderungen nicht mehr den Weg zu Openhab finden, aber um das genauer nachvollziehen zu können verstehe ich leider zu wenig von dem CoAP (CoLoT) Protokoll dass die Shelly's da nutzen um die Änderungen der Welt mitzuteilen.

Hab schon überlegt ob es was mit der Unifi USG oder meinem Netzwerk zu tun haben könnte, aber ehrlich gesagt habe ich daran überhaupt nichts geändert. Außer das ich die USG geplant und das NAS versehentlich heruntergefahren hatte.

Tatsächlich kann ein Neustart schon dazu führen, dass der Kontakt zwischen den beteiligten Geräten nicht mehr korrekt aufgebaut wird. Aber gewöhnlich sollte ein Neustart der Komponenten dann auf jeden Fall ausreichen.

Was CoAP betrifft, so scheint mir, ist das leider ein totes Pferd, da beim Hersteller in der aktuellen Firmware dieses Protokoll nicht mehr eingesetzt wird.

Guten morgen,

habe jetzt gestern Openhab in einem neuen Container gestartet (direkt auf V3.2), leider keine Besserung des Verhaltens. Auch ein kompletter Neustart aller Ressourcen sowie eines Shelly's zur Probe hat das Problem nicht behoben.

Ich denke, wenn Coap ohnehin keine wirkliche Zukunft mehr zu haben scheint, schaue ich mir die Implementierung über MQTT mal an. Dort habe ich ja schon gesehen, dass ein Long_Pressed Event sofort durchschlägt. Frage mich dabei aber, wie ich wiederholte Long_Pressed Events erkennen kann, da der Status im MQTT Explorer ja bestehen bleibt (bis er von einem Short_Pressed abgelöst wird).

Vielleicht schaue ich mir den Netzwerkverkehr auch noch mal genauer an bevor ich zu MQTT umstelle, hätte schon gerne verstanden, warum die Info nicht mehr im OH ankommt.