Neues Modul HMCCU für Homematic CCU

zap · 18 September 2016, 18:27:15

Automatisch ermitteln kann HMCCU das derzeit nicht. Wenn Du die Rauchmelder manuell zusammenfassen willst:


define RM_Gruppe HMCCUDEV virtual group=AZ-Rauchmelder:1,WK-Rauchmelder:1,...

cho · 18 September 2016, 21:27:20

Zitat von: cho am 17 September 2016, 22:30:31
Hallo Zap,

ich versuche gerade meine HM Geräte via Deinem Modul und dem Homebridge Modul in Apple Home einzubinden.
Die Steuerung von einfachen Dummy Geräten funktioniert gut. Aber ich bekomme die HM Geräte dadrüber nicht zum Laufen. Hast Du schon mit Homebridge Erfahrungen gesammelt und weißt, wie die Attribute für HM Geräte am Besten zu setzen sind?

Viele Grüße
Christian

Hallo zusammen,

hat schon irgendjemand von Euch Erfahrung mit Zaps Modul und Homebridge gesammelt? Wie habt Ihr Eure HM Thermostate und Fensterkontakte für Homebridge konfiguriert?

Viele Grüße
Christian

ToM_ToM · 18 September 2016, 21:51:42

Hey, hat jemand von euch schon eine Wetterstation eingebunden?
Die Wetterstation an sich ist kein Problem, aber die Daten wie "Rain today" werden nicht im Device, bzw. Kanal gespeichert, sondern als System-Variable.
Systemvariablen kann ich ja mit

Code Auswählen

get CCU2 vars .* abfragen und bekomme dann die Daten

Code Auswählen

${sysVarRainToday}=0.000000 zurück.
In der Wetterstation gibt es ein Reading welches ob es aktuell regnet oder nicht, daher wollte ich irgendwie den Weg über das notify gehen. Wenn es regnet, dann starte einen Watchdog der alle 30 Sekunden die Systemvariable einliest um die CCU nur mit der Abfrage zu belasten wenn es regnet.

Idee war so etwas in der Art:

Code Auswählen

define RefreshTodayRainVolume notify HM_GN_Wetterstation.1.RAINING.yes {...hier dann die Abfrage mit get CCU2 vars ${sysVarRainToday} und das Schreiben der Daten in ein Reading...}

Aber ich glaube, das funtkioniert so nicht... oder (unabhängig davon dass ich das $ und die { } noch maskieren müsste)?

VG, Thomas

zap · 19 September 2016, 07:41:47

Die Systemvariable in der CCU heißt wirklich ${sysVarRainToday}? Wer denkt sich denn sowas aus?

Wenn ich mich recht erinnere, holt sich HMCCU bei einem "get vars" sowieso immer alle Variablen. Der Parameter legt nur fest, welche Variablen tatsächlich in einem Reading landen. Da das ein regulärer Ausdruck ist, sollte folgendes funktionieren:

Code Auswählen


get CCU2 vars sysVarRainToday

Kannst es ja mal manuell probieren.

Statt in FHEM ein Notify zu verwenden, könntest Du auch aus der CCU2 heraus ein Reading bzw. ein Dummy Device in FHEM auf den Wert setzen. Wie das geht, hatte ich schon mal irgendwo beschrieben. Du brauchst auf der CCU2 das Programm "nc" (NetCat) sowie am besten noch CuXD. Dann erstellst Du in der CCU2 ein Programm, das bei Änderung einer Variablen ausgeführt wird und entsprechende Werte an FHEM schickt.

Update: Hier ist der Beitrag:

https://forum.fhem.de/index.php?topic=42089.0

ToM_ToM · 19 September 2016, 14:33:59

Hallo zap,

habe mir das durchgelesen, aber ich möchte ungern irgendwas auf die CCU draufspielen.

Habe mir die Lösung jetzt so gebaut:

Code Auswählen

