Taugt Homematic IP als alternative zu MAX!?

Begonnen von patlabor, 22 Januar 2020, 06:38:03

Vorheriges Thema - Nächstes Thema

patlabor

Hallo zusammen,

ich habe seit 2 Jahren das Heizungssytem von MAX! im Einsatz und bin damit leider sehr unzufrieden und habe massive Problme die scheinbar nicht wirklich zu lösen sind, vorher hatte ich FHT im Einsatz, dort war eigentlich alles gut.

Jetzt habe ich gerade eine Gelegenheit für je 45€ mehrere Homematic IP "Bild Edition" Startetsets zu bekmommen. Bisher habe ich mich mit Homematic (IP) wegen des hohen Preises und der doch etwas unübersichtlichen Konfiguration nicht beschäftigt.
Leider muss ich in gut einer Stunde auf die Arbeit, und müsste mich unmittlebar nach der Arbeit entscheiden ob ich die Sets will oder nicht. Daher habe ich leider so gut wie keine Zeit mehr selbst zu recherchieren, aber vielleicht kann mir ja hier jemand meine Fragen unkompliziert beantworten.

a) Zum Betrieb von Homematic IP benötigt man laut Wiki eine CCU2 oder neuer. Bei der Startset Box liegt laut Verpackung ein "Gateway" bei, ist dies eine CCU?

b)Lassen sich die Thermostate in Fhem ohne Einschränkungen verwenden, oder läuft das ganze dann doch über die Hersteller Cloud, und ich kann mit fhem nur mitlesen/schreiben?

c)Ich habe sämtliche Fenster mit Xiaomi Fensterkontakten versehen und benutze die via fakeShutterContact mit den MAX Thermostaten, gibt es eine solche Funktion auf für die Homematic Thermostate, oder bin ich dort auf die Homematic Fensterkontakte angewiesen?

Das sind natürlich alles Fragen die ich durch lesen selbst beantworten könnte, aber wie gesagt ich bin gleich auf der Arbeit und kann nichts mehr recherschieren, habe mich vorher noch nie mit Hommatic beschäftigt, müsste also bei 0 anfangen, und muss mich nach der Arbeit entscheiden, ob ich nach Hause fahren, oder in die entgegengesetzte Richtung und mir die Ventile gönne.

Danke schon mal im voraus für die Hilfe

Wzut

na hoffentlich ist das MAX Problem kein mechanisches, denn dann werden auch die HMs es nicht schaffen deine Ventile hundertprozentig dicht zu bekommen.
Ich melde auf alle Fälle schon mal Interesse an deinen Problemkindern an falls du heute Abend in die andere Richtung fährst ....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

MadMax-FHEM

#2
So, ich versuche mich mal an Antworten:

Zitat
a) Zum Betrieb von Homematic IP benötigt man laut Wiki eine CCU2 oder neuer. Bei der Startset Box liegt laut Verpackung ein "Gateway" bei, ist dies eine CCU?

Ja, du brauchst für den Betrieb über/durch fhem eine CCU2/CCU3. Das ist DIE Zentrale für alle Homematic (IP) Geräte und diese wird dann per HMCCU in fhem integriert. Von dort holt sich fhem die Daten und übergibt "Schaltbefehle" etc.

NEIN! Das Gateway ist (wohl) KEINE CCU. Sieht/klingt wie das "normale" Starter-Pack bei ELV: https://de.elv.com/homematic-ip-starter-set-raumklima-mit-access-point-heizkoerperthermostat-und-fensterkontakt-hmip-sk1-142546
Das geht dann nur mit Smartphone und Cloud!

D.h. du brauchst mindestens noch ein Funkmodul und die SW für eine CCU ("Charly", RaspberryMatic, piVccu, debmatic), sofern ein PI bereits vorhanden wäre (es geht auch der wo fhem schon läuft)...
Ansonsten halt auch noch den PI oder eben eine echte CCU...
Z.B.: https://de.elv.com/elv-komplettbausatz-funk-modulplatine-fuer-raspberry-pi-3-b-rpi-rf-mod-fuer-homematic-und-homematic-ip-152941
oder: https://de.elv.com/elv-homematic-komplettbausatz-funkmodul-fuer-raspberry-pi-hm-mod-rpi-pcb-fuer-smart-home-hausautomation-142141
(Bei Funkmodul vorher bei der geplanten SW [piVccu, debmatic, RaspberryMatic] schauen was dort so unterstützt wird)


