HMCCU Beispiel Geräte-Definitionen

[zap]

Mal sehen. Aus der Funktion ist mittlerweile ein FHEM Modul geworden. Das ist aber noch nicht soweit, dass man es veröffentlichen könnte. Habe auch schon mal überlegt, sowas direkt in HMCCU einzubauen ...

Die neue HMCCU Version hat momentan Prio.

[Chiemgauer]

Hat schon jemand eine Wetterstation von Homematic eingefügt?

[tuppertasse]

Habe ich mit readinggroup nicht hin bekommen und mir daher in myUtils eine Perl-Funktion dafür gebaut.

Hab es schon hinbekommen aber ist schon ziemlich aufwendig für viele devices zu definieren (siehe Anhang) - gibt ja immer verschiedene Möglichkeiten je nach Device.
Eine Integration wäre schon klasse :-)liebguck

[eddie8]

Sehr cool, vielen Dank!

Nur eine Frage: Warum genau die "Virtuelle Gerätegruppe aus Wand- und Heizkörper-Thermostat"? Es reicht doch eigentlich, wenn ich das Wandthermostat einfüge, das kann Temperatur und Luftfeuchtigkeit loggen, offenbar sogar den Fensterstatus vom Fenstersensor, und die Temperatur kann ich darüber auch setzen, was wiederum an das Heizungsthermostat übermittelt wird, da die gekoppelt sind. Richtig?

@DaDiGi
Haben Homatic IP Geräte an der CCU2 in der Konstellation mit FHEM irgendwelche nennenswerten Vorteile gegenüber "normalen" Homeatic-Thermostaten, oder warum hast du dich für die entschieden?

VG
Eddie8

[Vorhand]

Sehr gut diese Code-Beispiele.
Neben der grundsätzlichen Erklärung, ist ein konkretes Beispiel meist der beste Einstieg für mich.
Frage: muss der rpcserver nach einer Programmänderung in fhem manuell neu gestartet werden, obwohl das attr rpcserver on # Automatisch gesetzt ist?
Danke

[tuppertasse]

@Vorhand:
Also falls man über die fhem.cfg direkt editiert, dann wird der rpcserver sowieso neu gestartet automatisch.

Ich für meinen Teil mache es meistens über die KlickiBunti Oberfläche. Da brauchte ich bisher nie den rpcserver neu starten.

Wenn man aber komplexere neue define's einfügt, dann bitte sich meistens ein Neustart an --> ich starte dann aber komplett fhem neu.
rpcserver selber wird überwacht bei mir und automatisch neu gestartet wenn er sich beendet hat. Später implementiere ich noch Email Benachrichtigung dazu.

[chris1284]

@Vorhand:
Also falls man über die fhem.cfg direkt editiert, dann wird der rpcserver sowieso neu gestartet automatisch.
Da brauchte ich bisher nie den rpcserver neu starten.

... mehr oder weniger zuverlässig neugestartet müsste es heißen. es gitb offenbar stati da verträgt hmccu / der rpc keinen neustart von fhem (sei es über cfg-edit oder restart).
hatt ich gerade erst nach dem fhem in kurzer zeit 3-4 mal neugestartet / editiert wurde. danach musste ich den rpc per hand starten

[zap]

Bei einem "shutdown restart" wird normalerweise auch der RPC-Server gestoppt und neu gestartet (wenn das Attribut rpcserver = on ist).

Da der RPC-Server versucht, sich beim Stoppen korrekt bei der CCU abzumelden, kann es in einigen Fällen zu einem Timeout kommen. Das äußert sich dann so, dass FHEM runterfährt, der oder die RPC-Server Prozesse aber noch auf die CCU warten.

Bei einem Update gehe ich normalerweise so vor:

1. RPC-Server manuell stoppen und warten, bis auch der Status auf "stopped" geht
2. Update ausführen
3. shutdown restart

Bei der Definition von Geräten kann der RPC-Server weiter laufen. Wenn es da irgendwelche Seiteneffekte geben sollte, bitte melden. Das ist so nicht gewollt.

@eddie8: Natürlich kann man über das Wandthermostat das Heizkörperthermostat mit steuern. Auch der Status der Fenster wird über den Datenpunkt WINDOW_OPEN_REPORTING mitgeteilt. Das mit den virtuellen Gerätegruppen ist hilfreich, wenn man in der CCU ein Gruppendevice bestehend aus Wandthermostat, Heizkörperthermostaten und ggf. Fenstern angelegt hat. Das virtuelle Device in FHEM steht dann für das Gruppendevice in der CCU. Dann kannst Du über dieses virtuelle Device auf alle Datenpunkte aller Geräte dieser Gruppe zugreifen. Bitte beachten: Das Attribut rpcport muss um den Wert 9292 ergänzt werden, damit die Readings der CCU Gruppen automatisch in FHEM aktualisiert werden.

Hier eine Beispieldefinition.

Code Auswählen Erweitern


