Mit HomematicIP weiter machen

[Wernieman]

WLAN und Pi sind ein eigenes Thema, da sind esp deutlich stabiler (und können auch besser einen Stromausfall verkraften)

[ronzo]

Aber nochmal zurück zu HmIP. Geht doch auch mit nem Raspberry, demselben PCB? und piVCCU und entsprechender Firmware. Hätte ich dann praktisch ein LanGW für HmIP oder kann ich davon nur ein Stück einsetzen (anstatt wie jetzt 3 HmLanGws)?

[ronzo]

Aber: deine Stromrechnung...

Die Raspberries sind bei meiner Anzahl an Elektrogeräten schon wurscht... da würd ich mir höchstens einen kleinen esoterischen Betrag sparen.

[Christoph Morrison]

Ich hätte es gerne so simpel wie jetzt. Einfach ein HM-MOD-RPI-PCB zusammenlöten und unter Raspbian per Socat freigeben. Das Gefrickel für HmIP ist schon deutlich mehr Aufwand.

Dann haben wir wohl unterschiedliche Definitionen von "simpel". Simpel ist für mich: Ich kaufe ein Gerät für 15€, drücke in der CCU3 und auf dem Gerät eine Taste und das wars.
Nicht dass du mich falsch verstehst, ich löte hier auch Zeugs und hab DIY-HM-Devices, aber simpel sind die nicht. Was genau da Gefrickel musst du mir, auch als Nicht-HmIP-Fanboy, doch noch mal erklären.

[ronzo]

Dann haben wir wohl unterschiedliche Definitionen von "simpel". Simpel ist für mich: Ich kaufe ein Gerät für 15€, drücke in der CCU3 und auf dem Gerät eine Taste und das wars.
Nicht dass du mich falsch verstehst, ich löte hier auch Zeugs und hab DIY-HM-Devices, aber simpel sind die nicht. Was genau da Gefrickel musst du mir, auch als Nicht-HmIP-Fanboy, doch noch mal erklären.

Ich habe mich anfangs nicht vollständig meinen Standpunkt dargelegt. Habe jetzt 3 Raspberries mit dem PCB, die als HmLanGws agieren. Für HmIP würde ich das genauso auf Raspberry-Basis bevorzugen, da der eine oder andere Raspberry noch Zusatzaufgaben wahrnimmt (z.B. HUEBridge, oder BT LE Presence Check, ...). Für HmIP hätte ich gerne ein genauso gut funktionierendes Setup auf Raspberry-Basis.

[Wernieman]

Was ich bei Homatic so "toll" fand, war die Heizungssteuerung. Ventile an die Heizung, an CCU2 paaren und Profil einstellen. Eventuell (Meistens) die externe Steuerung/Sensor dran, Verbinden und das war es  ....

Da ich hier teilweise mehr als ein Heitzkörper steuern muß, also  mehrere pro Raum, geht so etwas auch per ZWAVE? Oder muß man da in FHEM "basteln"?

[Beta-User]

Was ich bei Homatic so "toll" fand, war die Heizungssteuerung. Ventile an die Heizung, an CCU2 paaren und Profil einstellen. Eventuell (Meistens) die externe Steuerung/Sensor dran, Verbinden und das war es  ....

Da ich hier teilweise mehr als ein Heitzkörper steuern muß, also  mehrere pro Raum, geht so etwas auch per ZWAVE? Oder muß man da in FHEM "basteln"?

Na ja, wo beginnt "basteln"?

"Theoretisch" müßte es auch Thermostatköpfe geben, die Profile verwalten können - praktisch gesehen habe jedenfalls ich die aber noch nicht, und das "Format", in dem man Profile übermitteln muss, ist auch "speziell"...

Aber eine ganze Anzahl von ZWave-Thermostaten (auch verschiedener Hersteller) in eine structure packen und die z.B. mit WeekdayTimer+weekprofile steuern, das sollte problemlos gehen, und auch "vituelle Raumtemperatursensoren" werden prinzipiell unterstützt - nur eben auf andere Weise "frickelig" wie bei CUL_HM (mit IP geht das afaik bisher nicht). (Oder je einen WDT für je einen Thermostaten; geht genauso und via weekprofile kann man auch komfortabel umschalten).

Kurz: Es ist anders, die Thermostate laufen nicht autonom (auf einem Wochenprogramm) und manchmal ist das Verständnis für die Abläufe verbesserungsfähig (siehe aktuelle Diskussion zum Spirit), aber prinzipiell ist es kein wirkliches Problem, wenn man FHEM an sich im Griff hat...

[Christoph Morrison]

Ich habe mich anfangs nicht vollständig meinen Standpunkt dargelegt. Habe jetzt 3 Raspberries mit dem PCB, die als HmLanGws agieren. Für HmIP würde ich das genauso auf Raspberry-Basis bevorzugen, da der eine oder andere Raspberry noch Zusatzaufgaben wahrnimmt (z.B. HUEBridge, oder BT LE Presence Check, ...). Für HmIP hätte ich gerne ein genauso gut funktionierendes Setup auf Raspberry-Basis.

