Umstieg von ccu.io und Einarbeitung - Erste Fragen
-
Hi,
Frage 1:
ich benötige ja 2 hm-rfd instanzen, einmal für wired und einmal für Funk
benötige ich auch eine hm-rega instanz? das ist mir nicht ganz klar, da ich ja eigentl. nur
Kommunikation zu den Aktoren / Sensoren machen möchte? `
In deinem Fall ist hm-rega nützlich, um Räume und Funktionen von deinen Aktoren aus CCU zu übernehmen.Sonst brauchst du das nicht. Kannst du sogar nach dem ersten Anlauf wieder deaktivieren.
Wir haben noch das Konzept mit der Zuweisung von Räumen und Funktionen nicht ganz bequem gemacht, deswegen wenn es vorhanden ist, übernehmen aus CCU mit hm-rega.
Frage 2:
soll ich als Kommunikation BIN-RPC oder XML-RPC fahren? `
Laut HQ, ist "bin" noch ziemlich buggy. Ich empfehle xml zu benutzen. Mindestens weiß ich, das es funktioniert.Frage 3:
was bedeten die Hacken beim hm-rpc adapter:
-
Init?
-
Check init
-
Initiiere Geräte neu (einmalig) `
Init? (Das wollte ich auch bei HQ fragen, deswegen steht da auch Fragezeichen)
Reverse engineering hat gezeigt, dass es sich hier um "init" Kommando handelt. Dass CCU bei ioBroker die Ereignisse selbst meldet. Deswegen es ist nötig, "Init" zu setzten, um die Ereignisse von CCU bekommen zu können. (Kann jemand das in Doku übernehmen?)
Check init
Ich habe jetzt gerade gesehen, dass es gar nicht implementiert ist. Die Idee war, CCU muss alle X Sekunden ein Event schicken. Falls Ereignis X * 2 Sekunden nicht da ist, dann muss man neu "init" Kommando senden. Werde jetzt genauer schauen.
Initiiere Geräte neu
Es kann sein, dass du in CCU die neue Geräte hinzugefügt oder alte gelöscht hast. Um diese Änderungen in hm-rpc zu bekommen muss du dieses Häkchen setzten, damit hm-rpc alle Geräte neu raus liest. Sonst wird es nicht gemacht, auch bei Neustart von hm-rpc.
Frage 4:
wird da jetzt dann gepollt oder kommen Events von der CCU2
Ich meine bei ccu.io wurde das doch irgendwann mal von polling auf events umgestellt, oder?
ist das bei iobroker auch so? `
Die Variablen (die du nicht hast) aus hm-rega werden gepollt. Alle andere werden gemeldet (natürlich wenn "Init?" gesetzt ist).Frage 5:
Beim Herumspielen (Installation auf einem Windows Rechner) mit den Scripten ist mir
aufgefallen, das nach einer gewissen Zeit der WebUI der LXCCU nicht mehr reagiert hat???
Ich kann bisher keinen direkten Zusammenhang sehen, aber es scheint so, als ob ioBroker dafür
verantwortlich ist.
Ich hab dann die CCU2 neu gestartet, ioBroker beendet und anschl. lief alles wieder korrekt. `
Sehe oben "Check init" Problem. Das passiert auch, wenn PC z.B. im Schlaff war.Während ich mit ioBroker experimentiere läuft ccu.io auf einem Raspi parallel weiter, das sollte ja
aber kein Problem sein, oder? `
Sollte normalerweise kein Problem sein. Wenn ich aber 3 oder mehr Instanzen von ccu.io/ioBroker starte, irgendwann kann CCU mit so viele Clients nicht umgehen.Was sollte ich zu Diagnosezwecken beim nächsten mal (hab nur ein Live-System
) sichern?ioBroker - log? ccu2 - log? `
Es reicht nur /opt/iobroker/log/iobroker.log zu sichern. -
-
Super, danke bluefox für die Erläuterungen,
jetzt sind mir ein paar dinge klar geworden.
aber ich hab gleich noch ein paar Fragen dazu
Ich würde die Doku entspr. anpassen und die Info
homoran zukommen lassen, so haben wir das auch bei
der Windows Installations-Doku gemacht…
Hier meine ergänzenden Fragen um sicherzustellen das ich alles korrekt verstanden hab:
Check init
Ich habe jetzt gerade gesehen, dass es gar nicht implementiert ist. Die Idee war, CCU muss alle X Sekunden ein Event schicken. Falls Ereignis X * 2 Sekunden nicht da ist, dann muss man neu "init" Kommando senden. Werde jetzt genauer schauen. `
d.h. die Funktion wirst du implementieren? hat das was mit einem "sauberen" an und abmeldender Events zu tun? Mir ist ein bisschen unklar, wie der Event-Mechanismus funktioniert?
Woher weis die CCU denn das sie Ereignisse schicken soll? Ist das ein Feature das die CCU von haus aus kann?
Initiiere Geräte neu
Es kann sein, dass du in CCU die neue Geräte hinzugefügt oder alte gelöscht hast. Um diese Änderungen in hm-rpc zu bekommen muss du dieses Häkchen setzten, damit hm-rpc alle Geräte neu raus liest. Sonst wird es nicht gemacht, auch bei Neustart von hm-rpc. `
d.h. der Haken muss dann gesetzt werden, wenn man neue Aktoren / Sensoren an die CCU anlernt.wäre es dann evtl ein schönes Feature, wenn der Haken wieder automatisch zurückgesetzt wird?
Oder man hat eher so etwas wie einen Button, um das Einlesen der neuen Geräte zu triggern?
Frage 5:
Sehe oben "Check init" Problem. Das passiert auch, wenn PC z.B. im Schlaff war. `
Ist das also ein bekannter "Bug"?Wird das gefixt?
Oder gibt es einen "Workaround"?
DANKE für deine Erläuterungen
-
noch eine Anmerkung zu der Bezeichnung "Init"
Wäre es nicht sinnvoller, dies in "Events" / "Ereignisse" umzubenennen
etwa so:
-
d.h. die Funktion wirst du implementieren? `
Wird heute Abend oder morgen schon gemacht. Wenn ich wieder fitter bin.
@tschombe:hat das was mit einem "sauberen" an und abmelden der Events zu tun?
Mir ist ein bisschen unklar, wie der Event-Mechanismus funktioniert?
Woher weis die CCU denn das sie Ereignisse schicken soll? Ist das ein Feature das die CCU von haus aus kann? `
Wenn ioBroker mit "init" Kommando eigene IP und Port zu CCU sagt, dann sendet CCU jede Änderung an dieser Adresse. Das kann CCU "out of the box".wäre es dann evtl ein schönes Feature, wenn der Haken wieder automatisch zurückgesetzt wird? `
Es ist jetzt schon so.Ist das also ein bekannter "Bug"?
Wird das gefixt? `
Heute Abend oder Morgen wird gefixt. -
Wird heute Abend oder morgen schon gemacht. Wenn ich wieder fitter bin. `
oh, unfit hört sich nicht gut an, falls du krank bist wünsche ich erstmal GUTE BESSERUNG!!!Aber schön zu hören das es gefixt wird, das hält mich aktuell vom weiteren Testen ab
da ich nicht beurteilen kann, wo Fehlverhalten evtl herkommen.
Es ist jetzt schon so. `
Eigenartig, bei mir wird der Haken NICHT zurückgesetzt, es wird aber aktuell auch nichtsimportiert, vermutlich liegt das an dem oben genannten Problem,
werde also erstmal den Fix abwarten
Heute Abend oder Morgen wird gefixt. `
SUPER
996_2016-12-31_09h58_04.png -
noch eine Anmerkung zu der Bezeichnung "Init"
Wäre es nicht sinnvoller, dies in "Events" / "Ereignisse" umzubenennen
etwa so:
filename="Admin.PNG" index="0">~~ `
Es gibt neue Version mit "check init" Möglichkeit.Die Beschriftung muss irgendwie so sein:
Ereignisse empfangen: Ereignissschnittstelle beobachten: Intervall für Beobachtung (Sek): Für Beobachtung das Objekt verwenden: -
Danke, werde ich vermutlich erst übermorgen testen können,
musste beruflich weg und hock jetzt im Hotel…
Zur Beschriftung: ja so fände ich es auch wesentlich verständlicher.
-
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…
