Auslesen des Status von Geräten in der SHC

... das "?" erscheint meiner Erfahrung nach nur nach einem Kaltstart (power off / power on) der Zentrale.
Das sollten V2-Nutzer ja aber tunlichst vermeiden.
Ob das Fenster / die Tür offen oder zu ist kann man dann nicht erkennen.

Bei einem Warmstart über die Hilfe werden die Zustände der WDS abgespeichert und dann wieder geladen. Sollte sich ein Zustand während des Neustarts ändern, wird er dann falsch angezeigt.

Wie das bei einer V2 nach ausschalten / einschalten über den Power-Button verhält kann ich gar nicht sagen.

Eine leere Batterie ist kein Grund für ein "?". WDS sind "Tiefschläfer", werden also nur aktiv wenn sie eine Zustandsänderung erkennen und melden auch nur dann ihren Status. an verbundene Aktoren und die Zentrale Daraus folgt aber auch, dass leere Batterien unter Umständen bei längerer Nichtbenutzung gar nicht erkannt werden und damit auch der Status nicht aktualisiert wird.

Es gab immer mal Anregungen den Zustand auch manuell setzen zu können. Diese wurden aber nie umgesetzt, wohl auch weil eben damit kein logisch sicheres Ergebnis zu erzielen ist.

Was wohl bei einem "?" sicher erkannt wird ist eine Zustandsänderung. Für einen Trigger (wird geöffnet , wird geschlossen) in einem Szenario ist also das "?" kein Problem, für eine Bedingung (ist geöffnet , ist geschlossen) schon.

Quote from Dirk_L

Die einzige Chance wäre also, das WDS einmal zu wecken, was wohl zZ nicht vorgesehen ist. Besteht da eine theoretische Chance?

... ich denke nicht. Im Tiefschlaf hilft nur "rütteln".

bei mir steht das oft wenn Fenster lange Zeit nicht geöffnet werden zb. Küche hab ich 3 Fenster wo meist nur 1 offen ist

Quote from Newfo2016

bei mir steht das oft wenn Fenster lange Zeit nicht geöffnet werden zb. Küche hab ich 3 Fenster wo meist nur 1 offen ist

... das konnte ich ohne Kaltstart der Zentrale noch nie beobachten.

Hallo zusammen,

ich habe mir das eben mal auf API-Ebene angesehen.

Leider gibt es keine (dokumentierte) Möglichkeit, einem Fenstersensor einen Status "unterzujubeln".

Wenn man einen SHC korrekt bootet, dann stellt er danach die vorherigen Zustände der Fenster wieder her. Wenn man einfach nur den Stecker rauszieht und wieder reinmacht - dann nicht.

Offensichtlich speichert also bei ShutDown die Zustände irgendwo hin und kann diese dann auch beim Hochfahren wieder den einzelnen Devices und Capabilities zuordnen. Das muss allerdings proritär geschehen und leider nicht über die API.

Ansonsten hätte ich gerne eine Funktion in den LSHC+ eingebaut, mit der man z. B. auf Knopfdruck "alle Fenster auf ZU" oder einzelne usw. hätte ansteuern können...

Leider nicht möglich, es sei denn, irgend ein Mäuschen flüstert mir den nicht dokumentierten API-Call zu....

Gruß Ralph

Quote from Ralph

Wenn man einen SHC korrekt bootet, dann stellt er danach die vorherigen Zustände der Fenster wieder her. Wenn man einfach nur den Stecker rauszieht und wieder reinmacht - dann nicht.

Und das war imho nicht immer so... Kann mich an so manches FW-Update erinnern, dass für alle Fenster in einmal auf- und zumachen endete .. beim Übertragen der Konfiguration auf eine Ersatzzentrale auch... Aber das passt ja dann auch....

Quote from Ralph

Leider nicht möglich, es sei denn, irgend ein Mäuschen flüstert mir den nicht dokumentierten API-Call zu....

Mach lieber was sinnvolleres (was man auch sniffen kann) so wie den Call für Szenario aktivieren/deaktivieren 😉

🖖🏻

Quote from MKR

Mach lieber was sinnvolleres (was man auch sniffen kann) so wie den Call für Szenario aktivieren/deaktivieren 😉

...das ist gar kein Problem ....brauchst Du das ?

Im OH-Binding wäre das super 😉

Alternativ als curl aus OH ... 🤔

Quote from MKR

Alternativ als curl aus OH ... 🤔

Naja....dann ist das ja nichts für den LSHC+

Um das mit curl aus OpenHab zu machen, müsste man eine DSL-Rule schreiben, die sich zuerst am SHC anmeldet und den AccessToken abholt. Anschließend müsste man dann das Szenario aktivieren oder deaktivieren.....

Muss ich mir mal anschauen....

Quote from MKR

Alternativ als curl aus OH ... 🤔

Ich habe mir das mal angesehen.

Direkt mit der Action sendHttpPostRequest in OpenHAB geht es nicht, weil da irgendwie die Antwort nicht rübergeleitet wird.

Ein Aufruf von cURL über OpenHAB ist auch ein furchtbares Gefrickel....weil man hier ständig die Ausfrufezeichen escapen muss......ein fürchterliches Gehampel....und das nur um einen Access-Token abzuholen...

Da hab ich keinen Bock drauf, stundenlang rumzufrickeln....kann gerne ein anderer versuchen

Ja das hab ich mir nach dieser Diskussion hier auch nicht anders erwartet...

Aber Sven mag ich nicht fragen, der ist von dem Binding glaub ich genervt genug 😉

Quote from MKR

Aber Sven mag ich nicht fragen, der ist von dem Binding glaub ich genervt genug 😉

...im OH-Binding ist für Szenarien überhaupt gar keine Infrastruktur enthalten....das dort umzusetzen ist m. E. keine Kleinigkeit.

Es im LSHC+ umzusetzen, wäre einfach.....bringt aber dort m. E. nichts....

Der LSHC+ soll ja keine Ersatzoberfläche werden, sondern sich um Dinge kümmern, die man sonst nicht machen kann....

Ich überlege gerade, wohin wir das Stück Konversation hier verschieben ... Oder löschen?

Zurück zum Thema: kann man das nicht "probieren" mit "Set"... Oder zum Beispiel sniffen, wie eine Änderung eines Dimmwertes an die API "gecallt" wird🤔

Das habe ich alles schon versucht - wird von der API abgelehnt

Macht auch Sinn 🙈