Homematic und Homematic IP am Raspberry

Begonnen von uwek, 23 September 2017, 17:40:48

Vorheriges Thema - Nächstes Thema

uwek

Guten Tag,

ich betreibe seit einigen Jahren FHEM auf einem Raspberry Pi3 mit verschiedenen Funksschnittstellen.

  • CUL für FHT und FS20
  • HUE Bridge für ZigBee
  • UZB-Stick für ZWAVE
Nun möchte ich gerne auch Homematic UND Homematic IP nutzen.

Ich habe hier im Forum ein ganze Weile gelesen, bin aber nicht ganz sicher ob ich alles richtig verstehe:
Welches Gerät brauche ich, um am rpi nun beide Homematic-Varianten parallel nutzen zu können?
Ich denke ich brauche eine CCU2, bin aber nicht sicher. Oder gibt es noch andere Möglichkeiten, z.B. RaspberryMatic?
Sind alle Homematic und Homematic IP Gräte uneingeschränkt nutzbar?

Vielen Dank und Gruß,
Uwe

Chris8888

Hallo Uwe,

die CCU2 mit HMCCU funktioniert tadellos.
Darüber kannst du dann HM und HmIP ansteuern...

Ich persönlich bevorzuge aber HM direkt in FHEM anzubinden, zB über einen CUL, einen HMUART oder HM-CFG-LAN.

VG
Christian
FHEM 6.0 auf einem PI4 mit div. Homematic-Komponenten, Alexa, Tablet-UI und Homebridge...und läuft einfach. Erweitert mit CCU3 und Homematic-IP...und läuft immer noch.

chris1284

#2
schau dir hier im homematic forumsteil die letzten themen an. da wurde deine frage zum einen mehrfach gestellt und bereist beantowrtet

https://forum.fhem.de/index.php/topic,68796.0.html
https://forum.fhem.de/index.php/topic,76951.0.html

ZitatWelches Gerät brauche ich, um am rpi nun beide Homematic-Varianten parallel nutzen zu können?
Ich denke ich brauche eine CCU2

du brauchst eine ccu2. diese gibt es viruell (YAHM, Raspberrymatic -> kostet dich einen pi falls nicht schon vorhanden und ein hm-mod-rpi-pcb ~20€) oder als zusätzliches gerät (ccu2 bausatz 80€ ist die günstigste variante)

ZitatIch persönlich bevorzuge aber HM direkt in FHEM anzubinden, zB über einen CUL, einen HMUART oder HM-CFG-LAN.

heute würde aber niemand mehr den cul nehmen (auch mit der angepassten culf machts wenig sinn), da zu viel hickhack mit einigen geräten.
HMUART mit  hm-mod-rpi-pcb  ist toll aber über fhem hat man halt kein hmip was wie ich finde eine künstliche beschneidung ist und kaum vorteile bringt (zb vccu, templates,hminfo).
HMUART mit HM-LGW-O-TW-W-EU ist wie ich finde das sinnloseste da das teil so viel wie eine ccu2 kostet aber weniger kann, zu dem ist es teuere als die überteuerten hm-cfg-lan.
HM-CFG-LAN ist veraltet und nur noch überteuert gebraucht zu haben, also auch keine wirkliche alternative.
wer ein langateway für hm braucht das direkt in fhem anzusprechen ist sollte den hm-mod-rpi-pcb mit einem lanport oder wifi betreiben. das ist günstig und eine zuverlässigere version des cun

uwek

Hallo,

vielen Dank für die Antworten. Ich habe es jetzt so verstanden:
Mit der ccu2 (HM-Cen-O-TW-x-x-2) sollten HM UND HMIP auf mit FHEM aif dem Pi jeden Fall funktionieren (?)
Eine Alternative wäre bspw. YAHM mit hm-mod-rpi-pcb auf einem Pi, was quasi eine nachgebildete ccu2 auf einem Pi wäre.

Nicht ganz klar ist mir:
Kann YAHM mit hm-mod-rpi-pcb auf demselben Pi laufen wie FHEM?
Offenbar stellt YAHM auch eine autark laufende ccu2-Umgebung dar, die auch ohne FHEM einsetzbar ist.
Ich will weiterhin alle Steuerungen, Abläufe usw. in FHEM realisieren und keine Parallel-Automatisierung via Homematic haben. Ich will einfach nur HM und HMIP-Komponenten zusammen mit meinen FS20, FHT, ZWAVE und ZigBee Geräten nutzen.

