FHEM und Homematic (IP) - Wie habt ihr es gelöst?

[Torben80]

Hallo Freunde,
zuerst einmal einen schönen Sonntag.

Ich bin gerade dabei bei mir etwas Homematic einzurüsten. Nun habe ich ein paar Fragen diesbezüglich.

Vorab, ich habe einen sehr skeptischen WAF.

Frage 1: (ganz leicht)
Der Unterschied zwischen HM IP und dem 'alten' HM.
Sehe ich es richtig, dass ich mir HM IP sparen kann, wenn ich eh alles über FHEM mache, da ich da ja ein HM - Gateway nutze?

Frage 2: (Heizung)
Ich habe nun 4 HM - Thermostate in 3 Räumen verteilt und einen Außensensor.
Den Außensensor lassen wir mal außer acht. Dann habe ich also 3 Thermostate (2 von den alten --> die mit dem Drehrad an der Seite) und einen vom neuen Modell (mit dem Einfach-Rahmen). Ich spare mir mal die genaue Typenbezeichnung (ihr wisst ja welche ich meine).

Nun zur Frage, wie bekomme ich eine "schöne Heizungssteuerung" hin OHNE an jedem Fenster noch einen "Öffnungssensor" / "Drehgriffsensor" anzubringen, da das mein Budget sprengt, und in meinem alten Haus nichts mit Heizkostenamortisierung zu tun haben soll, sondern viel eher mit "ähhhh Spielerei / Vereinfachung".
Natürlich kommen an die Heizungen die HM-Stellantriebe ran.

Ich habe schon eine schönes FTUI gebastelt, wo ich eigentlich alle im Überblick habe.
Meine Idee wäre, dass man morgens zum Lüften einen "Klick" macht z.B. auf den Schalter "Lüften" und alle Heizungen gehen aus, und nach dem Lüften den Schalter wieder deaktiviert und alle Heizungen gehen für 10 Minuten auf BOOST und dann auf Raumtemperatur.

Was meint Ihr?

P.S. Frage 3: Was sind das für ganz alte Stellantriebe, wo nur ein ganz kleines LCD drauf ist? die sind nicht sehr WAF-Konform, oder?

Vielen Dank fürs Lesen und ich hoffe, dass ich nicht "auseinander genommen" werde für diese Fragen.

Gruß Torben

[Chris8888]

Hallo Torben,

zu 1:
Das kann man nicht wirklich kurz beantworten und dazu gibt es bereits mehr als ausreichend Infomaterial. Einfach mal einarbeiten.
Grundsätzlich wenn du ausschließlich bei FHEM als "Server" bleiben willst, dann musst du bei HM bleiben. IP geht nur mit CCU (oder Cloud) und ggf Anbidnung an FHEM per Modul HMCCU.
Dafür ist aber die WAF-Faktor höher da die Geräte m.E. besser aussehen.

zu 2:
Die Heizungssteuerung macht ja dein Thermostat, zB über die Wochenprogramme. Warum willst du jeden Tag manuel eingreifen? Dafür hat man doch eine Heimautomatisierung! Natürlich ist deine Steuerungsidee umsetzbar...aber der Weg über 1-2 Fensterkontakte an den wichtigsten Fenster hat schon was für sich. Und das kann ja auch wachsen....

Viele Grüße
Christian

[chris1284]

Frage 1: (ganz leicht)
Der Unterschied zwischen HM IP und dem 'alten' HM.
Sehe ich es richtig, dass ich mir HM IP sparen kann, wenn ich eh alles über FHEM mache, da ich da ja ein HM - Gateway nutze?

hm läuft über bidcos 868mhz. hm-ip basiert auf IPv6 und es ist, denke ich, die zukunft bei eq3 (auch wenn es bei der einführung immer hieß dass es das einsteigersortiment sein soll). allein dass sie das sortiment immer weiter dem alten bidcos anpassen vom umfang und neue funktionen wie cloud und sprachsteuerung per zb alexa pushen.

