Fragen zum HMCCU Best Practice Guide

[HomeAlone]

Hallo zusammen,
ich versuche gerade nach der HMCCU BestPractices Anleitung meine HomeMatic Komponenten in fhem zu integrieren.
Die Firewall habe ich zuvor in der HomeMatic WebUI freigeschaltet (für beide APIs).

Ich bin die Anleitung Schritt für Schritt durchgegangen, bis zum Abschnitt "Neue Geräte anlernen". Irgend etwas stimmt aber noch nicht.

Im Abschnitt "Attribute" wird unter anderem darauf hingewiesen, dass das Schreiben der zuvor gesetzten Readings mittels

Code Auswählen Erweitern

attr d_ccu ccureadings 1
geschehen solle.
Dieses Attribut existiert in meiner HMCCU (CCU3 über HM-MOD-RPI-PCB) jedoch nicht. Folgende Attribute werden mir angeboten:

Code Auswählen Erweitern

d_ccu: unknown attribute ?, choose one of alias comment eventMap group room suppressReading userReadings verbose stripchar stripnumber ccuaggregate ccudefaults rpcinterfaces ccudef-hmstatevals ccudef-substitute ccudef-readingname ccudef-readingfilter ccudef-readingformat ccuflags ccuReqTimeout ccuGetVars rpcinterval rpcqueue rpcport rpcserver rpcserveraddr rpcserverport rpctimeout rpcevtimeout parfile substitute ccuget event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat timestamp-on-change-reading cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel widgetOverride userattr

Wurde das umbenannt? Müsste es eigentlich existieren und es ist hier schon etwas mit der Config im Argen?


Im Abschnitt "Neue Geräte anlernen" liefern die Punkte 3. und 4. bei mir identische Ergebnisse:

Code Auswählen Erweitern

get d_ccu devicelist als auch

Code Auswählen Erweitern

get d_ccu devicelist d_ccu als auch bei

Code Auswählen Erweitern

get d_ccu devicelist egalwasauchimmer
generieren folgenden Output:

Code Auswählen Erweitern

Read 3 devices with 65 channels from CCU
Über die HomeMatic WebUi habe ich bereits zwei 6-Fach-Taster angelernt. In der GUI sieht man auch, dass Events auf den einzelnen Kanälen ankommen, wenn ich die zugehörigen Tasten drücke.
Diese sollen mir laut HMCCU Best Practice Guide bei der Eingabe obiger Befehler ebenfalls angezeigt werden, jedoch ist wie erwähnt die Ausgabe immer gleich.
Daher habe ich mich auch noch nicht an die Device-Definition via MHCCUDEV gewagt.

Hier die internals / settings und readings der HMCCU:

Code Auswählen Erweitern

Internals
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.178.231
NAME d_ccu
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 91
NTFY_ORDER 50-d_ccu
RPCPID 28146
RPCPRC internal
RPCState running
STATE running/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 65
ccudevices 3
ccuif BidCos-RF
ccuinterfaces BidCos-RF,HmIP-RF,VirtualDevices
ccuip 192.168.178.231
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2/3
host 192.168.178.231
version 4.3.004

Readings
count_channels 65 2018-10-18 14:24:56
count_devices 3 2018-10-18 14:24:56
count_groups 0 2018-10-18 14:24:56
count_interfaces 3 2018-10-18 14:24:56
count_programs 0 2018-10-18 14:24:56
rpcstate running 2018-10-18 14:24:27
state OK 2018-10-18 14:24:27

Attributes
ccuaggregate name:battery,filter:name=^HM_.*,read:battery,if:any=low,else:ok,prefix:battery_,coll:comment!Batterien OK;
name:voltage,filter:type=(HM-PB-6-WM55|HM-CC-RT-DN|HM-TC-IT-WM-W-EU),read:BATTERY_STATE,if:le=2.2,else:0,prefix:voltage_,coll:comment!Batteriespannung OK;
name:lock,filter:name=^HM_TF.*,read:state,if:any=open,else:closed,prefix:lock_,coll:comment!Alle Fenster/Türen geschlossen;
name:unreach,filter:name=^HM_.*,read:activity,if:any=dead,else:alive,prefix:unreach_,coll:comment!Alle Devices erreichbar
ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;^(.+\.)?UNREACH$:activity
ccudef-substitute AES_KEY!(0|false):off,(1|true):on;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;UNREACH!(0|false):alive,(1|true):dead;MOTION!(0|false):noMotion,(1|true):motion;DIRECTION!0:stop,1:up,2:down,3:undefined;WORKING!0:false,1:true;INHIBIT!(0|false):unlocked,(1|true):locked
cmdIcon on:general_an off:general_aus
event-on-change-reading .*
eventMap /rpcserver on:on/rpcserver off:off/
room HomeMatic
rpcinterfaces BidCos-RF
rpcport 2001
rpcserver on
stateFormat rpcstate/state
stripnumber 1

