HMCCU mit FHEM nutzen oder HMLAN direkt

[no_Legend]

mist. 

du hast also zum funken nur eine ccu?
also kein hmlan, kein hmusb und kein cul-irgendwas. so wüsste ich nicht wie. schade.

Hi Frank,

ich hab zwei HMLan und heute auch einen CUL eingerichtet, den hatte ich schon bestimmt 1 Jahr rumliegen. Schande

Welches HM Device hat inhibit und muss man den haben zum sniffen?
Aber am wichtigsten wie sniffe ich?

Schick mir doch mal ne PN.


Zurück zum Thema.
Ich habe das AES an und keine Probleme bisher.
Am Anfang musste man halt den Schlüssel per Windows Software ändern müssen.
Ging aber alles.

Gruß Robert

[Stril]

Hallo!

Warum musstest Du den Key per Windows-Software ändern und wo?
Ich dachte nach der Anleitung, dass das komplett aus FHEM erfolgt.

Hast Du dann am HMLAN über das Windows-Tool die Verschlüsselung auch angeschaltet?

Danke für Deine Hilfe!

[Otto123]

Nochmal mein Link zum Lesen http://www.fhemwiki.de/wiki/AES_Encryption#Aktivieren.2C_Einrichten.2C_Umgang_in_FHEM

Der Key muss entweder der VCCU (CUL/HMLAN/HMUSB) oder den IO Geräten (nur HMLAN/HMUSB) bekannt gemacht werden. Er wird als Attribut gesetzt, wobei 3 Schlüssel eingetragen werden können (hmKey hmKey2 hmKey3). Der Key wird MD5 kodiert - man kann ihn im Klartext oder bereits kodiert eingeben. FHEM kodiert ihn, wenn er im Klartext eingegeben werden sollte. FHEM speichert das Attribut ausschließlich kodiert.
attr VCCU hmKey geheimerSchluessel
Nun kann der Schlüssel auf die einzelnen Geräte übertragen werden. FHEM unterstützt mit dem Kommando assignHmKey das Verteilen des Schlüssels auf die HM Komponenten. Es ist aber auch möglich, diese Aktion mit der HM Konfigurationssoftware (HM-PC-Software) oder einer CCU durchzuführen.

Da hat sicher viel in den letzten Jahren geändert/entwickelt. Aktuell geht alles mit FHEM.

Gruß Otto

[no_Legend]

Hallo!

Warum musstest Du den Key per Windows-Software ändern und wo?
Ich dachte nach der Anleitung, dass das komplett aus FHEM erfolgt.

Hast Du dann am HMLAN über das Windows-Tool die Verschlüsselung auch angeschaltet?

Danke für Deine Hilfe!

Die Verschlüsselung des Netzwerktraffics mit dem HMLAN musste man deaktivieren.
Den standard schlüssel der im hmlan gespeichert ist habe ich damals auch per WIndows Software ändern müssen.
Dazu gibt es einen beitrag bei meintechblog.de

Wie der jetztige Stand ist kann ich nicht sagen, hab davon nichts mit bekommen.

Gruß Robert

[joshi04]

Ich habe mich mit der ursprünglichen Frage neulich auch auseinandergesetzt, wo die CCU2 gerade günstig als Bausatz erhältlich ist und mit dem HMCCU ein Modul in der Entwicklung ist, die CCU2 mit FHEM zu verbinden.

Bitte korrigiert mein Verständnis, falls unrichtig:
Wenn hier vom "standard schlüssel" der HMLan gesprochen wird, ist damit der in der "HomeMaric Konfigurator"-Software s.g. "Sicherheitsschlüssel" oder auch "System-Sicherheitsschlüssel" gemeint und bezieht sich auf die AES-Signierung zwischen IO <-> Gerät (->Wiki).

