OpenHAB RWE Smarthome Binding

[ollie]

Hallo profigriller,

ich habe die Regel bei mir nachgebaut - mit drei RST. Hier funktioniert es auch nicht perfekt. Allerdings ist meine Beobachtung, dass die Werte in der RWE-Silverlight-App korrekt sind, nur OpenHAB durcheinander gekommen ist.

Ich habe auch eine Vermutung, woran es liegt - insbesondere in Deinem Fall, da Du deutlich mehr Geräte hast als ich.
Es wird wahrscheinlich daran liegen, dass eine Veränderung, die an die Zentrale geschickt wird, umgesetzt wird, aber dann von der Zentrale als Notification wieder zurückgemeldet wird. Und hier läuft dann die Synchronität auseinander, weil die Notification der ersten Schaltung parallel zur zweiten läuft. Je mehr Geräte man hat, umso wahrscheinlicher. Bei mir geht es mal gut, mal in die Hose.

Das muss ich mir in Ruhe ansehen, sollte aber hinzukriegen sein. Ich versuche es am Wochenende zu lösen, sofern es hoffentlich auch daran liegt.

Gruß
Ollie

[profigriller]

Hallo Ollie,
ich hatte das missverständlich beschrieben:
Du hast geschrieben:
"... Allerdings ist meine Beobachtung, dass die Werte in der RWE-Silverlight-App korrekt sind, nur OpenHAB durcheinander gekommen ist."

Das ist bei mir auch so. Openhab ist durcheinander, der Rest passt. Das bedeutet halt leider auch, dass die rules in openhab durcheinander sind.

Es freut mich, dass sich das nachstellen lässt

Ich drücke Dir die Daumen, dass die Problemsuche und Änderung nicht zu aufwendig ist.

Viele Grüße,
profigriller

[Extrabannies]

Hi Olli,
Nochmals danke für deine klasse Arbeit.
Kannst du mir mit der Frage helfen, wie du die Verbindung mit der SH-Zentrale aufrecht erhältst, um das dauernde Login und vor allem das Hochladen der Konfiguration zu vermeiden? Auf deiner Web-Seite hast du was angedeutet, leider hilft mir das jedoch bei meinem Problem nicht weiter.
Wenn du helfen könntest, wäre das klasse.
Danke schon mal.
Herzliche Grüße
Björn

[ollie]

Hallo Björn!

Kannst du mir mit der Frage helfen, wie du die Verbindung mit der SH-Zentrale aufrecht erhältst, um das dauernde Login und vor allem das Hochladen der Konfiguration zu vermeiden? Auf deiner Web-Seite hast du was angedeutet, leider hilft mir das jedoch bei meinem Problem nicht weiter.
Wenn du helfen könntest, wäre das klasse.

Grundsätzlich läuft das so:
1. Man schickt einen Login-Request und erhält bei Erfolg eine gültige Session-ID zurück. Die Session läuft bis zum Logout oder Timeout, letzteres ist gefühlt nach ca. 6h.
2. Sämtliche Aufrufe um die Konfiguration zu laden oder Geräte zu schalten macht man dann mit Hilfe der Session-ID.
3. Die Konfiguration lädt man eigentlich nur am Anfang einmal und baut daraus sein Objektmodell auf.
4. Gleiches gilt für den Gerätezustand, den man am Anfang einmal lädt und das im Objektmodell speichert. Veränderungen bekommt man dann über Notifications mit.
5. Dazu muss man sie für die diversen Notifications registrieren und zwar mit der oben erhaltenen Session-ID. Die wichtigste hier ist die LogicalDeviceStateChangedNotification. Man erhält dann so lange die Nofications, bis die Session-ID ausläuft oder man sich ausloggt.
6. Ist man für Notifications registriert, muss man regelmäßig den getNotificationRequest aufrufen bekommt dann immer mitgeteilt, wenn sich ein Zustand geändert hat.
7. Den veränderten Zustand speichert man in seinem Objektmodell und ist somit wieder aktuell.

Zu beachten ist, dass die getNotificationsabfrage auch ohne Session-ID machbar ist. Nur wenn man sich vorher nicht mit einer gültigen Session-ID einmalig für die Notifications registriert hat, bekommt man immer nur ein leeres Ergebnis zurück. Hier ist also die Reihenfolge wichtig: Einloggen, Session-ID speichern, Konfiguration laden, für Notifications registrieren, Gerätestatus einmal komplett abfragen und dann erstmal nur auf Notifications lauschen. Läuft die Session-ID ins Timeout, bekommt man eine entsprechende Rückmeldung bei getNotifications und muss sich dann neu einloggen. Das Binding macht das auch, sonst wäre spätestens nachts Schluss....

Hilft Dir die Erklärung?

Gruß
Ollie

[devnull]

Grundsätzlich läuft das so:
1. Man schickt einen Login-Request und erhält bei Erfolg eine gültige Session-ID zurück. Die Session läuft bis zum Logout oder Timeout, letzteres ist gefühlt nach ca. 6h.
...
Gruß
Ollie

Edit: hat sich erledigt

[ollie]

@profigriller: Übergangslösung für Dein Problem könnte sein, einfach eine Pause in die rule zwischen die Einzelitems einzuführen: Thread::sleep(3000)

Ich bastle derzeit weiter...

Gruß
Ollie

[profigriller]

Hallo Ollie,
vielen Dank für Deine Nachricht. Der Hauptgrund zum Einsatz von openhab war die Verwendung des google Calendar plugin. Da habe ich leider null Einfluss auf das Timing der Kommandos.
Wie geschrieben kommen die Kommandos ja durch. Insofern habe ich aktuell kein großes Problem mit der Integration.

Ich warte mal, ob Du dazu einen Fehelr findest und teste natürlich auch gerne wenn es was zu testen gibt.

Viele Grüße,
profigriller

[ollie]

Das Kommando ist doch ein normales Rules Kommando. Ich dachte jetzt, dass du es einfach in die Termineinträge zwischen die Kommandos schreiben kannst. Das geht nicht?

Ansonsten bin ich dran am Fix...

LG Ollie

[Extrabannies]

Hi Olli,
Danke für die Antwort (Punkte 1 - 4 habe ich realisiert - siehe meine txt Dateien im vorherigen Beitrag).
Bezüglich der Notifications habe ich dies auch verstanden.
Kann ich irgendwie die Session auch für die Aktoren-Befehle cachen, oder geht dies "nur" für Notifications?
Und hast du evtl. ein Beispiel in php?
Sorry, bin Anfänger in dem Gebiet und komme nur über "trial and error" zum Ziel.
Cheers
Björn

[profigriller]

Hallo Olli,
ich habe das mal probiert. Gcal kann das sleep Kommando nicht verarbeiten. Nach meinem Verständnis hat gcal einen limitierten und anderen Befehlssatz als die rules.

Im openhab.log file findet sich dazu folgendes:


2015-04-25 11.30:11.359 [DEBUG] [o.i.g.i.util.ExecuteCommandJob] - About to execute CommandJob with arguments [Thread, , , sleep, , 3000.0, , ]

2015-04-25 11.30:11.360 [INFO ] [o.i.g.i.util.ExecuteCommandJob] - update <item> <state> - sends a status update for an item
send <item> <command> - sends a command for an item
status <item> - shows the current status of an item
items [<pattern>] - lists names and types of all items matching the pattern
say <sentence to say> - Says a message through TTS on the host machine
> <script to execute> - Executes a script


Viele Grüße,
profigriller