Meine Frage: Was mache/verstehe ich falsch?

Viele Grüße
Sascha

[zap]

Die best practice ist an einigen Stellen leider veraltet. Das Attribut ccureadings gibt es nur noch bei HMCCUDEV und HMCCUCHN.  Beim IO Device sind die Readings per Default an und können per Attribut ccuflags mit noReading deaktiviert werden.

Get devicelist liest immer die Geräte der CCU aus. Wenn du es mit create aufrufst, werden automatisch Devices in FHEM angelegt. Dazu aber bitte erst die Dommandref lesen, sonst legt es dir uU ziemlich viele an oder eben bei wenigen Geräte erst mal per Hand mit define anlegen.

Wie ich sehe, hast du die Aggregationsregeln aus dem Wiki übernommen. Die musst du natürlich auf deine Config bzw. Deine Device namen anpassen.

[HomeAlone]

Die best practice ist an einigen Stellen leider veraltet. Das Attribut ccureadings gibt es nur noch bei HMCCUDEV und HMCCUCHN.  Beim IO Device sind die Readings per Default an und können per Attribut ccuflags mit noReading deaktiviert werden.

Get devicelist liest immer die Geräte der CCU aus. Wenn du es mit create aufrufst, werden automatisch Devices in FHEM angelegt. Dazu aber bitte erst die Dommandref lesen, sonst legt es dir uU ziemlich viele an oder eben bei wenigen Geräte erst mal per Hand mit define anlegen.

Wie ich sehe, hast du die Aggregationsregeln aus dem Wiki übernommen. Die musst du natürlich auf deine Config bzw. Deine Device namen anpassen.

Erst einmal vielen Dank für Deine Antwort!
Was mir geholfen hat, ist der Parameter dump bei create. Wenn man
get d_ccu devicelist create dump
eingibt, sieht man auch, dass das Pairing geklappt hat und versteht ein wenig, wie die HM-Geräte organisiert sind.

Letztendlich habe ich meine beiden Schalter mittels
get d_ccu devicelist create HM_*
erstellen können. Interessanterweise wurde die CCU selbst auch gepaired, obwohl sie mit HM- beginnt...

Jetzt stehe ich abermals auf dem Schlauch: Die Schalter wurden beide als Device angeleg (HMCCUDEV). Dort steht, dass dann die einzelnen Kanäle automatisch auch angelegt werden, jedoch kann ich diese nicht abrufen. In der config des Schalters kann ich lediglich die Elemente des Kanals 0 abrufen - interessanter wären aber 1 bis 6, da diese ja für die Taster sind. Via get deviceinfo sehe ich, dass die Kanäle erkannt wurden.
Drücke ich einen Taster erscheint hierzu auch nichts im Logfile (bei Verbose 5).
Im Event Log erscheint lediglich der Eintrag:

Code Auswählen Erweitern

2018-10-20 13:21:23 HMCCUDEV HM_sz_Zentraltaster hmstate: Initialized

Aufgrund des Hinweis von zap habe ich sicherheitshalber in einem zweiten Test die Aggregationsregeln einmal komplett gelöscht, was aber zu demselben Ergebnis führt.

Kann mir einer einen Tipp geben, wie ich an die einzelnen Tasten des HM-PB-6-WM55 komme?

Schon mal vielen Dank im Voraus.
Viele Grüße
Sascha

[zap]

Die CCU selbst wurde angelegt, weil du beim create gesagt hast, dass alles, was mit HM beginnt, angelegt werden soll. Vermutlich wäre HM-.* oder besser ^HM-.* die richtige Wahl gewesen.

Wenn die Readings in den Kanälen nicht kommen, musst du ccureadingfilter setzen. Entweder schaust du dir in der Ausgabe von get deviceinfo an, welche Datenpunkte dich interessieren und setzt dann ccureadingfilter auf einene entsprechenden regulären Ausdruck oder du setzt das Attribut auf .* für alle Readings.

Wenn es ein Taster ist, könnte PRESS ausreichen. Wenn PRESS vorkommmt, immer event-on-update-reading auf PRESS oder .* setzen.

[HomeAlone]

Die CCU selbst wurde angelegt, weil du beim create gesagt hast, dass alles, was mit HM beginnt, angelegt werden soll. Vermutlich wäre HM-.* oder besser ^HM-.* die richtige Wahl gewesen.

