HmIP und FHEM für Dummies (mit piVCCU/Raspi)

[Mort]

Für alle die hier drüber stolpern: Das war ein Versuch, einen einfachen Einstieg zu schaffen. Da ich selbst aber auch nicht allzu tief im Thema bin, stimmt aber auch nach einer kleinen Überarbeitung sicher nicht alles. Vielleicht hat ja jemand anderes mehr Erfolg. Sorry.


Hardware-Voraussetzungen
Gleich vorweg: Die billigen Zentralen (HmIP-HAP, HmIP-WLAN-HAP) mit Smartphone-App funktionieren derzeit leider nicht so richtig gut, wobei da wohl gerade fleißig entwickelt und experimentiert wird.
Man stößt hier im Forum auch oft auf den "CUL", dieser ist für HmIP aber leider nicht geeignet.
Bleibt also eine "CCU". Von Homematic gibt es diese komplett als CCU3 oder die etwas ältere HM-LGW-O-TW-W-EU (angeblich nur für Homematic ohne "IP"), gebraucht lässt sich auch die CCU2 noch finden.

Selbstbau-CCU
Man kann sich die CCU aber auch selbst basteln - üblicherweise mit einem Raspberry Pi (es sind aber auch andere Plattformen möglich) und einer dieser Komponenten:
- HmIP-RFUSB - USB-Stick, offiziell von HM, aber eher mäßige Funkleistung und stiefmütterliche Pflege und (angeblich?) nicht HM (ohne "IP")-kompatibel
- HM-MOD-RPI-PCB - einfaches Funkmodul mit GPIO-Adapter
- RPI-RF-MOD - GPIO-Platine mit (angeblich) besserer Funkleistung, Wired-Support und weiteren kleinen Verbesserungen
Die offizielle CCU3 ist letztlich ein Raspberry Pi 3 mit RPI-RF-MOD und der offiziellen Open Source-Software HM-OCCU-SDK mit ein paar nicht offenen Erweiterungen.

Die beiden GPIO-Aufsätze können mit HB-RF-USB(-2) zu USB-Sticks und mit HB-RF-ETH zu eigenständigen Netzwerk-Geräten erweitert werden. Letzteres ist quasi eine günstige Alternative zu einem Extra-Raspi mit Ethernet-Anschluss, wobei aber die CCU-Software noch irgendwo anders laufen muss. Es ermöglicht also vor allem die freie Platzierung mit einem kleinen Formfaktor.
Die derzeitigen GPIO-Boards passen nicht auf den Raspberry Pi 4, hier muss also entweder ein alter Pi ran, Zwischensockel verwendet werden oder eine der Erweiterungen verwendet werden.

Alle Varianten für eine Selbstbau-CCU gibt es nur als Bausätze. Allerdings findet man bei eBay (v.a. Kleinanzeigen) oft fertige Geräte, und allzu schwer soll das Löten auch nicht sein (z.T. nur ein Kondensator). Der Bausatz HM-MOD-RPI-PCB wurde von ELV lange als "Funkmodul für HM-OCCU-SDK" vertrieben, mit einem Verpackungsdesign, das aussieht als hieße das Modul so.

Zu empfehlen ist also HM-MOD-RPI-PCB oder RPI-RF-MOD, je nach Begebenheiten (GPIO schon belegt? Lieber extern als eigenes Gerät?) und ggf. Verfügbarkeit mit "Erweiterung". Im Zweifelsfall lieber RPI-RF-MOD, da leistungsfähiger und normalerweise nur unwesentlich teurer, für viele Einsatzzwecke ist HM-MOD-RPI-PCB aber auch ausreichend.

Software für die Selbstbau-CCU
Derzeit stehen zur Auswahl:
- piVCCU - läuft wie ein eigenes virtuelles Gerät
- debmatic - "klassisches" Programm, daher auch leichter portierbar (x86), aber ggf. schwieriger einzurichten
- RasperryMatic - Komplettes System, wenn man die CCU auf 'nem eigenen Raspi laufen lassen will. Oder zumindest so gedacht.

Es handelt sich hier um verschiedene Adaptionen der Original-Software, die Oberfläche unterscheidet sich daher nur minimal. piVCCU und debmatic sind vom selben Entwickler.