Die HM-MOD-RPI-PCB unterstützt, wie ich auch erst kürzlich gelernt habe, ebenfalls HmIP. Ich habe nur noch keine Lösung gefunden (und auch nicht richtig gesucht), wie man einen RPI mit HM-MOD-RPI-PCB als abgesetztes LAN-GW für Hm-Classic und HM-IP nutzen kann. Alternativ könnte man natürlich eine eigene CCU3-Instanz mit was auch immer machen und die dann über FHEM/HMCCU koppeln.

[ronzo]

Vertragen sich mehrere CCU3-Instanzen (z.B. Pi mit piVCCU) bei HmIP?

[TL60]

Moin,
nach meinem Kenntnisstand kann man zumindest mit Raspberrymatic einen Pi mit dem HM-MOD-RPI-PCB als abgesetztes Funkmodul für Homematic (ohneIP) nutzen. Klingt etwas schizophren. Ein Raspberrymatic mit HM-MOD-RPI-PCB funktioniert als Gateway für Homematic classic und Homematic IP. Setzt man einen Pi mit demselben Modul als Langateway ein funktioniert die Reichweitenvergrösserung nur für Homematic Classic. Für Homematic IP müsste man einen IP Access-Point mit einer speziellen Firmware versehen und als Reichweitenverlängerung einsetzen. Siehe auch Doku zu rasperrymatic https://github.com/jens-maus/RaspberryMatic/wiki Hier unter Tipps und Tricks: HAP als HMIP-Gateway und unter Experten Features LAN-Gateway Betrieb. Ein solche Konstrukt lässt sich dann allerdings nur über das HMCCU Modul in FHEM einbinden.

[Horti]

@ronzo:

Es gibt für HMIP aktuell keine LAN-GW auf Raspberry-Basis. Es gibt die bereits angesprochene Möglichkeit mit den HAPs, wobei dann aber RPI-RF-MOD (als Hauptfunkmodul) zwingende Voraussetzung ist.
Das Hauptfunkmodul kann wiederum über LAN und HB-RF-ETH abgesetzt werden. Das Konstrukt HB-RF-ETH + RPI-RF-MOD oder HB-RF-ETH + HM-MOD-RPI-PCB ist dann auch eine Art LAN-GW, das wird aber nur 1x pro CCU unterstützt.
Beide Möglichkeiten kann man auch kombinieren, sofern RPI-RF-MOD verwendet wird.

[guhu]

Habe auch Homematic für die Heizkörper und ansonsten mit einigem herumexperimentiert.

Was mir gut gefällt und was ich ausbauen werde ich Zigbee. Davon habe ich derzeit Leuchten und Fensterkontakte und Schalter im Einsatz. Das mit DECONZ. Das gefällt mir sehr gut, weil es ziemlich problemlos läuft und durch das Mesh eine gute Verbindung fördert. Und das ganze ist -wie schon erwähnt- ein Standard, man ist also nicht von einer Firma abhängig. Preis-Leistungsverhältnis ist auch gut. Weiß allerdings nicht, ob es da auch Thermostate von gibt.

An Leuchten habe ich OSRAM derzeit und an Rest von Aqara (Schalter) bzw. Dresden (DECONZ-Stick).

[Beta-User]

Weiß allerdings nicht, ob es da auch Thermostate von gibt.

Gibt es zumindest einen, der auch von einzelnen FHEM-Usern verwendet wird: die ZigBee-Variante von dem Spirit. Gibt es auch attrTemplate für bei HUEDevice und MQTT2_DEVICE (falls wer das mit zigbee2mqtt verwenden will).
Die Einschränkungen sind aber afaik so ziemlich dieselben wie bei der ZWave-Variante (auch wenn das evtl. anders beworben wird).

Es gibt auch eine ganz gute "Datenbank" zu dem ZigBee-Zeug, der "(Wand-)Thermostate-Teil" ist hier zu finden: https://zigbee.blakadder.com/hvac.html (ergo: es gibt sogar Wandthermostate in ZigBee...).

[pcbastler]

Ich hänge mich mal hier dran, da ich ebenfalls umsteigen muss. Mein HM-Wassersensor hat den Geist aufgegeben und eine CCU2 habe ich aus einer Update-Aktion für lau bekommen. Idee war jetzt, die CCU2 als IO-Device für HmIP zu nutzen (das sollte mit HMCCUkein Problem sein) und mit einem HmIP-SWD zu beginnen. Leider übersteig die Auswertung der Readings des Sensors dann meinem Horizont
1.ALARMSTATE, 1.MOISTURE_DETECTED, 1.WATERLEVEL_DETECTED finden sich schon mal, jetzt brauche ich nur noch eine Alarmlösung (DebianMail bei Änderung des Alarmstate).

[Wernieman]

Die Readings hast Du doch schon, wo ist jetzt das Problem?