Neues Modul HMCCU für Homematic CCU

Nic0205 · 13 April 2016, 06:00:34

Hallo zusammen,

Ich versuche mich immer mehr in die FHEM Welt einzuarbeiten und dabei dieses tolle Modul für meine Bedürfnisse zu nutzen.

Ich habe viel gelesen und bekomme es auch hin, einzelne Devices anzulegen, die werte abzufragen und auch der RPC läuft mittlerweile. Was ich mich aber frage ist, ob es eine Art Best practice Ansatz gibt. Beispiel : Aktuell lege ich jedes einzelne Homematic Device manuell an. Da gibt es doch bestimmt eine Funktion mit der ich alle Geräte aus der CCU als FHEM Devices auf einen Schlag anlege - oder z.B. das auxh selektiv für nur einzelne Gerätetyp wie z.B. jalousie Aktoren. Geht so etwas?

Und dann noch eine allgemeine Frage: was sind readings? Und wie definiert man diese mit hmdev? Kann man das auxh automatisieren ? Bitte seht mir meine vielleicht blöden Fragen nach, aber in diesem langen Thread habe ich die Antworten leider nicht gefunden. Viele grüße Nic

von unterwegs gesendet

zap · 13 April 2016, 11:44:09

Zitat von: Nic0205 am 13 April 2016, 06:00:34
Was ich mich aber frage ist, ob es eine Art Best practice Ansatz gibt. Beispiel : Aktuell lege ich jedes einzelne Homematic Device manuell an. Da gibt es doch bestimmt eine Funktion mit der ich alle Geräte aus der CCU als FHEM Devices auf einen Schlag anlege - oder z.B. das auxh selektiv für nur einzelne Gerätetyp wie z.B. jalousie Aktoren. Geht so etwas?

Auf ein Autocreate aller CCU Devices in FHEM habe ich bewusst verzichtet, da dies bei größeren Homematic Installationen zu einer Flut von FHEM Devices geführt hätte. Du kannst aber z.B. ein Device für einen Fenstersensor anlegen und das dann mit dem FHEM Befehl "copy" kopieren. Danach musst Du in der Oberfläche von FHEM in der Detailansicht der Kopie nochmal auf "DEF" klicken und die Adresse bzw. den Namen entsprechend dem 2. Fenstersensor anpassen. Andere Möglichkeit wäre, fhem.cfg direkt anzupassen. Davon rate ich aber ab, gerade wenn man mit FHEM noch nicht so vertraut ist.
Best Practice aus meiner Sicht: Je Typ ein Device in FHEM definieren. Die anderen vom gleichen Typ mit copy anlegen und nachträglich die Adresse anpassen.
Übrigens: HMCCUxxx hat kein Problem damit, wenn sich mehrere FHEM-Devices auf ein CCU-Device beziehen. Ich habe z.B. die Steckdosen mit eingebautem Energiezähler im Einsatz. Dafür habe ich ein Read-Only Device mit HMCCUCHN definiert, das nur die Messwerte darstellt und ein weiteres mit HMCCUDEV, über das ich die Steckdose schalte.

Zitat
Und dann noch eine allgemeine Frage: was sind readings? Und wie definiert man diese mit hmdev? Kann man das auxh automatisieren ? Bitte seht mir meine vielleicht blöden Fragen nach, aber in diesem langen Thread habe ich die Antworten leider nicht gefunden.

Kein Thema, jeder fängt mal an. Readings sind veränderliche Werte eines Gerätes. Das können Messwerte wie Temperatur oder Luftfeuchte sein oder auch Zusände wie offen oder geschlossen. Bei HMCCU, HMCCUDEV und HMCCUCHN entsprechen die Readings den Datenpunkten und Konfigurationsparameter der CCU Devices. Die Readings werden automatisch generiert, wenn Du einen get Befehl ausführts oder der RPC-Server Updates von der CCU empfängt. Da einige Homematic Geräte sehr viele Datenpunkte / Parameter haben und meist nur wenige davon wirklich interessant sind, macht es sinn, diese mit dem Attribut ccureadingfilter zu filtern. Außerdem sollte man das Attribut event-on-change-reading auf .* setzen. Sonst werden eine Menge FHEM Events generiert und die Performance leidet.