Ich habe mich für piVCCU auf einem Raspberry Pi entschieden. Wer einen Raspi, ähnlich wie bei RaspberryMatic, komplett als HmIP-Zentrale nutzen will, bekommt hier vollständige System-Images. Ansonsten ist die Einrichtung hier ausführlich beschrieben.
Bei der Installation der eigentlichen Software ("sudo apt install pivccu(3)") wird nachgefragt, welche Hardware man hat. Für Platinen mit HB-RF-USB(-2) kann hier die GPIO-Variante gewählt werden. Man bekommt dann zwar einen Hinweis, dass kein GPIO-Aufsatz gefunden wurde, der Stick funktioniert aber normalerweise trotzdem. Mit sudo pivccu-info lässt sich das überprüfen.
Die piVCCU-VM bekommt auch eine eigene IP und Gerätenamen im Netz. piVCCU3 ist z.B. mit http://ccu3-webui erreichbar. (Lässt sich unter Einstellungen - Systemsteuerung - Netzwerkeinstellungen ändern.)

Für den Einsatz von FHEM muss alle Sicherheit ignoriert werden. Normalerweise ist das aber auch kein großes Problem, man hat ja noch den Router als Firewall. Wer 'ne FritzBox oder Router mit ähnlichen Funktionen hat, möchte aber vielleicht seinen Gästen lieber nur einen Gastzugang anbieten... 
Beim ersten Anmelden bietet die CCU-Weboberfläche auch gleich entsprechende Optionen an, ich hatte mich allerdings leider für die falsche (mittlere) Lösung entschieden. Es schadet aber ohnehin nicht, die Einstellungen wie hier beschrieben zu überprüfen.

Geräte anlernen und einrichten
Die CCU-Weboberfläche ist leider so ziemlich das benutzerunfreundlichste Stück Software, das ich bisher gesehen habe - und FHEM ist ja schon nicht gerade "easy to use"... 
Ich habe mich für CCU3 entschieden, CCU2 ist zum Teil minimal anders zu bedienen. Allzu große Unterschiede scheint es aber nicht zu geben.
Zum Anlernen gibt es rechts oben einen eigenen Button. Für die allermeisten HmIP-Geräte ist der "HmIP-Gerät anlernen"-Button links unten interessant. Danach können eine Minute lang die Geräte angelernt werden - je nach Gerät mit kurzem oder langem (4s) Druck auf die Home(matic)-Taste der Geräte. Auf der Oberfläche scheint zunächst nichts zu passieren. Bei genauem Hinschauen findet man aber, dass beim "Posteingang"-Button unten die Zahl plötzlich nicht mehr "(0)" ist. Nach dem Anlernen des/der Geräte (ich empfehle, das in möglichst kleinen Gruppen zu machen, sonst weiß man nicht mehr, welches Gerät welches ist), wechseln wir also mit einem Klick darauf in diesen "Posteingang".
Dort kann man blöderweise aber so ziemlich gar nichts machen, außer die Geräte mit "Fertig" zu bestätigen, vor allem kann man sie hier leider noch nicht umbenennen. (Außer ich habe etwas übersehen...)

Als nächstes geht es also in "Einstellungen" - "Geräte", wo man die Geräte durch Klick auf eine der Spalten ohne Checkboxen/Buttons umbenennen kann. Achtung, das FHEM-Modul mag keine Umlaute! Ich würde sicherheitshalber auch auf Leerzeichen verzichten, auf jeden Fall macht das auch das Autocreate (mehr dazu später) unproblematischer.
Mit dem "+" links werden die Kanäle geöffnet. Leider muss man sich in dieser Software tatsächlich zumindest so weit damit herumschlagen, dass man Raum und "Gewerk" (Funktionsgruppe, wie Heizung, Licht, ...) nur bei den Kanälen festlegen kann - wobei diese dann aber auch dem Gerät zugewiesen werden. Es empfiehlt sich, wenigstens den ersten Kanal, der für die Steuerung zuständig ist, umzubenennen (am besten wie das Gerät + ":1") und Raum und ggf. Gewerk zu wählen. Bei den anderen Kanälen ist das meist eher freiwillige Fleißarbeit.
Wer Geräte auf der Startseite will, muss übrigens in den Favoriten (ebenfalls unter Einstellungen) jeweils den ersten Kanal wählen, wenn man sinnvolle Informationen will, das Gerät taugt dazu meistens nicht.

