Umstieg von ccu.io und Einarbeitung - Erste Fragen

[tschombe]

Hi,

bin ja gerade am experimentieren mit ioBroker mit dem Ziel, von

ccu.io umzusteigen.

Ich setze eine CCU2 in Form von LXCCU ein, die ich zusammen mit einem alten Lan Gateway, einem neuen

Lan Gateway und einem Wired Gateway zur Ankopplung von Homematik Aktoren und Sensoren nutze.

(sowohl wired als auch funk)

Ich habe dort überhaupt keine Programme, keine Systemvariablen usw angelegt. Es ist quasi

tatsächlich ein "dummes" Gateway zu der Peripherie.

Alles (Programme, Variablen, Favoriten) läuft bisher auf ccu.io

Mein aktuelles Ziel wäre es, mit ioBroker die Kommunikation zur LXCCU aufzubauen und

die Scripte (heute nur Heizung und Jalousiensteuerung) umzuziehen.

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?

Frage 2:

soll ich als Kommunikation BIN-RPC oder XML-RPC fahren?

Frage 3:

was bedeten die Hacken beim hm-rpc adapter:

• Init?

• Check init

• Initiiere Geräte neu (einmalig)

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?

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.

Während ich mit ioBroker experimentiere läuft ccu.io auf einem Raspi parallel weiter, das sollte ja

aber kein Problem sein, oder?

Was sollte ich zu Diagnosezwecken beim nächsten mal (hab nur ein Live-System ) sichern?

ioBroker - log? ccu2 - log?

Ich hoffe ihr könnt mir ein paar dieser Fragen beantworten.

[bku]

Du hast aber schon das (noch unvollständige) Handbuch gelesen?

https://github.com/ioBroker/ioBroker/wi … r-handbuch

Gruß

Bernd

[tschombe]

ja, natürlich,

ich versuche sogar aktiv an einer Verbesserung der Doku mitzuarbeiten.

Allerdings kann ich aus der Doku leider meine offenen Fragen nicht 100%ig beantworten.

Ich kann gewisse dinge vermuten, aber ob das so ist weis ich leider nicht, daher frag ich hier nach:

Beispiel:

• konfiguration des hm-rpc adapters:

ich vermute mal ein Polling, da ich ein init-intervall eingeben kann,

vom namen her hätte ich vermutet das es was mit der adapter initialisierung zu tun hat,

ist aber vermutlich das polling intervall zur datenabfrage.

ok, wenn also polling, warum muss ich dann meine eigene Adapter-Adresse angeben???

das könnte ein Indiz für einen Rückkanal (events) sein???

[smiling_Jack]

Es werden nur System variablen gepoolt. Die andern kommen als Event

[tschombe]

dh. wenn ich keine systemvariablen habe läuft alles über events,

sprich ich könnte das polling intervall relativ hoch setzen.

ich dachte eh das die hm-rega für die systemvariablen zuständig ist,

oder macht das ein rm-rfd?

Gibts sowas wie eine Grafik ober Beschreibung welcher

Adapter auf welcher Ebene mit der CCU kommuniziert?

ich versteh das noch nicht so ganz

[Bluefox]

@tschombe:

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.

@tschombe:

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.

@tschombe:

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.

@tschombe:

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).

@tschombe:

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.

@tschombe:

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.

@tschombe:

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.

[tschombe]

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:

@Bluefox:

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 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?

@Bluefox:

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?

@Bluefox:

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

[tschombe]

noch eine Anmerkung zu der Bezeichnung "Init"

Wäre es nicht sinnvoller, dies in "Events" / "Ereignisse" umzubenennen

etwa so:

[Bluefox]

@tschombe:

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".

@tschombe:

wäre es dann evtl ein schönes Feature, wenn der Haken wieder automatisch zurückgesetzt wird? `
Es ist jetzt schon so.

@tschombe:

Ist das also ein bekannter "Bug"?

Wird das gefixt? `
Heute Abend oder Morgen wird gefixt.

[tschombe]

@Bluefox:

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.

@Bluefox:

Es ist jetzt schon so. `
Eigenartig, bei mir wird der Haken NICHT zurückgesetzt, es wird aber aktuell auch nichts

importiert, vermutlich liegt das an dem oben genannten Problem,

werde also erstmal den Fix abwarten

@Bluefox:

Heute Abend oder Morgen wird gefixt. `
SUPER
996_2016-12-31_09h58_04.png

[Bluefox]

@tschombe:

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:

[tschombe]

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.

[tschombe]

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

[tschombe]

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

[Bluefox]

@tschombe:

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.

[tschombe]

@Bluefox:

Ü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?

[Bluefox]

@tschombe:

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.

@tschombe:

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 2

@tschombe:

PS: 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.

[tschombe]

ok, danke für die Info,

dann lese ich jetzt erstmal die Spezifikation.

gibts übrigens in einer neueren Version:

http://www.eq-3.de/Downloads/Software/H … pc_API.pdf

[Homoran]

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

[Bluefox]

@Homoran:

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.