Ist in diesem Fall die oft bemängelte Leistungsfähigkeit der Original-CCU2 (HM-Cen-O-TW-x-x-2) oder die Einschränkungen des HM-LAN-Gateways (HM-LGW-O-TW-W-EU) für mich relevant? Die Geräte würden ja "nur" als Funkschnittstelle genutzt.

Ich entschuldige mich schon mal für meine vielleicht nervigen Rückfragen. Das Thema erscheint mir aufgrund der verschiedenen Lösungsansätze mit ihren jeweiligen Vor- und Nachteilen nicht ganz einfach zu sein. Also schon mal herzlichen Dank für Eure Hilfe.

Viele Grüße,
Uwe





Beta-User

Zitat von: uwek am 24 September 2017, 13:29:33
Kann YAHM mit hm-mod-rpi-pcb auf demselben Pi laufen wie FHEM?
Ja, steht aber bereits in aller Deutlichkeit spätestens in den von chris1284 verlinkten Beiträgen rund um den hier.
Du solltest damit alle HM-Geräte (auch IP) mit dem Modul HMCCU in FHEM einbinden können und keine weiteren Logiken  auf der (virtuellen O-) CCU(2) benötigen.

@chris1284: Für ein "bashing" auf CUL+Derivate besteht aber auch kein Anlaß... Die haben andere Vorteile. Und wenn man nur "wenige Standardgeräte innerhalb einer überschaubaren Reichweite" hat, aber grad zufällig keine keine GPIOs greifbar, stellt sich eben die Frage, ob man lieber einen CUL haben will, oder das wenig beschriebene Vorgehen über USB->HM-MOD-RPI-PCB wählt und ein klein wenig lötet ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

chris1284

#5
In Bezug auf cul und hm macht das ,, bashing" (ehr konstr. Kritik ) schon Sinn da es bessere alternativen gibt. Verwechsele auch nicht cul (das iodev) und cul_hm.....

Mittlerweile würde dir kaum ein erfahrener User mehr zum cul als iodev raten und man braucht keine gpio für das hm-mod-dpi-Modul

Beta-User

Zur Klarstellung:
Es ist zutreffend, dass es bessere Optionen für einen HM-Betrieb (mit CUL_HM) gibt als den CUL, ich selbst betreibe das HM-MOD-RPI-PCB auch nicht über GPIO, sondern an einem USB-Seriell-Wandler.

Bei der Frage, was man einem Einsteiger raten sollte, wird es aber schnell spannend, vor allem, wenn derjenige sich scheut, einen Lötkolben in die Hand zu nehmen. Dann ist nämlich - bei allen Einschränkungen, die ich hier nicht nochmal aufzählen will, ich kenne die Themen jedenfalls in der Theorie hinreichend - ein CUL&Co auch eine gangbare Variante, ohne sich die auch nur mit Einschränkungen genießbaren HW-Alternativen aus dem Hause e3-Q antun zu müssen. In jedem Fall sind diese schlicht überteuert (das mag man zwar auch von den 20 Euro für das PCB-Modul sagen, aber da geht es noch halbwegs).

Wer also erst mal ausprobieren will und (noch nicht) zum Lötkolben greifen, (erst mal) wenige Geräte innerhalb eines kleineren Umkreises hat und evtl. auch noch meint, 433MHz-Kram einsetzen zu wollen, kann ja erst mal 20 Euro ausgeben für einen Selbstbau-CUL eines erfahreren Users hier. Er sollte halt wissen, dass er beim Verlassen dieser Einschränkungen schnell Gefahr läuft, auf Fehlersuche zu gehen. Aber bitte: Ich hatte über 2 Jahre nur einen CUL im Einsatz, einiges an HM-Material (>50 Devices) und nie ernsthafte Probleme (aber auch von Anfang an darauf geachtet, den Funkverkehr zu den Devices eher sparsam zu halten).

MapleCUN will ich gar nicht nennen, das ist zwar die ultimative Allzweckwaffe, aber für einen Einsteiger dann das guten erst mal zu viel. Wobei auch hier gilt: nach Wiki einrichten geht schon...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Terabyte



Zitat von: Beta-User am 24 September 2017, 15:31:07
Zur Klarstellung:
Es ist zutreffend, dass es bessere Optionen für einen HM-Betrieb (mit CUL_HM) gibt als den CUL, ich selbst betreibe das HM-MOD-RPI-PCB auch nicht über GPIO, sondern an einem USB-Seriell-Wandler.