ob du dir es sparen kannst musst du wissen. du solltest nur beachten das du hm und hmip komponenten nicht direkt miteinander peeren kannst. was meinst du mit hm-gateway? grundsätzlich würde ich eine ccu2 oder einen pi mit HM-MOD-RPI-PCB und virueller ccu2 (YAHM zb ) empfehlen (und dann die HMCCU module in fhem) da man so beides nutzen (+ hm wired) und hm mit hmip über fhem (oder ccu skripte) verbinden kann. ich habe zb zu den alten komponenten an einigen stellen die hmip zwischenstecker im einsatz weil sie einfach platz sparen (und schicker aussehen).

Frage 2: (Heizung)
Ich habe nun 4 HM - Thermostate in 3 Räumen verteilt und einen Außensensor.
Den Außensensor lassen wir mal außer acht. Dann habe ich also 3 Thermostate (2 von den alten --> die mit dem Drehrad an der Seite) und einen vom neuen Modell (mit dem Einfach-Rahmen). Ich spare mir mal die genaue Typenbezeichnung (ihr wisst ja welche ich meine).

thermostate gibt es heizungsthermostate und wandthermostate... bei deiner beschreibung (die doch möglichst genau sein sollte mit zb modelbezeichnung) gehe ich davon aus das du wandthermostate meinst

Nun zur Frage, wie bekomme ich eine "schöne Heizungssteuerung" hin OHNE an jedem Fenster noch einen "Öffnungssensor" / "Drehgriffsensor" anzubringen, da das mein Budget sprengt, und in meinem alten Haus nichts mit Heizkostenamortisierung zu tun haben soll, sondern viel eher mit "ähhhh Spielerei / Vereinfachung".
Natürlich kommen an die Heizungen die HM-Stellantriebe ran.