Zitat
b)Lassen sich die Thermostate in Fhem ohne Einschränkungen verwenden, oder läuft das ganze dann doch über die Hersteller Cloud, und ich kann mit fhem nur mitlesen/schreiben?

Ja beides möglich (siehe oben). Allerdings NICHT mit dem Einsteigerset, CCU notwendig...


Zitat
c)Ich habe sämtliche Fenster mit Xiaomi Fensterkontakten versehen und benutze die via fakeShutterContact mit den MAX Thermostaten, gibt es eine solche Funktion auf für die Homematic Thermostate, oder bin ich dort auf die Homematic Fensterkontakte angewiesen?

Hmmm. Also so wie du das jetzt mit den FakeShuttern hast geht es auf alle Fälle mit Homematic OHNE IP ("Classic" / BidCos) und das dann direkt an fhem (also ohne CCU).
Ob das mit den Homematic IP geht weiß ich leider nicht.
Aber du hast 2 Möglichkeiten die gehen können:
entweder bietet die CCU etwas in der Richtung (da kann man mit Scripts wohl so einiges tun)
oder halt in fhem per Notify und setzen...

Wie geschrieben, ob das so direkt über FakeShutter geht: leider keine Ahnung...

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: MadMax-FHEM am 22 Januar 2020, 08:32:45
entweder bietet die CCU etwas in der Richtung (da kann man mit Scripts wohl so einiges tun)
oder halt in fhem per Notify und setzen...

Wie geschrieben, ob das so direkt über FakeShutter geht: leider keine Ahnung...
Habe den mir bekannten Stand der Dinge zu virtuellen Peers bei HMCCU.* (Achtung: Blinder spricht von Farbe...) mal hier zusammengetragen:
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Exkurs:_HMCCUDEV

Lt. dem dort verlinkten Thread sollten also virtuelle Fensterkontakte auch bei HMCCUDEV möglich sein, nicht aber virtuelle Raumthermostate. Aus HMCCUDEV würde ich ableiten, dass es nicht nur für den "alten" RT-DN gilt, sondern auch für HM-IP-Geräte gehen müßte...

Würde aber auch vorrangig mal nachsehen, ob es nicht irgendein mechanisches Problem gibt, was bei jeder Art Aktor Probleme machen wird...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

enno

Moin,

Zitat von: patlabor am 22 Januar 2020, 06:38:03
a) Zum Betrieb von Homematic IP benötigt man laut Wiki eine CCU2 oder neuer. Bei der Startset Box liegt laut Verpackung ein "Gateway" bei, ist dies eine CCU?

Falls du dich für Homematic IP entschliest, könnte ich dir eine fast ungenutzte CCU2 anbieten. Ich bin doch bei Homematic ohne IP geblieben.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC mit Proxmox und Debian

zap

Zitat von: Beta-User am 22 Januar 2020, 09:09:59
Habe den mir bekannten Stand der Dinge zu virtuellen Peers bei HMCCU.* (Achtung: Blinder spricht von Farbe...) mal hier zusammengetragen:
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Exkurs:_HMCCUDEV

Mit HMCCUDEV geht das nur, wenn der Sender ein Homematic Gerät ist. Im Falle von Fenstersensoren (nicht Homematic) an Thermostat (Homematic) also nicht.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Beta-User