Hallo

Wie hast du das mit dem HM-MOD-RPI-PCB und dem USB-Seriell Adapter gemacht?

Gesendet von meinem XT1635-02 mit Tapatalk


Beta-User

Zitat von: Terabyte am 24 September 2017, 16:20:47
Wie hast du das mit dem HM-MOD-RPI-PCB und dem USB-Seriell Adapter gemacht?
Das PCB nutzt auch über GPIO nur 4 Verbindungen: 3.3V, GND, RX und TX.
Die habe ich einfach an einen China-USB-Wandler geklemmt, der RX und TX auf 3.3V betreiben sollte (?). Da der eine USB-Buchse hatte, habe ich einen CP2102-basierten genommen, die Stecker weitestgehend ausgelötet und dann nur RX->8 und TX->9 mit den Steckleisten verlötet, 1 (=3.3V) und 5 (=GND) dann per Kabelchen. Dabei habe ich auch die mit dem PCB kommende Platine verlötet (das Modul war vorher im PI, da brauchte ich das), die Zählweise ist im Uhrzeigersinn beginnend bei dem PIN, der auf der Unterseite der Platine mit 1 bezeichnet ist (eckiger Lötpunkt).

Es gibt dazu auch ein sehr gutes PDF, das aber leider so tief hier im Forum vergraben ist, dass ich es grade auch nicht finde... Allerdings einen Beitrag von betateilchen mit Fotos, wie er das gemacht hat (Sicherheitsvariante mit Widerständen, ich habe das direkt verlötet, seit ca. 2 Monaten ohne erkennbare Probleme).

RAW-Definition:
defmod myHmUART HMUARTLGW /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
attr myHmUART group Interfaces
attr myHmUART hmId ABCDEF
attr myHmUART icon scc_868
attr myHmUART room Buero
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwek

Hallo,

vielen Dank für die hilfreichen Antworten und die angeregten Diskussionen. Ich werde mir nun einen HM-MOD-RPI-PCB zulegen - die Investition ist ja überschaubar;-)

Viele Grüße,
Uwe

Speedy68

Hallo zusammen,

ich wollte genau das gleiche erreichen: meine Homematic Komponenten um Homematic IP erweitern. Habe soviel gelesen und doch vermutlich was falsch verstanden.
Ausgangszustand war ein alter HMLAN Adapter.
Habe mir dann den HM-MOD-RPI-PCB zugelegt, auf dem PI installiert, "define myHmUART HMUARTLGW /dev/ttyAMA0" etc. definiert, VCCU eingerichtet etc.
Homematic läuft weiterhin super. HmIP nicht.
OK Ursache habe ich gefunden. Geht wohl nur z. B. über YAHM.
Bevor ich jetzt wieder blöde 'rumdoktere': Muss ich die ganzen Einstellungen hinsichtlich UART wieder zurücknehmen - oder kann das Funkmodul gleichzeitig in YAHM arbeiten und als Bestandteil der VCCU? Es waren auf dem PI ja auch verschiedene Dateien anzupassen (config.txt, cmdline.txt ...) müsste das auch rückgängig gemacht werden?

Danke für Eure Antworten!

sat666

Hallo zusammen,

kleiner Leidensbericht zum Thema: ich habe in den letzten Wochen versucht, Homematic IP auf einem raspberry zum Laufen zu bringen. Habe extra einen neuen raspberry pi 3 erworben, da mein 1er wohl zu alt ist. Da auf dem Pi auch noch andere Software laufen soll, habe ich mich auf YAHM konzentriert. RaspberryMatic ist ja anscheinend eine StandAlone-Lösung analog der CCU2.
Als Grundlage habe ich Raspbian Stretch Lite verwendet. Die erste Hürde war hier die Netzwerkkonfiguration, da es zukünftig wohl keine "eth0"-Schnittstelle mehr gibt, sondern "e"+MAC-Adresse. Nachdem das lief, habe ich FHEM und YAHM installiert, was beides soweit geklappt hat. Musste dann feststellen, dass mein CUL-Stick wohl nicht mit YAHM zusammenarbeitet. Ich habe dann in einen HM-MOD-RPI-PCB investiert. Der CUL läuft nun erstmal mit dem EnoceanPI auf meinem alten raspberry mit FHEM weiter.
Habe nun gedacht, nur noch das YAHM-Modul "Homematic IP" aktivieren und gut ist. Auf der Oberfläche der CCU2(YAHM) kamen jedoch PopUps, dass HMip-RF, BidCOS-RF, Virtuals Devices, etc. nicht läuft. Habe alles nochmal neu installiert und ewig rumprobiert. Mittlerweile steht bei der Anzeige der verfügbaren Module über "yahm-module available" bei "Homematic IP" nun "deprecated" (develop-branch). Habe dann mit YAHM aufgegeben....konnte Homematic IP dort nicht zum Laufen bringen.