define HM_G_HZ_Bad HMCCUDEV G-BO-HZ group=KL-BO-HZ,KL-BO-TH
attr HM_G_HZ_Bad ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT|^VALVE|^CONTROL|^WINDOW_OPEN)
attr HM_G_HZ_Bad cmdIcon    Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr HM_G_HZ_Bad controldatapoint 1.SET_TEMPERATURE
attr HM_G_HZ_Bad event-on-change-reading .*
attr HM_G_HZ_Bad eventMap   /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
attr HM_G_HZ_Bad stateFormat T: KL-BO-TH.1.TEMPERATURE° H: KL-BO-TH.1.HUMIDITY% D: KL-BO-TH.2.SET_TEMPERATURE° P: DEWPOINT° V: KL-BO-HZ.4.VALVE_STATE% G-BO-HZ.1.CONTROL_MODE 
attr HM_G_HZ_Bad statedatapoint 1.SET_TEMPERATURE
attr HM_G_HZ_Bad stripnumber 1
attr HM_G_HZ_Bad substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
attr HM_G_HZ_Bad userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-BO-TH.1.TEMPERATURE", "KL-BO-TH.1.HUMIDITY","n/a")}, LOWBAT_STATE:(KL-BO-TH.0.LOWBAT|KL-BO-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(KL-BO-TH.0.LOWBAT|KL-BO-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","cnt","yes","")}
attr HM_G_HZ_Bad webCmd     control:Auto:Manu:Boost:on:off
attr HM_G_HZ_Bad widgetOverride control:slider,10,1,25


Wobei G-BO-HZ = CCU Gruppendevice, KL-BO-TH = Wandthermostat, KL-BO-HZ = Heizkörperthermostat

Sieht dann so aus wie im Anhang.

[eddie8]

Hätte vielleicht noch jemand ein Beispiel für einen Funk-Wandtaster 2-fach (HM-PB-2-WM55-2)?

[zap]

Hätte vielleicht noch jemand ein Beispiel für einen Funk-Wandtaster 2-fach (HM-PB-2-WM55-2)?

Ich habe einen HM-PB-2-WM55. Für jede der beiden Tasten habe ich ein HMCCUCHN Device definiert:

Code Auswählen Erweitern


define meinetaste HMCCUCHN TasterKanal1
attr meinetaste ccureadingfilter (LOWBAT|UNREACH|PRESS)
attr meinetaste ccureadingformat datapoint
attr meinetaste statedatapoint PRESS_SHORT
attr meinetaste statevals  press:true
attr meinetaste substitute 1|true:pressed


Wichtig ist, in diesem Fall nicht event-on-change-reading zu setzen sondern ggf. event-on-update-reading = .*

[eddie8]

Oh klasse, besten Dank! Funktioniert schonmal, sehe entsprechende Readings:
2.PRESS_SHORT    pressed     2016-10-11 23:30:42
state                       pressed     2016-10-11 23:30:42

Wenn ich jetzt noch lange drücken haben wollte, brauche ich dann weitere zwei devices und arbeite jeweils mit statedatapoint PRESS_SHORT?

Was ich nicht verstanden habe ist der letzte Satz:

Wichtig ist, in diesem Fall nicht event-on-change-reading zu setzen sondern ggf. event-on-update-reading = .*

Ich nehme an da geht es dann um Events ausführen, soweit bin ich noch nicht, aber vielleicht könntest du da auch kurz helfen? Ich habe das Device WoZi_Schalter (eine Fritz!Dect Dose via FBDECT; funktioniert bereits in FHEM), diese will ich jetzt nur mit dem einen Taster einschalten (aus geht automatisch). Also irgendwie muss jetzt wohl folgendes passieren:
event-on-update-reading = press_short ->  set WoZi_Schalter on

Theoretisch müsste man ja auch mehrere Dinge bei einem Tastendruck ausführen können, also etwa set WoZi_Schalter1 on && set WoZi_Schalter2 on ?

[zap]

Wenn Du länger auf eine Taste drückst, sollte es ein PRESs_LONG geben. Du brauchst auch nicht unbedingt für jede Taste ein Device zu definieren. Es geht auch ein einzelnes HMCCUDEV Device.

Schalte mal den Event Monitor in FHEM ein, drücke eine Taste und beobachte die Meldungen. Auf die Meldungen kannst Du in einem Notify reagieren und entsprechende Set Befehle auslösen. Das sind dann aber FHEM Basics. Schau Dir mal das Wiki zu Notify etc an.

[Kurt77]

Hallo,
wie würden die Attribute aussehen, die es ermöglichen, die Helligkeit beim Zwischenstecker HM-LC-Sw1-Pl-2 auszulesen?
Danke und Gruß,
Kurt

[zap]

Mit Attributen hat das erst mal nichts zu tun. Du definierst ein Device in FHEM mit dem Modul HMCCUDEV. Dann rufst Du für dieses Device "get deviceinfo" auf. Das zeigt Dir die Datenpunkte an. Du wirst bei einem Dimmer vermutlich einen Datenpunkt LEVEL finden, der die Helligkeit in Prozent enthält oder Werte zwischen 0 und 1.

Du kannst auch gleich "get update" ausführen. Dann werden die Datenpunkte in Readings geschrieben. Wenn der Helligkeits Datenpunkt z.B. 1.LEVEL ist, kannst Du mit "get datapoint 1.LEVEL" auch genau den Wert auslesen und in ein Reading speichern.

Lies einfach mal die Anleitung und diesen Thread. Da gibt es einige Beispiele auch für Attribute.

[faerberma46466]

Hat schon jemand das Wanddisplay HM-PB-4Dis-WM-2 eingebunden bzw. die in der CCU angelegten Befehle per fhem zum laufen gebraucht?
Mit HMCCUDEV kann der Device leicht angelegt werden allerdings komme ich danach nicht wirklich voran.
Und per HMCCUCHN hat es bei mir leider auch nicht funktionert

Grüße