die stellantriebe haben eine window open erkennung, auch ohne fensterkontakt. diese basiert auf einem schnellen tmperaturabfall. ich würde dir aber sensoren als bausatz mit elv-card und gutscheincodes (https://forum.fhem.de/index.php/topic,32996.150/topicseen.html) empfehlen. so hält sich der kostenfaktor in grenzen und wenn man intelligent plant reicht zb in einem raum mit 3 fenstern ein sensor wenn man dieses fenster immer mit öffnet.

bevor ich fensterkontakte hatte, habe ich einen 6-fach wandtasterbausatz gehabt den ich vor und nach dem lüften betätigt habe. jedes tatsenpaar war den entsprechenden stellantrieben der räume zugeordnet (wandtaster-buttons mit hm-cc-rt-dn peered) und hat die desired-temp auf 5°C gesetzt hat. nach dem lüften den 2. button gedrückt und es wurde wieder auf auto mode geschaltet. günstig und effektiv

P.S. Frage 3: Was sind das für ganz alte Stellantriebe, wo nur ein ganz kleines LCD drauf ist? die sind nicht sehr WAF-Konform, oder?

vergiss die einfach....

[Torben80]

@Chris1284:

Erst einmal vielen Dank für deine sehr ausführliche Antwort.

Zusammengefasst, wenn ich das richtig verstanden habe, "sollte" ich mir, wenn ich denn HM-IP nutzen möchte eine CCU2 holen, und diese dann über FHEM ansprechen?

Womit ich dann bei den nächsten beiden Frage bin.

1. Meine (und ja, du hast recht, es sind Wandthermostate) Wandthermostate paire ich dann mit der CCU2 und kann diese dann genau so auslesen als wenn ich sie über ein HM-UA-Gateway (WLAN HM-Mod-PCB-RPI) an FHEM angebunden hätte.

2. Ich paire dann auch die IP-Stellantriebe (also quasi ALLE HM produkte) mit der CCU2 und kann die Temperaturen usw trotzdem per FTUI-Widget aus FHEM heraus steuern?

Ich weiss dass ich das bestimmt hätte auch alles selber suchen / lesen können, aber ich hatte heute morgen nicht die Zeit mich noch in 2-3 Module einzulesen, sorry.

mfg und SCHÖNEN START in die Woche!
Es ist Monatg und keiner geht hin

Gruß Torben

[chris1284]

Zu 1 ja
Zu 2 ja, das verwerten der readings in zB TUI ist nicht wirklich davon abhängig ob einen cul,ccu,Hmuart oder was auch immer nutzt.

Du kannst auch das hm-mod-pcb-rpi als Schnittstelle direkt in fhem nutzen. Bis auf ein paar Spielereien wie Register direkt zu setzen(was die wenigsten brauchen) und der vccu hast du meiner Meinung nach keine Vorteile gegenüber einer echten ccu2 (oder YAHM). Ich sehe es eher als Nachteil kein hmip zu haben und jeden kleinen Konfigurationschritt  über endlose Befehle in cul_hm machen zu müssen statt in der ccu schnell zusammen zu klickern

[Torben80]

Ok, hört sich soweit gut und auch plausibel an. Wie oft muss ich denn auf das WebUI der CCU2 gehen? Ich habe etwas gelesen, wegen der RaspberryMatic geschichte, und da schwören natürlich alle drauf, da es ja soooo viel schneller ist bei allem.

Was sagt der Fachmann? Ich installiere (paire) eh nur einmal und den Rest mache ich über FHEM? Also habe ich eh keine großen Verzögerungen.

Gruß Torben

und danke noch einmal für seine "in meinen Augen" qulifizierten Antworten, die mich weiter bringen als RTFM

[chris1284]

du musst zum anlernen (pairing)auf die ccu2. in der regel machst du dabei gleich die konfig des devices und peerst es ggf mit anderen. später ist das aufrufen der gui der ccu2 kaum noch nötigt (evtl zum firmware-update oder zur umkonfiguration, wobei du das auch teils aus fhem machen kannst).

ja, die ccu2 oberfläche ist langsamer als die der raspimatic oder von yahm. der seitenaufbau geht gefühlt 50% schneller (allein am aufruf der webui verglichen braucht zb die ccu2 bei mir 7 sekunden, der pi ca 4 sekunden). sich den pi als ccu2 zu nehmen ist auch etwas günstiger (35€ pi + 20€ < ccu2 bausatz 80€). wenn du yahm statt raspimatic nutz sparst du dir auch noch den fhempi weil die ccu2 und fhem auf der selben kiste laufen können. man hinkt aber immer etwas hinterher weil die entwickler von yahm/raspimatic zb neu firmware erst einbauen müssen. ist aber halb so willt weil es sich meist nur um wenige tage handelt. bei der ccu2 installierst du sie einfach. raspberrymatic ist kompatibler zur ccu2 als yahm (zb kannst du nicht einfach backups aus yahm auf eine ccu2 spielen, bei raspimatic geht das ). muss jeder selbst wissen. als ich die ccu2 kaufte gab es noch kein raspimatic oder yahm, es gab lxccu was aber umständlich zu installieren und in den kinderschuehen steckte. mittlerweile würde ich zur raspimatic/yahm greifen weill wenn mir das ccu2 konstrukt in verbindung mit fhem nicht gefällt kann ich auch die hardware einfach direkt in fhem nutzen (hmuart und cul-hm). passt mir fhem nicht aber die cuu geschichte kann ich auf dem sleben pi (yahm natürlich vorausgesetzt) auch andere sachen probieren (ioBriker, openhab zb) ohne meine kernautomatisierung mit umbauen/neumachen zu müssen weil die ccu unabhängig von fhem, ioBrocker oder b openhab läuft. ich habe zb zeitschaltvorgänge alle in der ccu eingestellt anstatt at's in fhem zu bauen oder auch notifys in der ccu umgesetzt soweit möglich. so kann ich fhem abschalten aber zb geht morgens bei den fischen trotzdem das licht an