zap · 13 April 2016, 11:57:17

Zitat von: Achiim am 12 April 2016, 23:52:25
Ich habe jetzt eine Lösung dank deiner Hinweise implementiert. Ausgenutzt habe ich dabei folgende Sachverhalte:

rpcserver liefert unterschiedliche Werte bei update und bei einem echten Event aus der CCU ("1" bei echtem Tastendruck; "false" bei get c_WZ_Rolladen_... update)
rpcserver aktualisiert die Readings sowohl bei echten Events als auch bei "get ... update" oder beim "Start des rpcserver"

Schön, dass es jetzt funktioniert. Nur um das nochmal klar zu stellen: Die Updates durch get Befehle und die Updates durch den RPC-Server sind 2 völlig verschiedene Dinge. Das läuft in der CCU in 2 getrennten Schichten ab. Ein "get update" oder auch ein "get datapoint" fragt in der CCU Logikschicht den Zustand von Datenpunkten ab und setzt die Readings in FHEM entsprechend.
Unterhalb der Logikschicht werkelt die RPC-Schicht. Diese schickt bei Änderungen an CCU Devices die geänderten Werte an alle registrierten RPC-Server (einer davon ist der von HMCCU). Die RPC-Schicht weiß nichts von der Logikschicht, kennt z.B. nicht mal die Namen der Geräte in der CCU sondern nur die Adressen.

Wenn Du jetzt z.B. mit "set datapoint" einen Wert in der Logikschicht änderst, merkt das die RPC-Schicht und schickt den geänderten Wert an die registrierten RPC-Server (u.a. HMCCU) zurück. D.h. Du setzt z.B. einen Wert mit set datapoint auf true und der RPC-Server erhält von der CCU quasi als Bestätigung 1 zurück.

Grundsätzlich sollten Nutzer von CUL_HM bei Fernbedienungen vor ähnlichen Fragestellungen stehen. Du könntest also mal in diesem Forum suchen, wie CUL_HM Nutzer diese Thematik (Notifies) gelöst haben.

Achiim · 13 April 2016, 15:54:09

Ich habe mal im cul_hm Forum nach der Problematik gesucht und folgendes gefunden: https://forum.fhem.de/index.php?topic=43726.0. Da versucht MiWe58 eigentlich genau das, was ich auch tun will. Homematic-Fernbedienung und nicht-Homematic-Rolladen über FHEM zu "verbinden". Also genau das, was eine Stärke von FHEM sein soll, auszunutzen. Die Lösung bestand allerdings darin, statt des notify DOIF zu verwenden. Davon hattest Du mir ja abgeraten...

Es mit cul_hm umzusetzten war auch mein erster Ansatz, der ist aber ähnlich gescheitert, wie es MiWe58 erlebt hat. Eine zufriedenstellende Lösung habe ich nicht hinbekommen. Zumal ich das damals ohne CCU versucht hatte und schon an der korrekten Konfiguration der HM-RC-Dis-H-x-EU gescheitert war. Mehr als 3-4 Tasten konnte ich beim besten Willen (und vielen Fehlversuchen) nicht konfigurieren.... Das mag ja auch an mir und meinen ungenügenden Kenntnissen über HM gelegen haben. Jetzt mit CCU2 und dem Modul HMCCU kommt FHEM seinem Anspruch als Integrator eigentlich inkompatibler Systeme zu agieren wieder einen ganzen Schritt näher...

zap · 14 April 2016, 11:58:06

Erkenntnisse zur Verwendung von Fernbedienungen:

Ich habe nun mal den 2-fach Taster HM-PB-2-WM55 mit HMCCUDEV getestet.