Zitat von: zap am 22 Januar 2020, 16:43:36
Mit HMCCUDEV geht das nur, wenn der Sender ein Homematic Gerät ist. Im Falle von Fenstersensoren (nicht Homematic) an Thermostat (Homematic) also nicht.
Hmm, ok. Bei der Recherche für's Wiki war ich auf den Beitrag mit dem Titel HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor gestoßen, der ist dort auch verlinkt. Der hat sich von Ferne so gelesen, als ginge das.
Muß ich wohl wieder korrigieren... :(
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

patlabor

Hallo nochmal,

danke für die vielen und kurzfristigen Infos. Habe mich schlussendlich gegen  Homematic entschieden. Scheint wohl immer noch so wie ich es vor Jahren beim einstieg in FHEM enpfunden habe. Viel zu aufwendig und zu kompliziert um das ganze mal schnell nebenbei in Betrieb zu nehmen. Dann scheinen diese Sets ja nur ein Bruchteil von dem zu beinhalten was man für Homematic braucht.
Trotzdem danke für die Múhe und die Infos.

martinp876

Das mit verlinken verstehe ich nicht. Virtuellen device sind gebaut um solche triggern zu senden.
In culhm geht das problemlos. Wäre sehr seltsam wenn eine ccu das nicht unterstützt.  Muss natürlich über die zentrale laufen,  also kein direktes leeren. Neben dem fensterkontakt könnte man auch das remote Interface des rt nutzen.

Beta-User

Na ja, es ist vermutlich so, dass eQ-3 vorrangig darauf bedacht ist, Produkte (hier: WT's) zu verkaufen...

Speziell bei den virtuellen Peers für die HM-CC-RT-DN ist es doch so, dass man jeweils ein eigenes Device (mit 6-stelliger HmID) braucht, und dann max. zwei Kanäle verwendet. Um das mit CCUx abzubilden, müßte diese in der Lage sein, mehr als ihre 50 virtuellen Kanäle mit _einer_ bestimmten HmID abzubilden.
Und wie das bei HM-IP aussieht, ist wieder ein anderes Thema...
Ob und wie das ggf. doch geht, können ggf. CCUx-Experten wie zap, deimos oder Baden Power beantworten, ich habe für's erste nur versucht, den hier im Forum publizierten Stand ins Wiki zu übertragen und ändere das auch gerne wieder, sollte es was neues geben.
(Eventuell könnte man mit Hilfe von FHEM/CUL_HM etwas tricksen, denn - sollte ein indirektes peering via CCUx grundsätzlich gehen - die  CCUx müßte eigentlich ein darüber publiziertes "fake" Device akzeptieren, wenn es denn nur die erforderlichen Infos liefert (also vermutlich einen Gutteil der Registerwerte, die beim Pairen von CUL_HM angefragt werden).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

martinp876

Beachte, wenn ein aktor einen Sensor gepeert hat, auch virtuell, kann man einen testtrigger senden. Das ist speziell von eq3 implementiert.
Das kann man hervorragend zum koppeln Familien fremder devices zusammen mit virtuellen Kanälen als Stellvertreter nutzen.
Ich gehe davon aus, dass es auch bei hmip vorgesehen ist.
Nicht vergessen, dass eq3 min. 4 Familien kreuzweise verbinden muss und will.

Beta-User

Hmm, vielleicht zur Klarstellung:
Ich nutze keine CCUx, von daher ist das nicht "mein Anliegen" oder so. Dass es vermutlich irgendwie geht, nehme ich auch an. Es hat nur bisher (hier im FHEM-Umfeld) keiner einen Weg dokumentiert, wie man das mit einer CCUx umsetzt, that's all.

Diejenigen, die ein Interesse daran haben, können und dürfen das gerne umsetzen, ich dokumentier's dann ggf. auch. Nebenbei fände ich das auch ein gutes Argument für Technik aus dem Hause eQ-3, der ich ansonsten zwischenzeitlich eher skeptisch gegenüberstehe...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

zap

Zitat von: martinp876 am 25 Januar 2020, 21:10:02
Beachte, wenn ein aktor einen Sensor gepeert hat, auch virtuell, kann man einen testtrigger senden. Das ist speziell von eq3 implementiert.
Das kann man hervorragend zum koppeln Familien fremder devices zusammen mit virtuellen Kanälen als Stellvertreter nutzen.
Ich gehe davon aus, dass es auch bei hmip vorgesehen ist.
Nicht vergessen, dass eq3 min. 4 Familien kreuzweise verbinden muss und will.

Direkte Verknüpfung zwischen den einzelnen HM Familien sind leider nicht möglich. Das geht nur über Programme in der CCU. Dann reagieren die so verknüpften Geräte jedoch deutlich langsamer.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)