Hallo Björn!
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
(23-04-2015, 21:37:25)Extrabannies schrieb: 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