Neues Modul HMCCU für Homematic CCU

[Achiim]

Verständnisfrage: Das Ergebnis von get d_Stehlampe deviceinfo wird in einem Fenster angezeigt als:

Code Auswählen Erweitern


CHN MEQ0714259:0 HM-LC-Dim1T-Pl-3 MEQ0714259:0
  DPT {b} BidCos-RF.MEQ0714259:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.DUTYCYCLE = false [RE]
  DPT {8} BidCos-RF.MEQ0714259:0.RSSI_DEVICE = 1 [RE]
  DPT {8} BidCos-RF.MEQ0714259:0.RSSI_PEER = 44 [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.DEVICE_IN_BOOTLOADER = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.UPDATE_PENDING = false [RE]
  DPT {8} BidCos-RF.MEQ0714259:0.AES_KEY = 0 [R]
CHN MEQ0714259:1 WZ-Stehlampe-1
  DPT {6} BidCos-RF.MEQ0714259:1.LEVEL = 1.000000 [RWE]
  DPT {b} BidCos-RF.MEQ0714259:1.OLD_LEVEL =  [W]
  DPT {f} BidCos-RF.MEQ0714259:1.LEVEL_REAL = 1.000000 [RE]
  DPT {f} BidCos-RF.MEQ0714259:1.RAMP_TIME =  [W]
  DPT {f} BidCos-RF.MEQ0714259:1.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0714259:1.RAMP_STOP =  [W]
  DPT {b} BidCos-RF.MEQ0714259:1.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:1.ERROR_REDUCED = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:1.ERROR_OVERLOAD = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:1.ERROR_OVERHEAT = false [RE]
  DPT {i} BidCos-RF.MEQ0714259:1.DIRECTION = 0 [RE]
  DPT {b} BidCos-RF.MEQ0714259:1.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0714259:1.WORKING = false [RE]
CHN MEQ0714259:2 HM-LC-Dim1T-Pl-3 MEQ0714259:2
  DPT {6} BidCos-RF.MEQ0714259:2.LEVEL = 0.000000 [RWE]
  DPT {b} BidCos-RF.MEQ0714259:2.OLD_LEVEL =  [W]
  DPT {f} BidCos-RF.MEQ0714259:2.LEVEL_REAL = 1.000000 [RE]
  DPT {f} BidCos-RF.MEQ0714259:2.RAMP_TIME =  [W]
  DPT {f} BidCos-RF.MEQ0714259:2.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0714259:2.RAMP_STOP =  [W]
  DPT {b} BidCos-RF.MEQ0714259:2.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:2.ERROR_REDUCED = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:2.ERROR_OVERLOAD = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:2.ERROR_OVERHEAT = false [RE]
  DPT {i} BidCos-RF.MEQ0714259:2.DIRECTION = 0 [RE]
  DPT {b} BidCos-RF.MEQ0714259:2.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0714259:2.WORKING = false [RE]
CHN MEQ0714259:3 HM-LC-Dim1T-Pl-3 MEQ0714259:3
  DPT {6} BidCos-RF.MEQ0714259:3.LEVEL = 0.000000 [RWE]
  DPT {b} BidCos-RF.MEQ0714259:3.OLD_LEVEL =  [W]
  DPT {f} BidCos-RF.MEQ0714259:3.LEVEL_REAL = 1.000000 [RE]
  DPT {f} BidCos-RF.MEQ0714259:3.RAMP_TIME =  [W]
  DPT {f} BidCos-RF.MEQ0714259:3.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0714259:3.RAMP_STOP =  [W]
  DPT {b} BidCos-RF.MEQ0714259:3.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:3.ERROR_REDUCED = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:3.ERROR_OVERLOAD = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:3.ERROR_OVERHEAT = false [RE]
  DPT {i} BidCos-RF.MEQ0714259:3.DIRECTION = 0 [RE]
  DPT {b} BidCos-RF.MEQ0714259:3.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0714259:3.WORKING = false [RE]


Wie kann ich das in Verbindung bringen zu den in der CCU angezeigten Werten?

[Achiim]

Den Slider habe ich nun so definiert:

Code Auswählen Erweitern


define d_Stehlampe HMCCUDEV MEQ0714259 1
attr d_Stehlampe IODev myCCU2
attr d_Stehlampe ccureadings 1
attr d_Stehlampe controldatapoint 1.LEVEL
attr d_Stehlampe event-on-change-reading .*
attr d_Stehlampe statechannel 1
attr d_Stehlampe statedatapoint LEVEL
attr d_Stehlampe statevals on:1.0,off:0.0
attr d_Stehlampe stripnumber 1
attr d_Stehlampe substitute 1.0:on,0.0:off
attr d_Stehlampe webCmd control
attr d_Stehlampe widgetOverride control:slider,0,0.25,1,1


substitute hat noch keine Wirkung.

[Achiim]

Heute habe ich meinen PI2 mit der Testversion von gestern (neues 88_HMCCU.pm und ccurpcd.pl ) neu gestartet und im FHEM-Log folgendes entdeckt:

Code Auswählen Erweitern

2016.04.10 10:32:06 0: Server shutdown
2016.04.10 10:32:08 0: HMCCU: RPC server not running
Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug


Keine Ahnung, ob das eine Meldung von HMCCU ist....

[Achiim]

Solange der RPCServer auf meiner zentralen FHEM-Installation nicht läuft, habe ich mir wie folgt beholfen... Auch wenn's vielleicht etwas übertrieben erscheint.... 

1 Ich habe meine programmierbare  HM Fernbedienung (HM-RC-Dis-H-x-EU) über die CCU2 angemeldet, da ich mit der Konfiguration dieser über FHEM nicht klar kam. Dort habe ich mir zwei Funktionen (Rolladen hoch und Rolladen runter) auf die Fernbedienung gelegt.

2 Die CCU2 meldet nun über den registrierten rpcserver, der bei mir leider nur im Keller auf dem piKeller (PI3) läuft, jeden Tastendruck der Fernbedienung.

3 Über eine FHEM2FHEM-Verbingung habe ich mein FHEM auf dem piHägelesweg mit dem FHEM auf dem piKeller gekoppelt. Alle Ereignisse der Fernbedienung werden darüber zum zentralen FHEM übermittelt.

4 Über ein notify werden nun auf dem piHägelesweg alle Tastendrücke der HM-Fernbedienung registriert und ich steuere je nach gedrückter Taste den Rademacherrolladen im Wohnzimmer.


Kaum zu glauben, aber das funktioniert.... Herzlichen Dank für dieses tolle Modul ---> und es stimmt was zap uns hier verspricht: "best of both worlds approach"

[zap]

Hallo Achiim,

gerade nach Hause gekommen. Muss Deine Posts erst mal sortieren ...

Also der SL Event ist neu. Damit meldet ccurpcd.pl an HMCCU, dass er kurz davor ist, den RPC Server Loop zu starten. Eigentlich sollte HMCCU den Event kennen, vielleicht habe ich aber auch die falsche Version angehängt. Bist Du sicher, dass Du die Version 3.1b runtergeladen, installiert und auch in FHEM geladen hast?? Bei mir funktioniert das nämlich und die Meldung "unknown event" kommt auch nicht.

HMCCU bzw. HMCCUDEV/CHN liefern die offiziellen Datenpunkt-Namen, die man auch folgendem Dokument entnehmen kann:

http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf

Leider unterscheiden sich die Bezeichnungen in der CCU Weboberfläche von den Datenpunktnamen. Bei einigen kann man den Zusammenhang ableiten, bei anderen hilft nur ausprobieren. Dein Screenshot zeigt übrigens nicht die Datenpunkte sondern die Konfigurationsparameter. Diese werden mit get/set config gelesen oder gesetzt. Die Werte aus den Datenpunkten findest Du in der CCU z.B. unter "Status und Bedienung/Geräte".

Die Ausgabe von get deviceinfo ist übrigens sehr hilfreich, wenn man die interessanten Datenpunkte herausfinden möchte, um z.B. das Attribut ccureadingfilter zu setzen. Insbesondere die Angaben in den eckigen Klammern sind nützlich: R=Read, W=Write, E=Event. Bei einem Datenpunkt, der kein W hat, ist ein set Befehl sinnlos. Umgekehrt: Fehlt das R, kann man diesen Datenpunkt bei get ignorieren.

Ein gutes Beispiel sind Thermostate: Hier gibt es den Datenpunkt CONTROL_MODE, mit dem man den aktuellen Steuermodus auslesen kann [RE]. Eingestellt wird der Modus aber über MANU_MODE oder AUTO_MODE, beide [W].

Die folgende Meldung hat nichts mit HMCCU zu tun (ich schreibe immer "HMCCU:" davor):

Code Auswählen Erweitern


Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug


zum substitute beim Dimmer: Das kann nicht funktionieren, da substitute Fließkommazahlen ignoriert (sonst hat das unangenehme Seiteneffekte auf alle nummerischen Readings). Aber ich überlege mal, was man da machen kann. Blöd ist halt, dass der Dimmer kein STATE mit true oder false für ein / aus hat.

[Achiim]

Also:

Ich habe die Versions geprüft und habe unterschiedliche Angaben gefunden ....

In FHEM kommt mit ... "version 88_*"

Code Auswählen Erweitern


File           Rev   Last Change

88_HMCCU.pm    11140 2016-03-28 16:57:53Z fhemzap
No Id found for 88_HMCCUDEV.pm


In der von Dir gestern gelieferten 88_HMCCU.pm steht:

Code Auswählen Erweitern


#  88_HMCCU.pm
#
#  $Id: 88_HMCCU.pm 11140 2016-03-28 16:57:53Z fhemzap $
#
#  Version 3.1b
#
#  Module for communication between FHEM and Homematic CCU2.
#  Supports BidCos-RF, BidCos-Wired, HmIP-RF.
#
#  (c) 2016 zap (zap01 <at> t-online <dot> de)
#

Im Code von 88_HMCCU.pm  ist nur eine Stelle, die aus SL reagiert:

Code Auswählen Erweitern


elsif ($Tokens[0] eq 'SL') {
#### RPC Server going to start server loop ###
Log3 $name, 0, "HMCCU: Received SL event. RPC server ".$Tokens[2]." starting server loop.";
$hash->{hmccu}{rpc}{$Tokens[2]}{loop} = 1;
InternalTimer (gettimeofday()+$HMCCU_INIT_INTERVAL1, 'HMCCU_RPCRegisterCallback', $hash, 0);
return;
}


Das scheint alles okay und auch an der richtigen Stelle installiert zu sein... dann probiere ich es eben nochmal....

Code Auswählen Erweitern

2016.04.10 20:07:05 0: HMCCU: RPC server started with pid 2552
2016.04.10 20:07:29 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.10 20:07:34 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.10 20:07:35 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.10 20:07:40 0: HMCCU: Received IN event. RPC server CB2001 initialized.


Und siehe da... der RPC-Server läuft und läuft und läuft.....

Ich habe nix geändert... Einfach nochmal probiert und es tut.... 

War wohl irgendwie mein Fehler.... Gestern ist es spät geworden... Danke.

[Achiim]

Datenpunkte? Also für meine Stehlampe finde ich in der CCU unter "Status und Bedienung/Geräte":

[Achiim]

Bezogen auf die komische Meldung

Code Auswählen Erweitern


Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug

habe ich folgenden Hinweis gefunden:

https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1055551

Kann es sein dass die Meldung indirekt von Dir ist, da Du vermutlich mit ps prüfst, ob noch ein rpcserver läuft...

[zap]

Benutzt Du denn zsh statt bash? Nur da soll dieser Fehler auftreten.
Aber grundsätzlich: ja, ich nutze ps für die Prozessprüfung.

Zu den Datenpunkten: ja das meine ich. Das ansteigende Dreieck ist der Datenpunkt LEVEL. Du solltest Dir mal die PDF anschauen, die ich verlinkt hatte. Da wird für jedes Gerät jeder Datenpunkt mit Funktion beschrieben. Darauf greifst Du mit "get datapoint" oder "set datapoint" zu. set devstate ist nur ein Sonderfall von set datappoint eben für den statedatapoint.

Daneben gibt es noch die Config-Parameter. Hier werden interne Parameter der Geräte festgelegt, die keinen direkten Effekt auslösen sondern das generelle Verhalten eines Gerätes beeinflussen.

In der CCu werden die Datenpunkte möglichst einfach und grafisch dargestellt. Letztendlich greift die Weboberfläche aber auch nur auf Datenpunkte und Config Parameter zu.

Danke nochmal fürs Testen. Werde das morgen einchecken.

[Achiim]

Langsam verstehe ich die Bedeutung der Readings.... Aber intuitiv ist anders.... Das liegt aber eher an eQ3...


Noch eine Kleinigkeit..

Wie angeraten nutzte ich den ccureadingfilter und zwar mit der Einstellung: "^WZ-Stehlampe-1!(LEVEL|ON_TIME|RAMP_TIME|RAMP_STOP). Dieser Filter zeigt etwas mehr als ich erwartet hätte. Warum kommen auch die Readings "WZ-Stehlampe-1.LEVEL_REAL" und "WZ-Stehlampe-1.OLD_LEVEL" durch? Siehe screenshot.

[zap]

Langsam verstehe ich die Bedeutung der Readings.... Aber intuitiv ist anders.... Das liegt aber eher an eQ3...

Die Reading-Namen werden aus den Datenpunkt-Namen oder den Namen der Config-Parameter gebildet (dann mit "R_" davor, weil das CUL_HM auch so macht). Vielleicht noch gut zu wissen: Der RPC-Server aktualisiert nur Datenpunkte, keine Config-Parameter (kein Fehler sondern "ist halt so (EQ3)"). Aber ich denke, im täglichen Betrieb wird man die Config-Parameter eher selten nutzen. Wenn ich da was einstellen muss, mache ich das direkt in der CCU.

Wie angeraten nutzte ich den ccureadingfilter und zwar mit der Einstellung: "^WZ-Stehlampe-1!(LEVEL|ON_TIME|RAMP_TIME|RAMP_STOP). Dieser Filter zeigt etwas mehr als ich erwartet hätte. Warum kommen auch die Readings "WZ-Stehlampe-1.LEVEL_REAL" und "WZ-Stehlampe-1.OLD_LEVEL" durch? Siehe screenshot.

Der reguläre Ausdruck LEVEL matched alle Datenpunkte, die LEVEL enthalten. So dürfte es funktionieren:

^WZ-Stehlampe-1!(^LEVEL$|ON_TIME|RAMP_TIME|RAMP_STOP)

Wenn Du sowieso nur einen Kanal (hier WZ-Stehlampe-1) betrachtest, kannst Du "^WZ-Stehlampe-1!" auch weglassen. Dann bezieht sich der Filter auf alle Kanäle.

Eine weitere Vereinfachung, wenn Du bei einem Gerät nur einen Kanal verwendest, wäre HMCCUCHN statt HMCCUDEV effizienter. Dann sparst Du Dir z.B. bei set datapoint die Angabe der Kanalnummer.

In HMCCUDEV:

set xyz datapoint 1.LEVEL 0.5

In HMCCUCHN:

set xyz datapoint LEVEL 0.5

[tuppertasse]

In den nächsten 1-2 Wochen wird es ein Update geben, das wahlweise ohne den externen RPC-Server auskommt (verwendet dann einen internen Sub-Prozess).

Hi zap,
klappt das diese Woche mit deinem angekündigten Update ?
frage nur nach, da ich das wenn sofort ausprobieren wollte

[Achiim]

Verständnisfrage:

Wie definiere ich eine Rauchmeldergruppe? Gemäß Anleitung (Readme) finde ich folgendes:

Code Auswählen Erweitern


Define a new client device group:
   define <name> HMCCUDEV <ccu-group-device> [<state-channel>] [readonly]
      {group={<device>|<channel>}[,...]|groupexp=<expression>}


meine Interpretation dieser Syntax war wie folgt:

Code Auswählen Erweitern


define d_Rauchmelderteam HMCCUDEV *MEQ0257246 1 group=MEQ0257246,NEQ0197808
oder
define d_Rauchmelderteam HMCCUDEV Rauchmeldeteam 1 group=MEQ0257246,NEQ0197808


Beides liefert in FHEM: Invalid or unknown CCU device name or address

Update: Oh, da war ein Schreibfehler drin... Jetzt mit "r"

Code Auswählen Erweitern


define d_Rauchmelderteam HMCCUDEV Rauchmelderteam 1 group=MEQ0257246,NEQ0197808


liefert in FHEM: CCU device address not found for Rauchmelderteam


Die devicelist der HMCCU (get myCCU devicelist dump) sieht wie folgt aus:

Code Auswählen Erweitern


Rauchmelderteam
Rauchmelderteam:0
Rauchmelderteam:1
HM-RCV-50 BidCoS-RF
HM-RCV-50 BidCoS-RF:0
HM-RCV-50 BidCoS-RF:1
HM-RCV-50 BidCoS-RF:10
HM-RCV-50 BidCoS-RF:11
HM-RCV-50 BidCoS-RF:12
HM-RCV-50 BidCoS-RF:13
HM-RCV-50 BidCoS-RF:14
HM-RCV-50 BidCoS-RF:15
HM-RCV-50 BidCoS-RF:16
HM-RCV-50 BidCoS-RF:17
HM-RCV-50 BidCoS-RF:18
HM-RCV-50 BidCoS-RF:19
HM-RCV-50 BidCoS-RF:2
HM-RCV-50 BidCoS-RF:20
HM-RCV-50 BidCoS-RF:21
HM-RCV-50 BidCoS-RF:22
HM-RCV-50 BidCoS-RF:23
HM-RCV-50 BidCoS-RF:24
HM-RCV-50 BidCoS-RF:25
HM-RCV-50 BidCoS-RF:26
HM-RCV-50 BidCoS-RF:27
HM-RCV-50 BidCoS-RF:28
HM-RCV-50 BidCoS-RF:29
HM-RCV-50 BidCoS-RF:3
HM-RCV-50 BidCoS-RF:30
HM-RCV-50 BidCoS-RF:31
HM-RCV-50 BidCoS-RF:32
HM-RCV-50 BidCoS-RF:33
HM-RCV-50 BidCoS-RF:34
HM-RCV-50 BidCoS-RF:35
HM-RCV-50 BidCoS-RF:36
HM-RCV-50 BidCoS-RF:37
HM-RCV-50 BidCoS-RF:38
HM-RCV-50 BidCoS-RF:39
HM-RCV-50 BidCoS-RF:4
HM-RCV-50 BidCoS-RF:40
HM-RCV-50 BidCoS-RF:41
HM-RCV-50 BidCoS-RF:42
HM-RCV-50 BidCoS-RF:43
HM-RCV-50 BidCoS-RF:44
HM-RCV-50 BidCoS-RF:45
HM-RCV-50 BidCoS-RF:46
HM-RCV-50 BidCoS-RF:47
HM-RCV-50 BidCoS-RF:48
HM-RCV-50 BidCoS-RF:49
HM-RCV-50 BidCoS-RF:5
HM-RCV-50 BidCoS-RF:50
HM-RCV-50 BidCoS-RF:6
HM-RCV-50 BidCoS-RF:7
HM-RCV-50 BidCoS-RF:8
HM-RCV-50 BidCoS-RF:9
AZ-Rauchmelder
AZ-Rauchmelder:0
AZ-Rauchmelder:1
HM-RC-Dis-H-x-EU MEQ0670565
HM-RC-Dis-H-x-EU MEQ0670565:0
Stehlampe an-dim:1
HM-RC-Dis-H-x-EU MEQ0670565:10
HM-RC-Dis-H-x-EU MEQ0670565:11
HM-RC-Dis-H-x-EU MEQ0670565:12
HM-RC-Dis-H-x-EU MEQ0670565:13
HM-RC-Dis-H-x-EU MEQ0670565:14
HM-RC-Dis-H-x-EU MEQ0670565:15
HM-RC-Dis-H-x-EU MEQ0670565:16
HM-RC-Dis-H-x-EU MEQ0670565:17
HM-RC-Dis-H-x-EU MEQ0670565:18
HM-RC-Dis-H-x-EU MEQ0670565:19
Stehlampe aus-dim:2
HM-RC-Dis-H-x-EU MEQ0670565:20
WZ-Rolladen-hoch:3
WZ-Rolladen-runter:4
HM-RC-Dis-H-x-EU MEQ0670565:8
HM-RC-Dis-H-x-EU MEQ0670565:9
HM-LC-Dim1T-Pl-3 MEQ0714259
HM-LC-Dim1T-Pl-3 MEQ0714259:0
WZ-Stehlampe-1
HM-LC-Dim1T-Pl-3 MEQ0714259:2
HM-LC-Dim1T-Pl-3 MEQ0714259:3
SZ-Rauchmelder
SZ-Rauchmelder:0
HM-Sec-SD NEQ0197808:1


Leider gibt es die Option "dump" in der FHEM-Oberfläche für "devicelist" nicht, sodass man das über die Komandozeile eingeben muss, wenn man eine Liste der in HMCCU bekannten Geräte haben will.

Hinweis:
In der CCU sieht die Definition der Rauchmeldergruppe so wie auf dem Screenshot aus.

[zap]

Hi zap,
klappt das diese Woche mit deinem angekündigten Update ?
frage nur nach, da ich das wenn sofort ausprobieren wollte

Das Timing Problem mit dem RPC-Server Start hat mich ziemlich viel Zeit und Nerven gekostet. Ich muss die Änderungen jetzt erst mal in meine (eigentlich schon lauffähige) neue Version integrieren, damit nach dem nächsten Update das Problem nicht wieder da ist. Mal sehen
Hängt auch vom Wetter ab: Schlechtes Wetter => FHEM Entwicklung. Gutes Wetter => Mountain Bike.

@Achiim: Muss ich mir zuhause mal anschauen. Habe keine Rauchmeldergruppe, nur Heizungsgruppen. Wenn Du die Adresse der Gruppe verwendest, muss jedenfalls der "*" weggelassen werden.

Prinzipiell sehen Deine defines aber gut aus.

Was sagt denn "get myCCU deviceinfo Rauchmelderteam" ?

[Achiim]

Auf ... get myCCU deviceinfo Rauchmelderteam .... kommt:

Code Auswählen Erweitern


CHN *MEQ0257246:1 Rauchmelderteam:1
  DPT {b} BidCos-RF.*MEQ0257246:1.STATE = false [RE]
  DPT {b} BidCos-RF.*MEQ0257246:1.INSTALL_TEST =  [E]