define RefreshTodayRainVolume notify HM_GN_Wetterstation.HM-WDS100-C6-O-2_NEQXXXXXXX.1.RAINING.yes { my $rainVolume = fhem("get CCU2 vars sysVarRainToday");; fhem("trigger RefreshTodayRainVolumeWatchdog .");; }
define RefreshTodayRainVolumeWatchdog watchdog HM_GN_Wetterstation.HM-WDS100-C6-O-2_NEQXXXXXXX.1.RAINING:yes.* 00:00:10 SAME { my $rainVolume = fhem("get CCU2 vars sysVarRainToday") =~ s/\$\{sysVarRainToday\}=//r ;; fhem("setreading HM_GN_Wetterstation RainToday $rainVolume");; fhem("trigger RefreshTodayRainVolumeWatchdog .");; }

Ich denke, der Ansatz ist ganz gut.
Aber irgendwie triggert der Watchdog nur einmal und läuft nicht alle 10 Sekunden wie ich es eigentlich wollte.

VG, Thomas

zap · 19 September 2016, 20:28:17

Ich habe gerade ein Update für 88_HMCCU.pm eingecheckt. Das dürfte allerdings erst morgen per Update verteilt werden (kenne den Aktualisierungszyklus von FHEM SVN nicht).

In dieser Version sollte der Bug im Attribut stripnumber behoben sein (wenn stripnumber = 2).

Der Befehl "get devicelist" des I/O Device wurde um eine Autocreate Funktion erweitert. Die alte Syntax geht natürlich auch noch. Die neue sieht so aus:

get name devicelist create <devexp> [p=<prefix>] [s=<suffix>] [f=<format>] [<attr>=<value> [...]]

Der Parameter devexp legt einen regulären Ausdruck für CCU Geräte- oder Kanalnamen fest. Für alle Namen, die auf diesen Ausdruck passen, werden Geräte in FHEM angelegt. Ich rate dringend davon ab, hier .* zu verwenden.

Wenn ein Präfix oder ein Suffix angegeben wird, werden die FHEM Gerätenamen entsprechend ergänzt. Format legt einen generellen Formatstring für den Gerätenamen fest. In allen drei Parametern können folgende Platzhalter verwendet werden:

%n = Geräte- oder Kanalname in der CCU
%d = Gerätename in der CCU (auch bei Kanälen)
%a = Adresse in der CCU

Die Regel ist also: FHEM-Gerätename = Präfix + Format + Suffix. Wobei der Default für Format %n ist. Default für Präfix und Suffix ist ein Leerstring.

Beispiel:

get myccu devicelist create ^KLIMA-WOHNEN.* p=HMKL_ f=%n_dev room=Homematic icon=rc_Home

aski71 · 19 September 2016, 20:38:58

Hi,

heute habe ich auf die offizielle HMCCU per fhem Update upgedated.
Seitdem funktioniert meine CUxD "Christbaum"-Steckdose nicht mehr.

Fehler:
HMCCUCHN Christbaum Invalid Datapoint

Defnition wie vorher:

Code Auswählen

define Christbaum HMCCUCHN Christbaum
attr Christbaum userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr Christbaum IODev ccu2
attr Christbaum ccureadingfilter (STATE|ON_TIME)
attr Christbaum ccureadings 1
attr Christbaum devStateIcon on:li_wht_on off:li_wht_off Initialized:10px-kreis-gelb
attr Christbaum event-on-change-reading .*
attr Christbaum group Lichter
attr Christbaum room Homekit,Wohnzimmer
attr Christbaum statevals on:true,off:false
attr Christbaum substitute STATE!true:on,false:off,1:on,0:off

Was ist da jetzt anders?
Wieso geht das nicht mehr?

VG alex

aski71 · 19 September 2016, 22:14:02

Zitat von: aski71 am 19 September 2016, 20:38:58
Hi,

heute habe ich auf die offizielle HMCCU per fhem Update upgedated.
Seitdem funktioniert meine CUxD "Christbaum"-Steckdose nicht mehr.

Fehler:
HMCCUCHN Christbaum Invalid Datapoint

Defnition wie vorher:

Code Auswählen Erweitern
define Christbaum HMCCUCHN Christbaum attr Christbaum userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 attr Christbaum IODev ccu2 attr Christbaum ccureadingfilter (STATE|ON_TIME) attr Christbaum ccureadings 1 attr Christbaum devStateIcon on:li_wht_on off:li_wht_off Initialized:10px-kreis-gelb attr Christbaum event-on-change-reading .* attr Christbaum group Lichter attr Christbaum room Homekit,Wohnzimmer attr Christbaum statevals on:true,off:false attr Christbaum substitute STATE!true:on,false:off,1:on,0:off

Was ist da jetzt anders?
Wieso geht das nicht mehr?

VG alex

Ergänzung: KEINE meiner CUxD Steckdosen geht mehr! Überall der gleiches Problem.
Umdefinition mittels HMCCUDEV: Gleiches Problem.
Danke für Hilfe....

zap · 20 September 2016, 07:26:58

Du musst vermutlich das Attribut statedatapoint setzen. Da ist HMCCU nun etwas sensibler geworden. Mach mal bitte ein get deviceinfo auf eines der Geräte und poste die Ausgabe.

aski71 · 20 September 2016, 07:46:12

Zitat von: zap am 20 September 2016, 07:26:58
Du musst vermutlich das Attribut statedatapoint setzen. Da ist HMCCU nun etwas sensibler geworden. Mach mal bitte ein get deviceinfo auf eines der Geräte und poste die Ausgabe.

statedatapoint habe ich auch schon versucht.
Keine Änderung, egal ob ich: state, STATE, oder Christbaum.STATE verwende.
Auch CUxD.CUX2801005:2.STATE, CUX2801005:2.STATE führt zu nichts.

Deviceinfo sieht so aus:

Code Auswählen

CHN CUX2801005:0 FritzDECT:0 
  DPT {b} CUxD.CUX2801005:0.LOWBAT = false [RE] 
  DPT {b} CUxD.CUX2801005:0.UNREACH = false [RE] 
  DPT {b} CUxD.CUX2801005:0.STICKY_UNREACH = true [RWE] 
CHN CUX2801005:1 Harmony 
  DPT {f} CUxD.CUX2801005:1.LEVEL = 0.010000 [RWE] 
  DPT {b} CUxD.CUX2801005:1.OLD_LEVEL =  [W] 
  DPT {b} CUxD.CUX2801005:1.STOP =  [WE] 
  DPT {b} CUxD.CUX2801005:1.STATE = false [RWE] 
  DPT {b} CUxD.CUX2801005:1.PRESS_SHORT =  [WE] 
  DPT {b} CUxD.CUX2801005:1.PRESS_LONG =  [WE] 
  DPT {b} CUxD.CUX2801005:1.CMD_RUNS =  [W] 
  DPT {b} CUxD.CUX2801005:1.CMD_RUNL =  [W] 
  DPT {s} CUxD.CUX2801005:1.CMD_KILL =  [W] 
  DPT {s} CUxD.CUX2801005:1.CMD_EXEC =  [W] 
  DPT {s} CUxD.CUX2801005:1.LOGIT =  [W] 
  DPT {s} CUxD.CUX2801005:1.SYSLOG =  [W] 
  DPT {s} CUxD.CUX2801005:1.CMD_SETS = $_P1$ switch $_C1$ 0 [RWE] 
  DPT {s} CUxD.CUX2801005:1.CMD_SETL = $_P1$ switch $_C1$ 1 [RWE] 
  DPT {s} CUxD.CUX2801005:1.CMD_RETS = 0 [RE] 
  DPT {s} CUxD.CUX2801005:1.CMD_RETL =  [RE] 
  DPT {b} CUxD.CUX2801005:1.CMD_QUERY_RET =  [W] 
  DPT {b} CUxD.CUX2801005:1.WORKING = false [RE] 
  DPT {i} CUxD.CUX2801005:1.CONTROL = 1 [R] 
  DPT {f} CUxD.CUX2801005:1.SET_STATE =  [W] 
  DPT {s} CUxD.CUX2801005:1.RAND = 54260 [RW] 
  DPT {b} CUxD.CUX2801005:1.INHIBIT = false [RW] 
CHN CUX2801005:2 Christbaum 
  DPT {f} CUxD.CUX2801005:2.LEVEL = 0.010000 [RWE] 
  DPT {b} CUxD.CUX2801005:2.OLD_LEVEL =  [W] 
  DPT {b} CUxD.CUX2801005:2.STOP =  [WE] 
  DPT {b} CUxD.CUX2801005:2.STATE = false [RWE] 
  DPT {b} CUxD.CUX2801005:2.PRESS_SHORT =  [WE] 
  DPT {b} CUxD.CUX2801005:2.PRESS_LONG =  [WE] 
  DPT {b} CUxD.CUX2801005:2.CMD_RUNS =  [W] 
  DPT {b} CUxD.CUX2801005:2.CMD_RUNL =  [W] 
  DPT {s} CUxD.CUX2801005:2.CMD_KILL =  [W] 
  DPT {s} CUxD.CUX2801005:2.CMD_EXEC =  [W] 
  DPT {s} CUxD.CUX2801005:2.LOGIT =  [W] 
  DPT {s} CUxD.CUX2801005:2.SYSLOG =  [W] 
  DPT {s} CUxD.CUX2801005:2.CMD_SETS = $_P1$ switch $_C1$ 0 [RWE] 
  DPT {s} CUxD.CUX2801005:2.CMD_SETL = $_P1$ switch $_C1$ 1 [RWE] 
  DPT {s} CUxD.CUX2801005:2.CMD_RETS = 0 [RE] 
  DPT {s} CUxD.CUX2801005:2.CMD_RETL = 0 [RE] 
  DPT {b} CUxD.CUX2801005:2.CMD_QUERY_RET =  [W] 
  DPT {b} CUxD.CUX2801005:2.WORKING = false [RE] 
  DPT {i} CUxD.CUX2801005:2.CONTROL = 1 [R] 
  DPT {f} CUxD.CUX2801005:2.SET_STATE =  [W] 
  DPT {s} CUxD.CUX2801005:2.RAND = 12157 [RW] 
  DPT {b} CUxD.CUX2801005:2.INHIBIT = false [RW] 
CHN CUX2801005:3 Balkonlicht 
  DPT {f} CUxD.CUX2801005:3.LEVEL = 0.000000 [RWE] 
  DPT {b} CUxD.CUX2801005:3.OLD_LEVEL =  [W] 
  DPT {b} CUxD.CUX2801005:3.STOP =  [WE] 
  DPT {b} CUxD.CUX2801005:3.STATE = false [RWE] 
  DPT {b} CUxD.CUX2801005:3.PRESS_SHORT =  [WE] 
  DPT {b} CUxD.CUX2801005:3.PRESS_LONG =  [WE] 
  DPT {b} CUxD.CUX2801005:3.CMD_RUNS =  [W] 
  DPT {b} CUxD.CUX2801005:3.CMD_RUNL =  [W] 
  DPT {s} CUxD.CUX2801005:3.CMD_KILL =  [W] 
  DPT {s} CUxD.CUX2801005:3.CMD_EXEC =  [W] 
  DPT {s} CUxD.CUX2801005:3.LOGIT =  [W] 
  DPT {s} CUxD.CUX2801005:3.SYSLOG =  [W] 
  DPT {s} CUxD.CUX2801005:3.CMD_SETS = $_P1$ switch $_C1$ 0 [RWE] 
  DPT {s} CUxD.CUX2801005:3.CMD_SETL = $_P1$ switch $_C1$ 1 [RWE] 
  DPT {s} CUxD.CUX2801005:3.CMD_RETS =  [RE] 
  DPT {s} CUxD.CUX2801005:3.CMD_RETL =  [RE] 
  DPT {b} CUxD.CUX2801005:3.CMD_QUERY_RET =  [W] 
  DPT {b} CUxD.CUX2801005:3.WORKING = false [RE] 
  DPT {i} CUxD.CUX2801005:3.CONTROL = 1 [R] 
  DPT {f} CUxD.CUX2801005:3.SET_STATE =  [W] 
  DPT {s} CUxD.CUX2801005:3.RAND = 50659 [RW] 
  DPT {b} CUxD.CUX2801005:3.INHIBIT = false [RW]

zap · 20 September 2016, 11:49:45

Ist das ein Dimmer (wegen dem Datenpunkt LEVEL)? Wenn es über STATE geschaltet wird, muss bei HMCCUDEV statedatapoint=1.STATE sein, bei HMCCUCHN hingegen nur STATE und das HMCCUCHN Device muss sich auf Kanal 1 beziehen.

Ansonsten setze mal ccuflags auf trace, führe dann ein Set datapoint aus und schau, was im FHEM.log dazu protokolliert wird.

aski71 · 20 September 2016, 13:18:21

Zitat von: zap am 20 September 2016, 11:49:45
Ist das ein Dimmer (wegen dem Datenpunkt LEVEL)? Wenn es über STATE geschaltet wird, muss bei HMCCUDEV statedatapoint=1.STATE sein, bei HMCCUCHN hingegen nur STATE und das HMCCUCHN Device muss sich auf Kanal 1 beziehen.

Ansonsten setze mal ccuflags auf trace, führe dann ein Set datapoint aus und schau, was im FHEM.log dazu protokolliert wird.

Nein. Das ist kein Dimmer. CUxD legt nur allerlei Allerlei an. Im Prinzip wird bei Veränderung des STATE von CUxD ein Shellscript mit dem richtigen Parameter aufgerufen. Das funktioniert auch nach wie vor hervorragend in der CCU Oberfläche, in der HC App (die direkt mit der CCU verbunden ist). Nur aus fhem seit dem Update gestern nicht mehr.

Hab ccuflags auf trace gesetzt und dann diverser set datapoint Kommandos ausprobiert.

Ergebnis im Log ist immer:

Code Auswählen

2016.09.20 13:14:50 1: HMCCUCHN: Christbaum Invalid datapoint

zap · 20 September 2016, 14:38:35

Bitte aktualisiere im iO Device nochmal die Deviceliste mit get Deviceliste
Danach nochmal das Set datapoint versuchen

aski71 · 20 September 2016, 14:49:25

Zitat von: zap am 20 September 2016, 14:38:35
Bitte aktualisiere im iO Device nochmal die Deviceliste mit get Deviceliste
Danach nochmal das Set datapoint versuchen

Auch schon mal gemacht.
Immer der gleiche Fehler.

Code Auswählen

set Christbaum datapoint STATE on
set Christbaum datapoint state on
set Christbaum datapoint Christbaum.STATE on
get Christbaum devstate
get Christbaum datapoint state
get Christbaum datapoint STATE

Das einzige, was zu gehen scheint, ist folgendes:
Wenn ich direkt mit der CCU-Oberfläche schalte und dann

Code Auswählen

get update
mache, dann wird der Ein-/Aus-Zustand ausgelesen und richtig dargestellt.
Die Readings Christbaum.STATE und state werden aktualisiert.

zap · 20 September 2016, 16:50:14

Habe die Ursache gefunden. Die CUxD Devices werden in der CCU mit einem bestimmten Typ angelegt (einem original Homematic Typ). Leider unterscheiden sich die Datenpunkte des CUxD Devices von denen des original Homematic Typen.

In Deinem Fall hat also die CUxD Steckdose andere Datenpunkte als eine Homematic Steckdose, wird aber als solche von der Zentrale verwaltet. Wenn HMCCU nun mit get devicelist alle Geräte der CCU abfragt, merkt es sich die verfügbaren Datenpunkte je Gerätetyp. Da hier 2 Devices sich als gleicher Gerätetyp ausgeben aber unterschiedliche Datenpunkte liefern, überschreiben sie sich gegenseitig. Das ist echt übel. Da muss ich erst mal drüber nachdenken, wie man das umgehen kann. Jedenfalls nicht ohne Update.