Der AES-Schlüssel, der hinten auf dem HMLan aufgedruckt ist, bezieht sich auf eine ggf. AES-verschlüsselte/signierte (?) Kommunikation zwischen Zentrale (FHEM oder CCU2) <-> IO-Device (HMLan). Da das derzeitige FHEM-Modul diese Art der Verschlüsselung nicht unterstützt, muss diese in der Windows Software "HomeMatic Lan-Interface Configurator" unter "change IP Setting" deaktiviert werden, wenn man FHEM als Zentrale einsetzen möchte.

Beide Konfigurationen könne mM nur über die entsprechende Win-Software konfiguriert werden.

Setzt man nun FHEM als Zentrale ein, muss der oben neu vergebene Sicherheitsschlüssel (im Auslieferungszustand hat der HMLan einen Standardschlüssel, der zwar nicht bekannt aber für alle Auslieferungsstände gleich ist) im HMLan als Attribut angegeben werden. Ich betreibe damit eine Winmatic, die nur AES-signierten Nachrichten akzeptiert und habe damit bislang noch keine Probleme gehabt.

Jetzt noch einmal kurz ursprünglichen Frage:
Mein derzeitiges Verständnis ist, dass

• Die CCU2 ist eine vollständige Zentrale mit Funkmodul und kann völlig unabhängig von FHEM über deren grafische Oberfläche konfiguriert werden. Größtenteils alle Funktionalitäten, die man für die Homeautomation braucht, samt Visualisierung können konfiguriert werden. Die CCU2 kann nur HM-Geräte integrieren. (Ich habe selbst keine.)
• Mit dem Modul HMCCU gibt es eine Möglichkeit, Informationen zwischen der CCU2 und FHEM auszutauschen. mM gibt es noch weitere Möglichkeiten, keine aber soweit ausentwickelt, wie derzeit bereits das HMCCU-Modul.
• Die Hauptproblematik der Kommunikation zwischen CCU2 und FHEM ist die Synchronisation zeitkritischer Zusammenhänge. D.h. niemand möchte einen HM-Bewegungsmelder, der erst nach 20 Sekunden den HUE-Streifen im Flur anmacht. Vielleicht bin ich hier aber auch schon wieder nicht mehr up-to-date.
• Wenn man also viele HM-Geräte hat, die hauptsächlich untereinander agieren und keine zeitkritischen HM<->FHEM Zusammenhänge, dann können die Vorteile der grafischen Oberfläche der CCU2 für die Einrichtung sicherlich von Vorteil sein.
  
• Auch jegliche Art von Mischformen sind sicherlich denkbar.
• Hat man hingegen wenige HM-Geräte, bzw. viele zeitkritische Zusammenhänge zwischen HM-Geräten und Geräte anderer Interfaces, dann ist die Anbindung der HM-Geräte über die CCU2-Anbindung über das HMCCU-Modul an FHEM (noch) nicht geeignet. Dann sollten die HM-Geräte besser über einen HMLan (+VCCU) mit FHEM als Zentrale betrieben werden.
• Die Funktionalitäten der CCU2 sind mit der Beschränkung auf HM-Geräte adäquat zu FHEM + HMLan/HMUSB/etc. + VCCU. Letzterem sind natürlich nur Grenzen durch die Phantasie des Admins gesetzt.

Könntet Ihr das bitte einmal Gegenlesen und mich ggf. korrigieren?

Ist HomematicIP nicht Cloud-basiserend? Oder kann man das Konfigurieren, dass die nicht nach Hause telefonieren? Nicht dass das so eine sch... Konzept ist, wie bei Netatmo!

[Stril]

Hallo!

Ich denke, HM-IP könnte wirklich das "große Argument" für den Zwischenweg über die Homematic Zentrale sein.

Zur Verschlüsselung habe ich jetzt aber doch noch eine Frage:
Muss dann jeder Sensor, der verschlüsselt arbeiten soll, auch über dien Windows-Software erst bearbeitet werden, oder muss man nur den HMLAN über die Windows-Software umstellen und dann in FHEM über assignHMKey den Key in den Sensor schreiben und damit den "alten Key" überschreiben?

Danke und Grüße
Phil

[zap]