1. Alle Datenpunkte (PRESS_SHORT, PRESS_LONG usw.) haben die Flags Write und Event, nicht jedoch Read gesetzt (s.a. get deviceinfo). Bedeutet: Ein get update liefert undefinierte bzw. unzuverlässige Ergebnisse, da ein explizites Lesen der Datenpunkte nicht erlaubt ist. Man ist also darauf angewiesen, dass die CCU Zustandsänderungen als Event an den RPC-Server schickt.

2. Die CCU schickt beim Drücken der Tasten am Taster nur dann Events, wenn die Tasten mit einem anderen Gerät verknüpft sind oder in einem CCU-Programm verwendet werden. Dieses Verhalten ist bekannt und einige User legen sich in der CCU Dummy-Programme an, die die Tastenzustände abfragen und eine Systemvariable auf irgendeinen Wert setzen um das Senden von Events zu erzwingen.

3. Die Events der CCU (z.B. zu PRESS_SHORT oder PRESS_LONG) enthalten immer eine 1 = Taste gedrückt. Einen Event "Taste nicht gedrückt" gibt es nicht. Konsequenz: event-on-change-reading darf nicht verwendet werden, stattdessen besser event-on-update-reading.

4. Die Datenpunkte PRESS_CONT und PRESS_LONG_RELEASE haben zumindest bei HM-PB-2-WM55 keine Funktion.

5. Bei jedem Tastendruck wird der Datenpunkt / Reading INSTALL_TEST mit 1 aktualisiert (könnte man auch als Tastendruckerkennung im Notify nutzen)

6. Ich würde für jede Taste bzw. jeden Kanal einer Fernbedienung ein HMCCUCHN Device definieren. Das hat den Vorteil, dass man den Zustand einer Taste über STATE darstellen kann.

In der nächsten Version wird der get update Befehl nur noch Datenpunkte / Readings aktualisieren, die das Flag "Readable" gesetzt haben. Damit dürften bei get update in Zusammenhang mit Fernbedienungen keine Probleme mehr auftreten.

Ein kleines Beispiel (Taste 1 = CCU Kanal FB-BA-1):

Code Auswählen


define HM_FB_BA_1 HMCCUCHN FB-BA-1
attribute HM_FB_BA_1 substitute 1:pressed
attribute HM_FB_BA_1 statedatapoint PRESS_SHORT
attribute HM_FB_BA_1 statevals press:true

Setzt STATE/state auf "pressed" wenn die Taste kurz gedrückt wird. Taste kann mit dem Befehl "set HM_FB_BA_1 press" kurz gedrückt werden.

Erkenntnisse zu Rauchmelder-Teams:

1. Rauchmelder-Teams sind keine CCU-Gruppen, sondern "Teams"

. Dementsprechend kann ein Rauchmelderteam in HMCCU bzw. HMCCUDEV nicht als Gruppen-Device (Zusatz group=...) angelegt werden. Das Anlegen einer reinen HMCCUDEV Gruppe ohne Bezug zur CCU ist zwar möglich, m.E. aber nicht sinnvoll.

2. Rauchmelder-Teams werden in der CCU wie ein eigener Gerätetyp behandelt. Die Adresse eines Teams ist die Adresse des Master-Rauchmelders mit einem Sternchen (*) davor. Momentan unterstützt HMCCU diese speziellen Adressen nicht. In der nächsten Version wird das aber der Fall sein.

3. Die Verwendung einzelner Rauchmelder wird jetzt schon von HMCCU uneingeschränkt unterstützt.

Nic0205 · 15 April 2016, 06:25:03

Hallo zap,

ich habe gerade einmal versucht meinen Raumthermostaten (noch den alten) einzubinden, scheitere aber irgendwie daran.

Bei State wird mir folgendes angezeigt:

Code Auswählen

Wohnzimmer_Heizung
T: Wohnzimmer_Heizung.1.TEMPERATURE° H: Wohnzimmer_Heizung.1.HUMIDITY% D: Wohnzimmer_Heizung.2.SETPOINT° P: n/a°