Wer Wandthermostate und/oder Fenster-/Türschalter mit Heizungsthermostaten verbinden will, macht das am besten über Gruppen. Im Einstellungsmenü sind sie etwas versteckt unter den "Diagrammen".
Für HmIP-Anwender gibt's nach dem Klick auf "Neu" erst einmal eine fiese Stolperfalle: Es scheint keine Geräte zum Hinzufügen zu geben. Der Trick ist: HmIP-Geräte gehören nicht zur "Heizungssteuerung". Sondern zur "HmIP-Heizungssteuerung", die man erst als Gruppentyp wählen muss.
Nach dem Anlegen der Gruppe gibt es erst einmal ein paar Fehlermeldungen und "Servicemeldungen", weil der Funkverkehr zum Einrichten der Kopplungen nicht innerhalb einer Nanosekunde erledigt ist. Nach wenigen Sekunden sollte sich das aber erledigt haben.

FHEM
Das Einrichten von HMCCU ist hier recht gut beschrieben. Wer flexibel bleiben will, kann statt der IP auch den Namen (ccu3-webui o.ä.) angeben.
Wenn das Zuweisen von "rpcinterfaces" (auf HmIP-RF) Fehlermeldungen liefert, nochmal die Firewall-Einstellungen der CCU überprüfen, und ggf. die CCU (Einstellungen - Systemsteuerung - Systemwartung) und FHEM ("shutdown restart") neu starten. Das hat zumindest bei mir geholfen.

Für das Anlegen der Geräte empfehle ich die Autocreate-Funktion von HMCCU. Für alle, die mit Regular Expressions (für die Namen) überfordert sind, das Wichtigste:
.* = Beliebig viele (*) beliebige Zeichen (.), also quasi was "*" auf der Kommandozeile ist
^x = Beginnt mit "x"
x$ = Endet mit "x"
(ohne ^/$ wird der Ausdruck als "enthält irgendwo" interpretiert)
Man kann auch einfach den kompletten Namen angeben (auf Groß-/Kleinschreibung achten!), wenn man sich nicht mit Regular Expressions rumschlagen möchte.

Im Gegensatz zur CCU-Oberfläche kann man bei FHEM/HMCCU sehr gut einfach nur die Geräte verwenden ("t=dev"), es werden dann automatisch die Kanäle 0 und 1 für die wichtigsten Funktionen genutzt. Kanaldefinitionen sind also nur für besonders Neugierige (zusätzliche Daten) oder exotischere Anwendungsfälle nötig.

Setzt man bei Thermostaten die Temperatur, dauert es einen Moment, bis diese auch als Status vom Gerät ausgelesen wurde. Bei Gruppen dauert es noch ein wenig länger, bis auch die anderen Geräte den gleichen Wert haben.

Gruppen kann man zwar definieren (siehe hier), aber ich konnte mit denen nicht viel anstellen, nicht einmal die Temperatur setzen. Da die Synchronisation der Temperatur trotzdem funktioniert (wenn auch etwas langsam), habe ich mich damit nicht weiter beschäftigt.

[Beta-User]

@martinp876 oder einen anderen Moderator:
Könntest du der Bitte von Horti nachkommen und mal diesen Thread anpinnen: https://forum.fhem.de/index.php/topic,116424.msg1107127.html#msg1107127

@Mort: Ich verstehe ehrlich gesagt weder, warum man noch eine Zusammenfassung von deinem Thread hier braucht, und es sind hier auch so viele (teils durchaus verständliche) "Unsauberkeiten" und Missverständnisse drin, dass damit m.E. keinem "Dummie" wirklich geholfen ist.

Z.B. CUL geht (derzeit) DEFINITIV NICHT für HM-IP, und die "offizielle CCU3" ist afaik nichts anderes, als ein (3-er) Pi mit dem RPI-RF-MOD, das - entgegen der Werbung (typ. eQ-3...)  - zwar keine nennenswert bessere Funkleistung gg. dem "alten" HM-MOD-RPI-PCB hat, aber eben das universellere der beiden Module ist.