Die CCU2 ist eine vollständige Zentrale mit Funkmodul und kann völlig unabhängig von FHEM über deren grafische Oberfläche konfiguriert werden. Größtenteils alle Funktionalitäten, die man für die Homeautomation braucht, samt Visualisierung können konfiguriert werden. Die CCU2 kann nur HM-Geräte integrieren. (Ich habe selbst keine.)

Stimmt soweit. Allerdings kann man mit Hilfe von CUxD (Zusatzmodul für die CCU, teilweise kostenpflichtig) auch EnOcean integrieren. Macht aber wenn man eh FHEM mit Funkstick hat keinen Sinn.

Mit dem Modul HMCCU gibt es eine Möglichkeit, Informationen zwischen der CCU2 und FHEM auszutauschen. mM gibt es noch weitere Möglichkeiten, keine aber soweit ausentwickelt, wie derzeit bereits das HMCCU-Modul.

Ja.

Die Hauptproblematik der Kommunikation zwischen CCU2 und FHEM ist die Synchronisation zeitkritischer Zusammenhänge. D.h. niemand möchte einen HM-Bewegungsmelder, der erst nach 20 Sekunden den HUE-Streifen im Flur anmacht. Vielleicht bin ich hier aber auch schon wieder nicht mehr up-to-date.

HMCCU ist hier darauf angewiesen, dass die CCU per Event Push zeitnah über Statusänderungen informiert. Das klappt nach meinen Erfahrungen gut. HMCCU liest dann in einem asynchronen Prozess alle x Sekunden diese Ereignisse aus einer Queue und verteilt sie an die entsprechenden FHEM Devices. X ist einstellbar, ich fahre derzeit mit 3 Sekunden.

Wenn man also viele HM-Geräte hat, die hauptsächlich untereinander agieren und keine zeitkritischen HM<->FHEM Zusammenhänge, dann können die Vorteile der grafischen Oberfläche der CCU2 für die Einrichtung sicherlich von Vorteil sein.

Versprich Dir nicht zuviel von der grafischen Oberfläche. Die Haptik ist ziemlich antiquiert, ähnlich FHEM in der Standardinstallation . Funktional ist sie aber top, d.h. anlernen von neue Devices, Verknüpfung von Devices oder erweiterte Steuerung per Script sind sehr einfach umzusetzen (ok, in das Scripting muss man sich etwas einarbeiten). Insbesondere das Anlernen ist deutlich einfacher als in FHEM und v.a. werden neue Komponenten auf dem Markt zeitnah unterstützt. Ich habe HMCCU u.a. entwickelt, weil ich die besseren grafischen Darstellungsmöglichkeiten in FHEM (Tablet UI regelt!) auch für Homematic nutzen möchte.

Hat man hingegen wenige HM-Geräte, bzw. viele zeitkritische Zusammenhänge zwischen HM-Geräten und Geräte anderer Interfaces, dann ist die Anbindung der HM-Geräte über die CCU2-Anbindung über das HMCCU-Modul an FHEM (noch) nicht geeignet. Dann sollten die HM-Geräte besser über einen HMLan (+VCCU) mit FHEM als Zentrale betrieben werden.

Bin ich anderer Meinung (best of both worlds). Alle meine Homematic Komponenten habe ich in der CCU2. Die exotischen Sachen (SONOS, AVR-Receiver, Wetterdaten usw) habe ich in FHEM. Und HMCCU verbindet beide Welten.

Die Funktionalitäten der CCU2 sind mit der Beschränkung auf HM-Geräte adäquat zu FHEM + HMLan/HMUSB/etc. + VCCU. Letzterem sind natürlich nur Grenzen durch die Phantasie des Admins gesetzt.

Die CCU hat zwar eine Scripting Schnittstelle, aber FHEM ist als offene Software deutlich flexibler. Wenn man aber nur Homematic Komponenten betrachtet, sehe ich hier den Vorteil bei der CCU.