Meine config sieht so aus:

Code Auswählen

attr Wohnzimmer_Heizung IODev d_ccu
attr Wohnzimmer_Heizung ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SETPOINT|^LOWBAT$|^WINDOW_OPEN|^UNREACH)
attr Wohnzimmer_Heizung controldatapoint Wohnzimmer_Heizung.SETPOINT
attr Wohnzimmer_Heizung devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
attr Wohnzimmer_Heizung event-on-change-reading .*
attr Wohnzimmer_Heizung stateFormat T: Wohnzimmer_Heizung.1.TEMPERATURE° H: Wohnzimmer_Heizung.1.HUMIDITY% D: Wohnzimmer_Heizung.2.SETPOINT° P: DEWPOINT°
attr Wohnzimmer_Heizung statechannel 2
attr Wohnzimmer_Heizung stripnumber 1
attr Wohnzimmer_Heizung substitute LOWBAT!(0|false):no,(1|true):yes;;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
attr Wohnzimmer_Heizung userReadings DEWPOINT {HMCCU_Dewpoint($name,"Wohnzimmer_Heizung.1.TEMPERATURE", "Wohnzimmer_HeizungH.1.HUMIDITY","n/a")}

Kannst Du erkennen, was ich falsch mache?
Und wie würde ich den "statedatapoint" richtig setzen?

Ich hoffe Du kannst mir nochmal helfen.

Viele Grüße
Nic

zap · 15 April 2016, 09:11:03

Zitat von: Nic0205 am 15 April 2016, 06:25:03
Hallo zap,

ich habe gerade einmal versucht meinen Raumthermostaten (noch den alten) einzubinden, scheitere aber irgendwie daran.

Hallo Nic,

ich brauche den Typ des Thermostaten. Der wird in der Detailansicht des FHEM Devices im Feld "Internals" als "ccutype" angezeigt.

Wenn möglich noch die Ausgabe von "get Wohnzimmer_Heizung deviceinfo"

Nic0205 · 15 April 2016, 09:15:30

Hier die daten:

ccutype: HM-CC-TC

Ubd hier Device Info:
CHN IEQ0171822:0 Heizung Wohnzimmer:0 DPT {b} BidCos-RF.IEQ0171822:0.UNREACH = false [RE] DPT {b} BidCos-RF.IEQ0171822:0.STICKY_UNREACH = false [RWE] DPT {b} BidCos-RF.IEQ0171822:0.CONFIG_PENDING = false [RE] DPT {b} BidCos-RF.IEQ0171822:0.LOWBAT = false [RE] DPT {8} BidCos-RF.IEQ0171822:0.RSSI_DEVICE = 1 [RE] DPT {8} BidCos-RF.IEQ0171822:0.RSSI_PEER = 180 [RE] CHN IEQ0171822:1 Raumklima Wohnzimmer DPT {f} BidCos-RF.IEQ0171822:1.TEMPERATURE = 19.000000 [RE] DPT {i} BidCos-RF.IEQ0171822:1.HUMIDITY = 57 [RE] CHN IEQ0171822:2 Soll Temperatur Wohnzimmer DPT {f} BidCos-RF.IEQ0171822:2.SETPOINT = 19.000000 [RWE] DPT {i} BidCos-RF.IEQ0171822:2.ADJUSTING_COMMAND = 0 [RE] DPT {i} BidCos-RF.IEQ0171822:2.ADJUSTING_DATA = 3 [RE] DPT {b} BidCos-RF.IEQ0171822:2.STATE = [W]

OK

von unterwegs gesendet

zap · 15 April 2016, 12:08:49

Also grundsätzlich falsch ist da nichts (außer das Attribut controldatapoint). Werden denn die Readings gesetzt/angzeigt (z.B. Wohnzimmer_Heizung.1.TEMPERATURE) ?

Für die Attribute hätte ich noch folgende Tipps:

attr Wohnzimmer_Heizung ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SETPOINT|^LOWBAT$|^UNREACH)
attr Wohnzimmer_Heizung statedatapoint SETPOINT
attr Wohnzimmer_Heizung controldatapoint 2.SETPOINT
attr Wohnzimmer_Heizung statevals on:100.0,off:0.0

Der Datenpunkt SETPOINT akzeptiert 2 spezielle Werte: 0=Ventil zu, 100=Ventil komplett offen. Ansonsten geht der Wertebereich von 6 bis 30 Grad. Daher die Empfehlung mit dem Attribut statevals. Dann kannst Du z.B. mit "set Wohnzimmer_Heizung off" das Ventil komplett schließen.

aski71 · 15 April 2016, 17:39:20

Hallo,

kann einer von Euch Spezialisten einem verzweifelnden Newbie bitte erklären, wie man an einen Dimmer einen Drehknopf drangenagelt bekommt?

Ich habe mich schon tot gegoogelt, komme aber leider nicht weiter.

Mein letzter kläglicher Versuch ging so:

Code Auswählen


attr SZDimmer webCmd state
attr SZDimmer widgetOverride state:knob,min:0,max:1,step:0.1,lineup:round
attr SZDimmer statevals state:.*

Das zeigt mir zwar den Drehknopf an, aber jetzt weiß ich nicht, was ich bei statevals angeben muss, damit der Wert auch zurück geschossen wird.
Ich check das nicht.

Danke für Hilfe!

zap · 15 April 2016, 18:32:45

Normalerweise sollte ein Dimmer einen Datenpunkt LEVEL haben, über den die Helligkeit gesteuert wird. Das kannst Du mit dem Befehl "get SZDimmer deviceinfo" rausbekommen, der Dir alle Datenpunkte Deines Devices anzeigt.

Angenommen, Dein Dimmer hat einen Datenpunkt LEVEL in Kanal 1, sollte folgendes funktionieren:

Code Auswählen


attr SZDimmer controldatapoint 1.LEVEL
attr SZDimmer statechannel 1
attr SZDimmer statedatapoint LEVEL
attr SZDimmer statevals on:1.0,off:0.0
attr SZDimmer webCmd control
attr SZDimmer widgetOverride control:knob,min:0,max:1,step:0.1,lineup:round

Das Attribut statevals ermöglicht Dir in diesem Fall, den Dimmer mit "set SZDimmer on/off" komplett ein- oder auszuschalten.

Achiim · 15 April 2016, 21:55:58

Zitat
1. Alle Datenpunkte (PRESS_SHORT, PRESS_LONG usw.) haben die Flags Write und Event, nicht jedoch Read gesetzt (s.a. get deviceinfo). Bedeutet: Ein get update liefert undefinierte bzw. unzuverlässige Ergebnisse, da ein explizites Lesen der Datenpunkte nicht erlaubt ist. Man ist also darauf angewiesen, dass die CCU Zustandsänderungen als Event an den RPC-Server schickt.

Das ist auch so bei meiner Fernbedieung (HM-RC-Dis-H-x-EU). Siehe den Output von deviceinfo:

Code Auswählen


CHN MEQ0670565:0 HM-Fernbedienung:0 
  DPT {b} BidCos-RF.MEQ0670565:0.UNREACH = false [RE] 
  DPT {b} BidCos-RF.MEQ0670565:0.STICKY_UNREACH = false [RWE] 
  DPT {b} BidCos-RF.MEQ0670565:0.CONFIG_PENDING = false [RE] 
  DPT {b} BidCos-RF.MEQ0670565:0.LOWBAT = false [RE] 
  DPT {8} BidCos-RF.MEQ0670565:0.RSSI_DEVICE = 1 [RE] 
  DPT {8} BidCos-RF.MEQ0670565:0.RSSI_PEER = 197 [RE] 
  DPT {b} BidCos-RF.MEQ0670565:0.DEVICE_IN_BOOTLOADER = false [RE] 
  DPT {b} BidCos-RF.MEQ0670565:0.UPDATE_PENDING = false [RE] 
  DPT {8} BidCos-RF.MEQ0670565:0.AES_KEY = 0 [R] 
