Homematic-IP Verständnisfrage

Begonnen von geforce28, 26 Januar 2018, 14:02:22

Vorheriges Thema - Nächstes Thema

geforce28

Hallo Leute,

ich muss einfach mal fragen, weil ich nicht weiß, ob ich alles, was ich jetzt so hier im Forum gelesen habe, richtig verstanden habe.
Habe aktuell das "alte" Homematic System, wo die Komponenten direkt mit FHEM über das LGW kommunizieren.

Wenn ich jetzt neue Komponenten kaufe, wollte ich eigentlich auf das neue HM-IP setzen, da (??) zukunftssicherer und besser verschlüsselt.
Dazu brauche ich, wenn ich es richtig verstanden habe eine CCU2 an die ich die HM-IP Geräte anlernen muss.
Mit der CCU2 kann dann wider rum FHEM sprechen und sich austauschen ...

In Bezug auf HM-IP Heizungsthermostate:
Kann FHEM direkt alles mit den Heizungsthermostaten machen über die CCU2, wie ich es mit den alten gemacht habe ?
Bspw. einen sog. Anwesenheitsmodus oder Urlaubsmodus einschalten, der dann die Heizungsschaltungen, wann die Heizung welche Temp. haben soll, ändert ??

Ist es auch weiterhin Möglich alles über FHEM zu monitoren, wie Device-States ? Batteriestatus ? Temperatur ? Status der Fensterkontakte ?
Funktioniert dies verzögert, weil der Weg über die CCU2 gegangen wird ?

Ich würde mich freuen, wenn ihr mir da ein bisschen Licht ins dunkle bringen würdet : )!

Vielen Dank im Voraus.

zap

#1
Zitat von: geforce28 am 26 Januar 2018, 14:02:22
Dazu brauche ich, wenn ich es richtig verstanden habe eine CCU2 an die ich die HM-IP Geräte anlernen muss.
Mit der CCU2 kann dann wider rum FHEM sprechen und sich austauschen ...

Ja.

Zitat
In Bezug auf HM-IP Heizungsthermostate:
Kann FHEM direkt alles mit den Heizungsthermostaten machen über die CCU2, wie ich es mit den alten gemacht habe ?
Bspw. einen sog. Anwesenheitsmodus oder Urlaubsmodus einschalten, der dann die Heizungsschaltungen, wann die Heizung welche Temp. haben soll, ändert ??

Grundsätzlich funktioniert das alles aus FHEM heraus mit HMCCU. Aber: Die Definition der Heizphasen in den einzelnen Programmen (Urlaub usw.) ist mit HMCCU sehr aufwändig. Da man das aber sowieso nur 1x macht, solltest Du die Heizprogramme in der CCU definieren. Da ist das über das WEbfrontend ganz gut gelöst. Aus FHEM heraus kannst Du dann die einzelnen Programme und Modi mit einem set Befehl aktivieren.

Zitat
Ist es auch weiterhin Möglich alles über FHEM zu monitoren, wie Device-States ? Batteriestatus ? Temperatur ? Status der Fensterkontakte ?
Funktioniert dies verzögert, weil der Weg über die CCU2 gegangen wird ?

Sicher, die Stati der Geräte werden von HMCCU automatisch aktualisiert. Dazu wird ein RPC Server verwendet. Derzeit gibt es zwei Arten von RPC-Server:

- Einer arbeitet mit Threads. Vorteil: Aktualisierung der Werte erfolgt quasi verzögerungsfrei (bei mir in 2 100stel Sekunden). Nachteil: es gibt Probleme mit Modulen, die JSON verwenden (dafür gibt es einen Workaround).
- Einer arbeitet mit Subprozessen und einer Queue: Vorteil: keine Probleme mit JSON. Nachteil: Reaktionszeit >2 Sekunden.

Vermutlich wird es demnächst einen dritten Weg geben, der die Vorteile von beiden Varianten verbindet ;-)
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

geforce28

#2
Vielen Dank für die Aufklärung...

Würdest du denn jetzt eher zu der HM-IP Lösung raten wenn ich jetzt neue Geräte kaufe ?...
Habe schon einiges der "normalen" HM-Serie.

Wie schätzt ihr denn die Vorteile in Bezug auf Sicherheit ein bei der HM-IP Lösung ?
Soll ja in Bezug auf Sicherheit schon sehr viel besser sein oder .. ?

Zitat- Einer arbeitet mit Threads. Vorteil: Aktualisierung der Werte erfolgt quasi verzögerungsfrei (bei mir in 2 100stel Sekunden). Nachteil: es gibt Probleme mit Modulen, die JSON verwenden (dafür gibt es einen Workaround).
Könntest du was genaueres dazu sagen ?
Was ist der Workaround ? Wo nachzulesen ?
Und gibt es eine Anleitung, die genau beschreibt, wie ich die CCU2 mit den HM-IP Geräten in FHEM einbinde ?...

zap

Schwer, da einen guten Rat zu geben. Momentan sieht es so aus, dass EQ3 vor allem HMIP pusht, dh. es gibt viel mehr neue Geräte für HMIP als für klassisches HM und sie sehen besser aus (Geschmacksache).

HMIP setzt auf verschlüsseltes IPv6 bei der Kommunikation. Von daher sicherer, was man auch daran sieht, dass es noch niemand geschafft hat, das zu analysieren für eine direkte FHEM Integration.

Du musst Dir nur darüber im Klaren sein, das HM und HMIP eben nur von einem Hersteller kommen. Alternativ könntest Du Dir zwave anschauen. Da gibt es Geräte von vielen Herstellern.

Anleitungen zu HMCCU gibt es im FHEM Wiki.

Die Thread Thematik ist seit gestern erledigt. Mit HMCCURPCPROC wird das Problem gelöst.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

geforce28

Okay danke...
Was ich jetzt bei der direkten Anbindung des "normalen" HM-Systems oft merke ist, dass Befehle immer nacheinander abgearbeitet werden, z.B. wenn man eine Gruppe von Schaltsteckdosen hat und diese gleichzeitig einschaltet werden nicht alle gleichzeitig angesprochen, sondern nacheinander.

Kann das "neue" HM-IP System schneller, bzw. parallel mit mehreren Geräten sprechen ?

Beta-User

Zitat von: geforce28 am 01 Februar 2018, 14:29:29
Okay danke...
Was ich jetzt bei der direkten Anbindung des "normalen" HM-Systems oft merke ist, dass Befehle immer nacheinander abgearbeitet werden, z.B. wenn man eine Gruppe von Schaltsteckdosen hat und diese gleichzeitig einschaltet werden nicht alle gleichzeitig angesprochen, sondern nacheinander.

Kann das "neue" HM-IP System schneller, bzw. parallel mit mehreren Geräten sprechen ?
Dass in Funksystemen Befehle immer nur nacheinander abgearbeitet werden können, weil sie sich sonst ins Gehege kommen, ist eigentlich klar.

Wenn du gleichzeitig wirksame Gruppenfunktionen brauchst, wäre das peeren mit einem virtuellen Button (bzw. mehreren) vielleicht eine Sache, die helfen könnte. Dann reagieren alle gepeerten Devices auf _ein_ Funksignal.

Geht recht einfach, wenn man eine VCCU hat (aber auch ohne).
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