Ist HomematicIP nicht Cloud-basiserend? Oder kann man das Konfigurieren, dass die nicht nach Hause telefonieren? Nicht dass das so eine sch... Konzept ist, wie bei Netatmo!

Ob man es so konfigurieren kann, dass es gar nicht nach Hause telefoniert, weiß ich nicht. Allerdings ist eine Steuerung nur über die CCU bei fehlender Internet Verbindung angeblich möglich.

Noch ein Hinweis: Das automatische Update per RPC Server in HMCCU funktioniert derzeit nur mit Homematic BidCos-RF und Wired Komponenten. HM-IP habe ich noch nicht getestet, hier warte ich noch auf die finale IP Firmware der CCU2 (vermutlich Februar). CUxD Geräte können nur per Polling abgefragt werden, da CUxD binary RPC benutzt, das HMCCU nicht unterstützt.

[joshi04]

Cool, vielen Dank.

best of both worlds

Sorry, ich habe mich vermutlich missverständlich ausgedrückt und eigentlich glaub ich, haben wir das gleiche Verständnis (best of both worlds).
Was ist meinte ist, wenn ein HM Gerät verbunden über die CCU2 ein Gerät verbunden über ein anderes FHEM Interface zeitkritisch steuern soll, oder andersherum (Beispiel HM-Bewegungsmelder, Z-Wave-LED-Strip (HUE)), muss man den Delay für die Synchronisation berücksichtigen.
Passt diese Aussage besser?

Obendrein, wenn es bei Dir schon mit nur 3 Sekunden läuft, wäre das vielleicht wirklich nur noch für genau solch ein Beispiel schwierig. (Vielleicht kaufe ich mir doch noch ne CCU2, zumindest erstmal zum "spielen".)

Zum Update fällt mir noch etwas anderes ein beim ursprünglichen Vergleich:
Für eventuelle Firmwareupdates von HM-Komponenten wird eine CCU2 benötigt. Bin mir aber nicht sicher, wie schwerwiegend dieses Feature ist, sollte es einem fehlen. Wie häufig gibt es tatsächlich Updates einer Firmware, deren neue Features einem tatsächlich fehlen würden?

Hast Du etwas dagegen, wenn ich die Erkenntnisse bei Zeiten ins Wiki rüber kopiere?

Edith: Und noch etwas zum Vergleich,
Bei der Verwendung der CCU2 ist die Kommunikation zwischen IO (CCU2) und Device (z.B. Winmatic) eine herstellerinterne Geschichte, d.h. das stellt eQ3 zur Verfügung. Treten hierbei Probleme auf, können Fehler bedingt durch FHEM ausgeschlossen werden.
Hintergrund dieser Aussage: Hatte vor einiger Zeit Problemchen mit einer Winmatic und war drauf und dran die über eine CCU2 anzubinden, um andere Fehlerursachen, schlicht und einfach auszuschließen.
Letztendlich war es vermutlich ein mechanischer Fehler (Fenster zu schwergängig, Winmatic hat sich unerwartet Verhalten mit unregelmäßigen erst NACK und dann Motortilt), zumindest rennt sie jetzt wieder.
Hätte ich eine CCU2 gehabt, wäre ich vielleicht schneller drauf gekommen, weil ich alles andere einfach nicht in hinterfragt hätte. Letztendlich lief der FHEM-Anteil fehlerfrei und hatte ich vollkommen grundlos unter Verdacht.

[zap]

Was ist meinte ist, wenn ein HM Gerät verbunden über die CCU2 ein Gerät verbunden über ein anderes FHEM Interface zeitkritisch steuern soll, oder andersherum (Beispiel HM-Bewegungsmelder, Z-Wave-LED-Strip (HUE)), muss man den Delay für die Synchronisation berücksichtigen.