Habe dann zufällig von dem piVCCU-Projekt gelesen. Hab kurzerhand die SD-Karte mit Raspbian neu geflasht und piVCCU installiert. Dann gleich versucht, einen IP-Wandthermostat daran anzulernen und es hat sofort funktioniert, ohne große Anpassungen am Netzwerk, aktivieren von Modulen, etc. Klappte sofort out-of-the-box. Ich kann also piVCCU klar empfehlen.

Gruß

chris1284

#12
Naja, du hast offensichtlich das Modul beimversuch mit Yahoo vorher nicht im rasbian sauber aktiviert.
Der cul läuft an Der Yahm ccu mit cuxd. Auf den ersten Blick ist pivccu ein yahm als apt-Paket aber mit  weniger Hardwaresupport. Ich werde es mal probieren.

sat666

ok, das mit dem CUL muss ich wohl relativieren: "Mein CUL-Stick" arbeitet nicht mit YAHM zusammen, weil der Anwender zu dumm ist, diesen zu aktivieren  ;) . Da ich kein Linux-Experte oder Programmierer bin, verstehe ich leider nicht, was bei den einzelnen Vorgängen so im Hintergrund passiert und kann daher auch nicht immer daraus ableiten, was zu tun ist, um Dinge zum Laufen zu bringen. Ich denke, da bin ich nicht der einzige hier. Ich bin vielmehr darauf angewiesen, mich an die jeweiligen Dokumentationen, Foren-Beiträge und Wiki-Einträge zu orientieren.

Die klare Aussage "Der CUL läuft an der Yahm ccu mit cuxd." find ich gut. Auf der YAHM-Wiki-Seite steht zum CUL aber gar nichts. Es gibt bei YAHM auch kein Modul, was man aktivieren könnte. Läuft über den CUL denn auch Homematic IP? Das habe nirgendwo nachlesen können. Mein Ziel ist ja, meine neuen IP-Geräte in FHEM einzubinden. Meine bisherigen Homematic-Geräte habe ich direkt in fhem eingebunden (ohne YAHM o.ä.).

Das piVCCU ein alt-Paket von YAHM ist, kann ich schlecht sagen. Da es mittlerweile auch in YAHM als Modul verfügbar ist, dachte ich, dass es etwas eigenständiges ist.

Vom CUxD habe ich auch schon gelesen, kann damit aber nichts anfangen. Weder bei FHEM gibt es dazu einen Wiki-Eintrag, noch in der Commandref gibt einen eigenen Eintrag dazu. Habe nur gelesen, dass man damit FS20 und Enocean steuern kann. Ich habe keine FS20-Geräte und die Enocean-Geräte laufen über einen EnoceanPI. Somit habe ich das nicht näher angeschaut. Läuft darüber auch Homematic IP?

chris1284

was ein Autokorrektur Fehler so ausmacht. Es sollte APT-Paket und nicht alt-Paket heißen.

Nein der CUL und andere Derivate können kein HMIP das geht nur mit HM-Produkten (CCU2, OCCU, Funkmodul, Accesspoint).
Deine Problemlösung kann also nur sein: echte CCU2 kaufen oder das HM-MOD-RPI-PCB kaufen und YAHm/piVCCU/raspberrymatic nutzen.
Evtl. läuft ja auch das HM-MOD-RPI-PCB auf dem enoceanPI auch noch und du müsstet dort nur noch Yahm oder piVCCU installieren.

zum CUL und YAHM:
Das Einbinden des CUL in YAHM kann man auch im Homematic-Forum gut nachlesen: pi installieren, YAHM installieren, CUxD installieren (über die CCU GUI), CUL einstecken -> wird in YAHM-CCU erkannt.
Der CUxD hat erstmal nichts mit FHEM zu tun sondern mit der CCU (daher auch im wiki für YAHM und FHEM nichts darüber ).