Kurz für Dummies: Wer eine virtualisierte CCU aufbauen will, sollte wohl das neue RPI-RF-MOD auf einen 4-er Pi stecken, insgesamt für ordentliche Kühlung sorgen, ein regelmäßige Backup einplanen und hoffen, dass eQ-3 die Komponenten qualitativ wieder besser auslegt sind als "eine Zeitlang" (habe vorhin zwei "C26" umgelötet und mir daher die Berechtigung erworben, über diese Firma etwas abzulästern).

[Horti]

Leider hat Martin bis jetzt nicht auf meine Bitte reagiert.

Die Anleitung ist ja nicht schlecht als Erfahrungsbericht, versucht aber zu viel abzudecken und damit doch an manchen Stellen zu oberflächlich. Aber ich fürchte, FHEM in Kombination mit HmIP schließt Dummies leider aus.

Ich könnte auch einiges erzählen über C26, ausgelaufene Batterien und nicht funktionierende Bausätze, aber das ist ja ein anderes Thema 

Und übrigens, "RPI-RF-MOD auf einen 4-er Pi stecken" geht gar nicht so einfach, dafür muss man entweder die GPIO-Leiste erhöhen/absetzen oder  zu einer Flex greifen.

[Beta-User]

Leider hat Martin bis jetzt nicht auf meine Bitte reagiert.

Mal schauen, das mit dem Anpinnen kann ja ggf. auch ein anderer Moderator übernehmen. Dass das Sinn machen würde, zeigt ja mal wieder die Existenz dieses Threads.

Aber ich fürchte, FHEM in Kombination mit HmIP schließt Dummies leider aus.

Na ja, der Weg zu HMCCU.* ist auch nicht wesentlich weiter als ConBee II + deconz (oder zigbee2mqtt, egal, mit welchem IO). Von daher ist könnte man das "in Kombination mit ..." auch ersatzlos streichen. FHEM ist nicht wirklich eine einfache Lösung für Hausautomatisierungs-Aufgaben, und ich habe arge Zweifel, ob es dafür überhaupt eine "für Dummies"-Lösung gibt.
Aber auch das ist ein anderes Thema .

Und übrigens, "RPI-RF-MOD auf einen 4-er Pi stecken" geht gar nicht so einfach, dafür muss man entweder die GPIO-Leiste erhöhen/absetzen oder  zu einer Flex greifen.

Ja supi... Danke für den Hinweis.

(Wäre ggf. noch einen kurzen Hinweis in dem anderen Thread wert, falls es da nicht schon steht).

[Mort]

@martinp876 oder einen anderen Moderator:
Könntest du der Bitte von Horti nachkommen und mal diesen Thread anpinnen: https://forum.fhem.de/index.php/topic,116424.msg1107127.html#msg1107127[/url]

Den habe ich leider übersehen. Tatsächlich schonmal ein guter Einstiegspunkt.

@Mort: Ich verstehe ehrlich gesagt weder, warum man noch eine Zusammenfassung von deinem Thread hier braucht, und es sind hier auch so viele (teils durchaus verständliche) "Unsauberkeiten" und Missverständnisse drin, dass damit m.E. keinem "Dummie" wirklich geholfen ist.

Es war der Versuch, anderen Leuten, die später über dieselben Probleme stolpern ein wenig zu helfen. Ist wohl offenbar misslungen...

Kurz für Dummies: Wer eine virtualisierte CCU aufbauen will, sollte wohl das neue RPI-RF-MOD auf einen 4-er Pi stecken

Abgesehen von der schon erwähnten Bauform-Problematik wär's schon cool, wenn das, und vielleicht noch Einrichten von HMCCU, schon reichen würde...

[Beta-User]

Leider hat Martin bis jetzt nicht auf meine Bitte reagiert.
[...]
Und übrigens, "RPI-RF-MOD auf einen 4-er Pi stecken" geht gar nicht so einfach, dafür muss man entweder die GPIO-Leiste erhöhen/absetzen oder  zu einer Flex greifen.

Hi Horti,

jetzt ist es gepinnt, sollte also ncht mehr ganz so einfach zu übersehen sein .

Magst du noch den Titel einkürzen und ggf. das mit der Steckerleiste irgendwie einarbeiten?