Hm-rpc: 2 grundsätzliche Probleme
-
Hallo,
ich habe von Anfang an 2 grundsätzliche Probleme mit hm-rpc - die Auswirkungen sind nicht gewaltig, sondern nur "unschön"
Ich muss alerdings auch direkt zugeben, dass ich die folgenden Problemchen nicht mit der aktuellen Version geprüft habe. Im Change-Log stehen dazu aber auch keine Hinweise.- Wenn man z.B. bei einem Rollladen-Aktor den Level=0 einstellt, dann passiert in Zusammenhang mit Skripten folgendes:
-
es werden Skripte ausgelöst, die auf "=0" reagieren
-
kurze Zeit später werden dann die Skripte ausgeführt, die auf ">0" reagieren, da es einen neuen Level von der CCU gibt
-
wird dann die Position "0" erreicht, werden wieder die Skripte die auf "=0" reagieren ausgeführt.
Wenn man also ein Licht in Abhängigkeit des Levels schaltet passiert folgendes
-
Licht sofort An
-
x Sekunden später: Licht Aus
-
Rollladen erreicht Endpositon: Licht An
Man müsste "irgendwie"
8-) die Events der Rollladen-Aktoren unterdrücken, wenn die Level Änderung von iobroker-intern kommt.- Schaltet man STATE von einem Funk-Schalt-Aktor und wird der neue Zustand nicht erreicht (z.B. weil es zu einem Kommunikationsproblem kommt), dann hat man im iobroker und der CCU unterschiedliche Zustände.
Ich habe mal einen Test mit einem solch fehlerhaften Gerät mit der App "pocketControl" gemacht. Die App bekommt es hin; zeigt also z.B. nach x-Sekunden die Lampe im Zustand "Aus" an, wenn der Ein-Befehl nicht an den Aktor geschickt werden konnte.
Vielleicht mache ich was falsch, vielleicht kann man die 2 Punkte auf eine To-Do Liste setzen oder es gibt einfache "workarounds" ?
Gruß
Georg
-
Hi
zuerst einmal muss man wissen das jeder Datenpunkt in iobroker noch einen „acknowledge/bestätigt“ flag hat. Wenn das „true“ ist stammt der Wert vom Gerät bzw von der ccu in deinem Fall. Bei „false“ ist das ein „wunschwert“ der gesetzt werden soll aber ggf. Noch nicht beim Gerät umgesetzt wurde.
Das hat Auswirkungen auf deine Fragen:
Zu 1.) Schraubfassung deine Skripte nur dann etwas tun wenn der neue Zustand auch bestätigt ist. Wenn du das tust ist das erste „für Aktionäre aus mit =0“ schonmal weg.
Weiterhin haben HM Geräte wie rollladen auch einen Datenpunkt namens „working“ der auf true steht wenn das Gerät „in betrieb“ ist - bei rollladen also wenn er gerade fährt. Also im Skript auch das prüfen und wenn working==true dann halt nix tun. Damit sollte das erledigt sein.
Zu 2.) faktisch ist das korrekt das hier die daten auseinander laufen. Mit der Info zu „bestätigt“ weißt du aber was du gerade vor dir hast … nämlich einen Wert der nicht vom Gerät bestätigt wurde. Damit kannst du wieder was anfangen und in Skripten arbeiten. Für ein device mit so einem Verhalten kann auch Guts ein das ein „getState“ in Skripten für immer den letzten bestätigten wert zurückgibt.
-
ah, danke für den Hinweis - dem geh ich mal bzgl. meiner Skripte nach. Das sollte ein paar Dinge lösen.
Bleibt noch VIS. Der WAF geht steil bergab, wenn VIS anzeigt, dass die Lampe eingeschaltet ist, diese aber aus ist :mrgreen:
-
Wie oft hast Du Kommunikationsprobleme?
-
nicht besonders oft - was die Sache um so schlimmer macht.