Wenn die Readings in den Kanälen nicht kommen, musst du ccureadingfilter setzen. Entweder schaust du dir in der Ausgabe von get deviceinfo an, welche Datenpunkte dich interessieren und setzt dann ccureadingfilter auf einene entsprechenden regulären Ausdruck oder du setzt das Attribut auf .* für alle Readings.

Wenn es ein Taster ist, könnte PRESS ausreichen. Wenn PRESS vorkommmt, immer event-on-update-reading auf PRESS oder .* setzen.

OK, ccudef-readingfilter in der d_ccu war das Problem. Habe das jetzt auf .* gesetzt, um erst mal herauszubekommen, was alles interessant ist. Zum Thema Tastendruck sind das die Events PRESS_SHORT und PRESS_LONG, PRESS_LONG_RELEASE.

Kommen auch im Event Log an:

Code Auswählen Erweitern

2018-10-20 18:27:34 HMCCUDEV HM_sz_Zentraltaster 1.INSTALL_TEST: 1
2018-10-20 18:27:34 HMCCUDEV HM_sz_Zentraltaster 1.PRESS_SHORT: 1
2018-10-20 18:27:34 HMCCUDEV HM_sz_Zentraltaster hmstate: Initialized
2018-10-20 18:27:44 HMCCUDEV HM_sz_Zentraltaster 1.INSTALL_TEST: 1
2018-10-20 18:27:44 HMCCUDEV HM_sz_Zentraltaster hmstate: Initialized
2018-10-20 18:27:49 HMCCUDEV HM_sz_Zentraltaster 1.PRESS_LONG: 1
2018-10-20 18:27:49 HMCCUDEV HM_sz_Zentraltaster 1.PRESS_LONG_RELEASE: 1
2018-10-20 18:27:49 HMCCUDEV HM_sz_Zentraltaster hmstate: Initialized
2018-10-20 18:28:13 MQTT unsecureMQTTBroker connection: active
2018-10-20 18:28:48 HMCCUDEV HM_sz_Zentraltaster 3.PRESS_SHORT: 1
2018-10-20 18:28:48 HMCCUDEV HM_sz_Zentraltaster 3.INSTALL_TEST: 1
2018-10-20 18:28:48 HMCCUDEV HM_sz_Zentraltaster hmstate: Initialized

Den Rest sollte ich (hoffentlich  ) hinbekommen.

Vielen Dank für die Hilfe!

[HomeAlone]

Nur der Vollständigkeit halber, falls es auch noch wer anderes probiert und sich ärgert, dass die finale Zuordnung hier noch fehlt:

Code Auswählen Erweitern

define sz_LichtArbeitszimmerEin notify HM_sz_Zentraltaster:1.PRESS_SHORT.* set az_Licht on
define sz_LichtArbeitszimmerAus notify HM_sz_Zentraltaster:2.PRESS_SHORT.* set az_Licht off


Oder generell (hoffe die Begrifflichkeiten sind korrekt getroffen):

Code Auswählen Erweitern

define <notifyName> notify <device>:<channel>.<event> <action>

Allerdings ist die Latenz doch ziemlich hoch - ca. 3-4 Sekunden.

[zap]

Hast Du im IO Device das Attribut ccuflags auf procrpc gesetzt? Falls nein, setzen, die Config speichern und FHEM neu starten. Das dürfte die Reaktionszeit drastisch verringern.

Bei den Geräten, die das unterstützen, würde ich immer die Direktverknüpfung in der CCU empfehlen. Das ist von der Reaktionszeit her nicht zu schlagen und kommt eben ohne CCU und ohne FHEM aus.

[HomeAlone]

Hast Du im IO Device das Attribut ccuflags auf procrpc gesetzt? Falls nein, setzen, die Config speichern und FHEM neu starten. Das dürfte die Reaktionszeit drastisch verringern.

Habe ich vorher nicht gemacht und jetzt versucht: Allerdings sieht es nicht so aus, als ob das gespeichert würde / ich es respektive speichern könnte. Lesen des Hinweis von fhem hat dann aber geholfen Ich habe das IO device deaktiviert und dann die Änderungen (attrib ccuflags procrpc) vorgenommen, gespeichert und neu gestartet.

Die Latenz ist jetzt OK: ca 1 Sekunde.

Bei den Geräten, die das unterstützen, würde ich immer die Direktverknüpfung in der CCU empfehlen. Das ist von der Reaktionszeit her nicht zu schlagen und kommt eben ohne CCU und ohne FHEM aus.

In meinem Fall nutze ich die HomeMatic Komponenten um andere (ZWave und EnOcean) damit zu schalten. Da die beiden meine "Zentraltaster" sind, kann ich so auch schnell einzelne Funktionen umbelegen.

So wie es jetzt ist, kann ich gut damit leben.

Dir noch mal ganz vielen Dank für die Hilfe, zap!