CHN MEQ0670565:1 Stehlampe an-dim:1 
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_SHORT = false [WE] 
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_LONG = false [WE] 
  DPT {b} BidCos-RF.MEQ0670565:1.INSTALL_TEST = false [E] 
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_CONT = false [E] 
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_LONG_RELEASE = false [E]
  ...

Zitat
In der nächsten Version wird der get update Befehl nur noch Datenpunkte / Readings aktualisieren, die das Flag "Readable" gesetzt haben. Damit dürften bei get update in Zusammenhang mit Fernbedienungen keine Probleme mehr auftreten.

Prima. Das wäre genau das, was ich brauche. Dann beeinflusst, ein get update auch nicht mehr vorhandene notifies, die auf Readings lauschen....

Nic0205 · 15 April 2016, 22:23:53

Hallo zap,

ZitatAlso grundsätzlich falsch ist da nichts (außer das Attribut controldatapoint). Werden denn die Readings gesetzt/angzeigt (z.B. Wohnzimmer_Heizung.1.TEMPERATURE) ?

ich mache mal einen Screenshot, wie es aussieht, irgendwie passt der State nicht.

aski71 · 15 April 2016, 23:40:46

Zitat von: zap am 15 April 2016, 18:32:45
Normalerweise sollte ein Dimmer einen Datenpunkt LEVEL haben, über den die Helligkeit gesteuert wird. Das kannst Du mit dem Befehl "get SZDimmer deviceinfo" rausbekommen, der Dir alle Datenpunkte Deines Devices anzeigt.

Angenommen, Dein Dimmer hat einen Datenpunkt LEVEL in Kanal 1, sollte folgendes funktionieren:

Code Auswählen Erweitern
attr SZDimmer controldatapoint 1.LEVEL attr SZDimmer statechannel 1 attr SZDimmer statedatapoint LEVEL attr SZDimmer statevals on:1.0,off:0.0 attr SZDimmer webCmd control attr SZDimmer widgetOverride control:knob,min:0,max:1,step:0.1,lineup:round

Das Attribut statevals ermöglicht Dir in diesem Fall, den Dimmer mit "set SZDimmer on/off" komplett ein- oder auszuschalten.

Danke zap!
So funktioniert's.
Das mit dem statedatapoint hatte ich schon rausgefunden. Aber nicht das mit dem controldatapoint.
Warum muss ich bei controldatapoint 1.LEVEL angeben und bei statedatapoint nur LEVEL?

VG Alex

P.S.: Die beschriebene Methode scheint auch nur zu funktionieren, wenn man das Gerät mit HMCCUDEV definiert. Mit HMCCUCHN geht's nicht.

zap · 16 April 2016, 09:42:07

Zitat von: Nic0205 am 15 April 2016, 22:23:53
Hallo zap,

ich mache mal einen Screenshot, wie es aussieht, irgendwie passt der State nicht.

Ah ja! Die Attribute stateformat und userreadings sind falsch. In beiden Attributen musst Du die Reading-Namen so verwenden, wie sie in FHEM angezeigt werden. stateformat ersetzt einfach die Readingnamen durch die Werte. So sollte es funktionieren:

Code Auswählen


attr Wohnzimmer_Heizung stateFormat T: Raumklima_Wohnzimmer.TEMPERATURE° H: Raumklima_Wohnzimmer.HUMIDITY% D: Soll_Temperatur_Wohnzimmer.SETPOINT° P: DEWPOINT°
attr Wohnzimmer_Heizung userReadings DEWPOINT {HMCCU_Dewpoint($name,"Raumklima_Wohnzimmer.TEMPERATURE", "Raumklima_Wohnzimmer.HUMIDITY","n/a")}