Umstieg von ccu.io und Einarbeitung - Erste Fragen
-
hat mir keine ruhe gelassen:
ES GEHT…
Hab mir wlan-zugang besorgt und ne VPN Verbindung nach hause aufgebaut.
Version aktualisiert und siehe da,
ich kann jetzt ioBroker laufen lassen, ohne das mir das WebUI einfriert,
zumindest in einem ersten Kurztest
DANKE!!!
Ich werde mich jetzt weiter ins Scripting einarbeiten
-
so, hier die Doku-Aktualisierung, die ich versprochen hatte,
evtl kann nochmal jemand drüberschauen und homoran sie im wiki
aktualisieren?
Wir sollten beim Usertreffen mal klären wie das mit den Zugriffsrechten ist,
dann könnt ich z.B. die Doku direkt im Wiki ändern, wenn das gewünscht ist…
268_hm-rfd_beschreibung.odt -
so, hier die Doku-Aktualisierung, die ich versprochen hatte,
evtl kann nochmal jemand drüberschauen und homoran sie im wiki
aktualisieren?
Wir sollten beim Usertreffen mal klären wie das mit den Zugriffsrechten ist,
dann könnt ich z.B. die Doku direkt im Wiki ändern, wenn das gewünscht ist…
Sieht wirklich verständlich (mindestens für mich :D ) und gut detailliert aus. Vielleicht kann man das noch irgendwie beschreiben, weil die Aussage:> Check init trigger: Virtuelle Taste der CCU, mit der eine einmalige Überwachung ebenfalls ausgelöst werden kann. `
nicht ganz korrekt ist.Über hm-rega (nicht hm-rpc) wird alle X Sekunden die Virtuelle Taste angetriggert. Damit kann man sicher sein, dass innerhalb X Sekunden ein Ereignis auf jeden Fall von CCU kommt.
Leider ist es nicht möglich so ein Trigger über hm-rpc auszulösen und Ereignisüberwachung wird nur mit der Zusammenhang mit hm-rega funktionieren.
Im Fall, dass hm-rega nicht geht (z.B. homegear) wird dann die Ereignisschnittstelle alle X Sekunden neu initialisiert. Das sollte, eigentlich, kein Problem sein, man muss nur Intervall ein bisschen höher setzten, z.B. 600 Sekunden (10 Minuten).
X Sekunden kann man über "Check init interval" einstellen. Virtuelle Taste kann man über "Check init trigger" einstellen.
Übrigens, richtiger Name für die Virtuelle Taste ist "****BidCos-RF.****BidCoS-RF:50.PRESS_LONG". Das wird momentan im Kode umgewandelt und die neue Versionen von hm-rpc werden schon richtigen Namen haben.
Edit: Momentan darf jeder wiki editieren. Wenn Mist ist, dann kann man die Änderungen wieder rückgängig machen.
Edit2: BTW: Es ist nicht nötig die IP Adressen zu retuschieren. Die 192.168… Adressen sind lokale Adressen und um die zu erreichen muss man bei dir zuhause in deinem Netz sitzen.
-
Über hm-rega (nicht hm-rpc) wird alle X Sekunden die Virtuelle Taste angetriggert. Damit kann man sicher sein, dass innerhalb X Sekunden ein Ereignis auf jeden Fall von CCU kommt.
Leider ist es nicht möglich so ein Trigger über hm-rpc auszulösen und Ereignisüberwachung wird nur mit der Zusammenhang mit hm-rega funktionieren.
Im Fall, dass hm-rega nicht geht (z.B. homegear) wird dann die Ereignisschnittstelle alle X Sekunden neu initialisiert. Das sollte, eigentlich, kein Problem sein, man muss nur Intervall ein bisschen höher setzten, z.B. 600 Sekunden (10 Minuten).
X Sekunden kann man über "Check init interval" einstellen. Virtuelle Taste kann man über "Check init trigger" einstellen.
Übrigens, richtiger Name für die Virtuelle Taste ist "****BidCos-RF.****BidCoS-RF:50.PRESS_LONG". Das wird momentan im Kode umgewandelt und die neue Versionen von hm-rpc werden schon richtigen Namen haben. `
Dann hab ich es noch nicht richtig verstanden:
a) wenn hm-rega die virtuelle Taste triggert, sollte sie nicht dann in hm-rega konfiuriert werden? warum muss hm-rpc diese Taste dann kennen?
b) wenn es kein hm-rega gibt (wie ja auch bei meinem Testsystem zur Zeit) wird quasi alle x Sekunden (check init interval) die Ereignisschnittstelle neu initialisiert.
warum muss die neu initialisiert werden? Beendet sich diese nach einer gewissen Zeit von inaktivität oder wie?
Wie kennt ihr das Verhalten dieser Schnittstelle, gibt es da von EQ-3 eine Beschreibung dafür oder habt ihr das über reverse-engineering bzw trial & error rausgefunden?
Brauch noch etwas input, dann überarbeite ich das Dokument nochmal,
PS: Der Screenshot ist noch der alte, ich weis nicht ob du die Oberläche wie im Thread oben angedeutet umbenennen willst?
-
a) wenn hm-rega die virtuelle Taste triggert, sollte sie nicht dann in hm-rega konfiuriert werden? warum muss hm-rpc diese Taste dann kennen? `
Es kann sein, dass jede hm-rpc Schnittstelle eigene Variable triggern sollte.
@tschombe:b) wenn es kein hm-rega gibt (wie ja auch bei meinem Testsystem zur Zeit) wird quasi alle x Sekunden (check init interval) die Ereignisschnittstelle neu initialisiert.
warum muss die neu initialisiert werden? Beendet sich diese nach einer gewissen Zeit von inaktivität oder wie? `
Wenn PC schlaffen geht, oder Netzwerkverbindung längere Zeit nicht da war und dann wieder hergestellt wurde, oder CCU neu gestartet wurde, dann vergisst CCU die eingegebene Adresse von ioBroker und ioBroker bekommt keine Ereignisse mehr.Wie kennt ihr das Verhalten dieser Schnittstelle, gibt es da von EQ-3 eine Beschreibung dafür oder habt ihr das über reverse-engineering bzw trial & error rausgefunden? `
http://www.eq-3.de/Downloads/PDFs/Dokum … 02__2_.pdf Kapitel 2PS: Der Screenshot ist noch der alte, ich weis nicht ob du die Oberläche wie im Thread oben angedeutet umbenennen willst? `
Ja Ich habe das schon geändert, nur nicht eingecheckt. -
ok, danke für die Info,
dann lese ich jetzt erstmal die Spezifikation.
gibts übrigens in einer neueren Version:
-
Was das triggern der virtuellen taste angeht habe ich das bei ccu.io genau anders herum verstanden.
Damit Rega nicht alle paar Sekunden abgefragt wird (hier werden ja hpts. die Variablen geholt) kann man auf der CCU diese virtuelle taste auslösen, wenn sich eine variable ändert.
Dann kann der wert für das automatische abfragen auf z.B. 15 Minuten gestellt werden.
Das schont die CCU.
Gesendet von meinem Cynus T7 mit Tapatalk
-
Was das triggern der virtuellen taste angeht habe ich das bei ccu.io genau anders herum verstanden.
Damit Rega nicht alle paar Sekunden abgefragt wird (hier werden ja hpts. die Variablen geholt) kann man auf der CCU diese virtuelle taste auslösen, wenn sich eine variable ändert.
Dann kann der wert für das automatische abfragen auf z.B. 15 Minuten gestellt werden.
Das schont die CCU.
Gesendet von meinem Cynus T7 mit Tapatalk `
Das auch. Ich stelle gerade fest, dass diese Feature auch nicht implementiert ist, obwohl in Konfig vorhanden ist.
-
Gibt es nicht einen "robusteren" Mechanismus, um z.B. einen Sleep vom PC oder
Verbindungsabbruch zu erkennen und dann das Init neu zu schicken als das
pauschal alle X Sekunden zu tun?
Evtl. können wir da mal jemanden von EQ-3 auf dem Usertreffen fragen?
So richtig hab ich das glaub ich immer noch nicht verstanden :oops:
PS: mir ist aufgefallen, wenn man ioBroker laufen lässt und hm-rdf
KEINE Verbindung zur CCU hat, bekomme ich harte Exceptions im Logfile angezeigt,
weis nicht ob das so gewollt ist:
-
Nein gewollt ist das nicht !
Ich hatte auch schonmal daran gedacht das ccu log auf Fehler mit der ip von iobroker zu überprüfen und dann zu reagieren.
Aber es gibt einfach zuviel zu tun.
Vieleicht magst du das machen.
-
` > Gibt es nicht einen "robusteren" Mechanismus, um z.B. einen Sleep vom PC oder
Verbindungsabbruch zu erkennen und dann das Init neu zu schicken als das
pauschal alle X Sekunden zu tun? `
Wenn das existierte würden wir natürlich das implementieren. Es gibt immer killer-case: CCU macht neustart. Und das kannst du gar nicht erkennen, ausser Ereignisse zu beobachten. -
Ich habe heute mit hq im homematic-chat das Problem mal diskutiert.
Es GIBT eine elegantere Lösung. In dem aktuellsten Schnittstellendokument der XML-API:
http://www.eq-3.de/Downloads/Software/H … pc_API.pdf
gibt es die Funktion "ping" die mit einem "pong" antwortet.
Damit sollte ein Keepalive - Mechanismus realisierbar sein.
Idee ist: Es gibt eine konfigurierte Intervallzeit.
Wenn das letzte Ereignis das empfangen wurde, länger zurückliegt als die Intervallzeit
wird das ping-Kommando gesendet.
Antwortet die CCU nicht korrekt mit einem "pong" innerhalb der Intervallzeit,
wird der init erneut versucht.
Ich würd mal versuchen bei Gelegenheit mir einen gitclone zu ziehen und mir das mal anschauen
-
ich hab jetzt mal versucht, in dem Code etwas durchzusteigen.
Hauptsächlich kämpfe ich eigentlich mit JavaScript / node.js und der
Callback-hell. Ich weis nie genau wann welche Funktion aufgerufen wird :oops:
Eigentlich will ich den Ping/Pong Mechanismus in hm-rpc implementieren wie er in
dem aktuellen XMLRPC-Dokument von eq-3 beschrieben ist und den ganzen init-hack
rausschmeissen, aber ich finde nicht so richtig den Ansatzpunkt.
Kann man sich evtl beim Usertreffen mal ne halbe Stunde bzw Stunde zusammensetzen
und das mal in einer Pair-Progamming session anprogrammieren?
Ich würd mein Notebook mit einer Entwicklungsumgebung mitbringen…
-
Ja. Können wir gerne machen.
-
das wär super!!!!!
Momentan versuch ich mich soweit möglich in den rpc adapter einzuarbeiten und
auch beim ping schon vorzuarbeiten.
Aktuell schiess ich aber immer meine CCU damit ab