Stimmt genau. Du kannst davon ausgehen, dass die CCU den entsprechend Event quasi in Echtzeit an den RPC-Server von HMCCU schickt. Dann liegt es nur noch an dem einstellbaren Poil-Intervall, wie schnell FHEM darauf reagieren kann. Dieses Intervall ist bei mir momentan 3 Sekunden, weniger als 2 Sekunden würde ich hier allerdings nicht einstellen, um Performance Probleme in FHEM zu vermeiden. Dieser Wert ist die maximale Verzögerung! Beispiel (Poll-Intervall = 10 sec):

t1: Events werden gepollt
t1+5 sec: Neuer Event von der CCU
t1+10 sec: Events werden erneut gepollt.

=> Reaktionszeit von FHEM = 5 sec, d.h. deutlich unter dem Poll-Intervall.

Für eventuelle Firmwareupdates von HM-Komponenten wird eine CCU2 benötigt. Bin mir aber nicht sicher, wie schwerwiegend dieses Feature ist, sollte es einem fehlen. Wie häufig gibt es tatsächlich Updates einer Firmware, deren neue Features einem tatsächlich fehlen würden?

Habe zwar kein CUL, aber das ist m.W. falsch. Auch über FHEM mit CUL_HM können Firmware-Updates installiert werden. Ich hatte bisher einmal den Fall, dass ein Update unbedingt notwendig war, weil der Fehler die Nutzung der Komponente eingeschränkt hat (Wandthermostat).

Hast Du etwas dagegen, wenn ich die Erkenntnisse bei Zeiten ins Wiki rüber kopiere?

Nein, natürlich nicht. Feel free ...

[Stril]

Stimmt genau. Du kannst davon ausgehen, dass die CCU den entsprechend Event quasi in Echtzeit an den RPC-Server von HMCCU schickt. Dann liegt es nur noch an dem einstellbaren Poil-Intervall, wie schnell FHEM darauf reagieren kann. Dieses Intervall ist bei mir momentan 3 Sekunden, weniger als 2 Sekunden würde ich hier allerdings nicht einstellen, um Performance Probleme in FHEM zu vermeiden. Dieser Wert ist die maximale Verzögerung! Beispiel (Poll-Intervall = 10 sec):

Hallo!

Wo entstehen denn hier die Performanceprobleme? Denkst Du, auf "potenter" Hardware könnte auch ein "kurzes" Pollintervall von z.B. 1s funktionieren?

Grüße
Phil

[zap]

Musst Du ausprobieren. Wenn Du viele HomeMatic Geräte hast, gibt es auch viele Events, die dann z.B. jede Sekunde abgearbeitet werden müssen. Während dieser Zeit ist FHEM blockiert.

[tndx]

Hallo Otto,

Nochmal mein Link zum Lesen http://www.fhemwiki.de/wiki/AES_Encryption#Aktivieren.2C_Einrichten.2C_Umgang_in_FHEM
Da hat sicher viel in den letzten Jahren geändert/entwickelt. Aktuell geht alles mit FHEM.

das steht zwar so in der Wiki, aber der Teufel liegt im Detail! Ich versuche nun schon seit Wochen (gut, habe auch max 1 Std. am Tag dafür) meine Keymatic und die Remotes AES-signiert ans Laufen zu kriegen, doch bis jetzt geht nur die Keymatic selbst. Aus dem Grund habe ich auch schon mit einer CCU geliebäugelt...

[Stril]

Hallo!

Ich habe inzwischen beide Varianten am Laufen: HMLAN und HMCCU.
Mein "Zwischenfazit":

Alles ist besser über HMCCU mit Ausnahme von timingkritischen Dingen (Bewegungsmelder ohne Direktverknüpfung).
HMCCU fügt einfach eine "Schrecksekunde" dazu.

Sonst mag ich die HMCCU-Lösung mehr:
- Firmwareupdates sind unproblematisch
- Verschlüsselung ist problemlos
- FHEM wird nicht durch eine hohe Anzahl von "Sub-Devices" gefüllt (bei einem Aktor mit Leistungsmessung 7 Devices)
- HmIP wird unterstützt

Vielleicht sehe ich manche Punkte nicht, aber HMCCU ist schon eine echte Erleichterung.

Grüße
Phil