Neues Modul HMCCU für Homematic CCU

[aski71]

Hallo,

ich musste gerade meine CCU2 neustarten.
Danach hatte fhem keine richtige Verbindung mehr.
Erst nach einem "set ccu2 rpcserver off" und "set ccu2 rpcserver on" ging es wieder.

VG Alex

[zap]

Ich hoffe, der CCU Neustart wurde nicht wg. HMCCU notwendig.

Das von Dir beschriebene Verhalten bei Neustart der CCU ist normal. Grund: wenn der RPC Server gestartet wird, registriert er sich bei der CCU als Empfänger von Nachrichten. Leider vergisst die CCU beim Neustart ihre registrierten Empfänger. Daher sollte man vor einem CCU Neustart den RPC Server stoppen und später wieder starten.

[Loredo]

Merkt der RPC Server nicht irgendwie, dass die CCU Registrierung weg ist? Bei einem Stromausfall etc wäre es gut, wenn man nicht händisch eingreifen müsste.


Gruß
Julian

[zap]

Nein, der RPC Server ist rein passiv. Er meldet sich aber per Notification, wenn für eine bestimmte Zeit keine Events von der CCU kamen: "No events from CCU since xxx seconds". Das xxx legt man mit dem Attribut rpcevtimeout fest. Dann kann man per notify mit einem "set rpcserver restart" darauf reagieren.

Andere Möglichkeit: per ping device die Erreichbarkeit der CCU checken und bei Fehler mit mindestens 1 Minute Verzögerung den RPC Server neu starten.

[Loredo]

Hm, gehört so eine Logik nicht besser ins Modul, anstatt dass die sich jeder für sich (und doch wieder irgendwie gleich) zusammenstellt?


Gruß
Julian

[zap]

Mm ... ja. Könnte ich machen. So in der Art: wenn Attribut rpcevtimeout gesetzt ist, wird bei Ausbleiben der Events der RPC Server neu bei der CCU registriert. Das wäre auch effektiver als die Prozesse komplett neu zu starten.

Ist für die nächste Version vorgemerkt.

[aski71]

Super, danke!
Dafür hätte ich auch plädiert. 
Vielleicht sogar mit einem sinnvollen Default-Wert für rpcevtimeout vorbelegt?

[Loredo]

Ist für die nächste Version vorgemerkt.

Klingt gut


Hätte hier noch etwas zu fixen:

Code Auswählen Erweitern


Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE UNREACH|^HUMIDITY|^TEMPERATURE|^LOWBAT20 20/ at ./FHEM/88_HMCCU.pm line 976.



Hatte zuvor per set-Default ein paar Standard-Configs eingespielt (dürfte hier von einem TH sein).




Gruß
Julian

[zap]

Dürfte ein TH vom Typ HM-WDS40-TH-I sein. Kannst Du das FHEM Device rausfinden? Mich interessiert der Wert des Attributs ccureadingfilter. Sieht irgendwie seltsam aus in der Fehlermeldung mit dem "^LOWBAT20 20" am Ende. Der Default Wert für dieses Attribut endet eigentlich auf "^LOWBAT$".

Möglicherweise ist da beim Download der Datei HMCCUconf.pm etwas schief gegangen.

[Loredo]

Gibt es denn die Möglichkeit die Readings umzubenennen? Ich würde z.B. gerne "FL_Motion-1.LEVEL" gerne nur als "pct" haben, damit es dem Fhem Standard entspricht und man es mit :FILTER Ausdrücken einfacher/übersichtlicher hat. Ist denn angedacht die Readings irgendwie zu mappen? Meine vorher schön übersichtlichen DOIFs verkomplizieren sich extrem, vor allem auch wegen der Abhängigkeit den Devicenamen mit im Reading zu haben, wenn es sich um ein HMCCUDEV Device handelt.


Es ist ja prima, dass man schon so viel einstellen kann über die Attribute. Aber es ist schon sehr aufwändig das für jedes Gerät einzustellen. Könnte man beim zentralen HMCCU Device nicht einen get-Befehl (zwecks User-Absicherung kein set-Befehl) machen, der aus einer Liste alle in der CCU verfügbaren Geräte anbietet und man diese einfach auswählen und anlegen kann? Dabei könnte man auch hinterlegen ob es jetzt sinnvoller ist ein HMCCUDEV oder HMCCUCHN Device anzulegen. So richtig optimal scheint mir beides nicht immer zu sein, manchmal möchte man bei so simplen Geräten wie einem Fenstersensor eigentlich Kanale 0+1 als Kombination haben, es aber trotzdem als HMCCUCHN anlegen, um die ganzen Präfixes bei den Readings zumindest los zu werden.
Ich weiß, der setter "defaults" soll hier eigentlich helfen. Neben dem, dass er besser als getter aufgehoben wäre, damit normale User die Konfig nicht mutwillig verpfuschen können, gilt es hier wohl die Datenbank etwas zu füttern. Dazu würde ich gerne etwas beisteuern. Nur scheitere ich schon daran mit eine zufriedenstellende Konfig zusammen zu schrauben bzw. bin mir bisher bei keinem Device sicher, ob das tatsächlich nicht besser geht. Die bisherigen Defaults und Beispiele hier im Forum fand ich alle eher weniger praxistauglich :-/


Könnte man auch die Doppelbelegung von STATE als Reading auflösen (ist zB bei Fenstersensoren drin)? Ich weiß, es kommt wohl so aus der CCU heraus. Ist aber in Fhem so nicht gut aufgehoben.


Die grundsätzliche Anbindung der CCU finde ich schon gut gelöst. Wie ist denn der Plan das rund zu machen, um es produktiv nutzbar zu machen?




Gruß
Julian

[zap]

Die grundsätzliche Anbindung der CCU finde ich schon gut gelöst. Wie ist denn der Plan das rund zu machen, um es produktiv nutzbar zu machen?

Dein Beitrag hilft mir schon sehr, das "rund" zu machen. Auf solchen Input von Nutzern bin ich angewiesen, da ich bisher v.a. meine eigenen Anforderungen umgesetzt habe (ich nutze es bei mir in Verbindung mit Tablet-UI produktiv).

HMCCU verfolgt ein anderes Konzept als CUL_HM. HMCCU ist ein generischer Ansatz, in dem alle Feinheiten über Attribute definiert werden. Das hat den Vorteil, dass auch neue Homematic Geräte sofort genutzt werden können. Bei CUL_HM hingegen ist jeder Gerätetyp speziell implementiert. Das macht die Konfiguration für den Nutzer einfacher. Allerdings muss man bei neuen Geräten warten, bis die Unterstützung eingebaut ist und der Code wird extrem aufwändig (ok, das ist ein Problem des Entwicklers bzw. die Verlagerung der Komplexität in den Code).

Für einige Deiner Punkte kann ich mir zumindest Workarounds vorstellen. Mehr dazu demnächst. Die Geschichte mit den Devicenamen im Readingname bei HMCCUDEVs ist entstanden, da bei einigen Homematic Devices Datenpunkte mehrfach vorkommen. Zur Abgrenzung müsste ich zumindest die Kanalnummer in den Readingname aufnehmen. Bei HMCCUCHN ist das nicht notwendig, da sich das ja immer auf genau einen Kanal bezieht.

Aber danke für die Anregungen. Während die Finger das schreiben, arbeitet das Hirn schon daran

[Loredo]

Aber danke für die Anregungen. Während die Finger das schreiben, arbeitet das Hirn schon daran

Klasse 
Auch wenn mein Feedback nicht so strukturiert war und mir noch 1000 andere Dinge durch den Kopf gegangen sind. Ich schaue mal weiter, brauche aber irgendwie recht fix eine Lösung meine Grundfunktionen daheim wieder ans laufen zu kriegen. Die Reading Namen sind dabei nur ein Randschauplatz.


Ich habe wohl eine Menge Geräte, die noch keine Defaults haben. Ich würde dafür auch gerne Defaults liefern, tue mich aber sehr schwer herauszufinden wie ich die überhaupt definiere. Beispielsweise habe ich einen Dimmaktor und möchte dabei neben dem eigentlichen Dimmwert auch die Hochdimmzeit sowie eine Ausschaltzeit definieren. Über CUL_HM geht das ganz einfach und soweit ich weiß werden diese Werte auch alle an den HM Aktor übertragen und nichts davon bleibt in Fhem. Da stellt sich nun die Frage wie ich das mit HMCCU löse? Ich kann zwar den LEVEL-Wert übergeben, aber wie übergebe ich gleichzeitig noch andere Werte? Natürlich wäre es schön, wenn die ganzen Setter irgendwie kompatibel wären und auch so heißen. Den generischen control-Setter kann es ja trotzdem geben und ich finde den Ansatz, dass alle Geräte direkt funktionieren können sollen sehr gut. Für die Praxis braucht es aber irgendwie mehr Kompatibilität/Interoperabilität.


Kannst du mir irgendwie helfen, um da besser rein zu kommen, damit ich dann auch mithelfen kann die Defaults-Datenbank zu vergrößern?

[Ralli]

Ich erlaube mir mal, auf https://forum.fhem.de/index.php/topic,41060.msg429362.html#msg429362 zu verweisen und die Folgebeiträge. Inwieweit sich das hier mit HMCCU adaptieren lässt, weiß ich nicht.

Über einen XML-RPC-Aufruf geht das mit einem putParamset. Allerdings ist bei dem Dimmer wichtig, dass das putParamset in zwei Etappen durchgeführt wird, darum habe ich für das eigentlich einfache putParamset einen neuen Befehl implementiert, der das entsprechend aufteilt und durchführt.

[zap]

Ich habe wohl eine Menge Geräte, die noch keine Defaults haben. Ich würde dafür auch gerne Defaults liefern, tue mich aber sehr schwer herauszufinden wie ich die überhaupt definiere.

Grundsätzlich solltest Du für jedes Gerät folgende Attribute festlegen:

ccureadingfilter: Einige Gerätetypen liefern eine Unmenge an Datenpunkten. Ohne den Filter würde das zu sehr vielen Readings führen. Eine Liste der verfügbaren Datenpunkte liefert "get deviceinfo". In den Filter müssen nur Datenpunkte aufgenommen werden, die die Flags R=Read oder E=Event gesetzt haben. Die anderen sind Write Only.

statechannel bzw. statedatapoint: Legt fest, über welchen Kanal bzw. welchen Datenpunkt die Befehle "get devstate" und "set devstate" auf ein Gerät zugreifen. Wenn das nicht festgelegt ist, kann devstate nicht verwendet werden (Zugriff per get/set datapoint geht natürlich immer).

stripnumber: Legt fest. ob Fließkommawerte abgeschnitten oder mit allen Nachkommastellen in Readings gespeichert werden. Empfehlung wäre 1, d.h. 1 Nachkommastelle, wobei 2 nicht für 2 Nachkommastellen sondern für 0 Nachkommastellen steht.

substitute: Ersetzt bestimmte Werte aus der CCU durch sprechende Texte (z.B. true/1 => on, false/0 => off)

statevals: Umkehr von substitute, d.h. ersetzt FHEM Werte vor dem Senden an die CCU (z.B. on => true, off => false)

Das sind wie gesagt die Attribute, die ich immer für ein Device setze.  Wenn ich etwas mehr Komfort in der FHEM Oberfläche haben möchte, kommen noch Attribute wie controldatapoint, widgetOverride, cmdIcon usw. dazu.

Beispielsweise habe ich einen Dimmaktor und möchte dabei neben dem eigentlichen Dimmwert auch die Hochdimmzeit sowie eine Ausschaltzeit definieren. Über CUL_HM geht das ganz einfach und soweit ich weiß werden diese Werte auch alle an den HM Aktor übertragen und nichts davon bleibt in Fhem. Da stellt sich nun die Frage wie ich das mit HMCCU löse? Ich kann zwar den LEVEL-Wert übergeben, aber wie übergebe ich gleichzeitig noch andere Werte?

Habe leider keinen Dimmer, daher hier einige theoretische Tipps, die Du ggf. mal testen könntest: Wenn ein Homematic Gerät einen Datenpunkt ON_TIME anbietet (s.a. get deviceinfo), stellt HMCCUDEV automatisch einen Set-Befehl on-for-timer bereit, mit dem das Gerät für eine bestimmte Zeit eingeschaltet werden kann. Sollte bei einem Dimmer funktionieren, tut es aber leider nicht, weil ich da noch einen Bug drin habe (gerade gefunden).
Wenn zusätzlich noch die Ramp-Time mitgegeben werden soll, müsstest Du 2 bzw. 3 Befehle absetzen. Beispiel (LEVEL muss zuletzt gesetzt werden):

Code Auswählen Erweitern


set mydev datapoint 1.RAMP_TIME 3.0
set mydev datapoint 1.ON_TIME 600
set mydev datapoint 1.LEVEL 0.7


oder

Code Auswählen Erweitern


attr mydev statechannel 1
attr mydev statedatapoint LEVEL
attr mydev statevals on:1.0,off:0.0,half:0.5
set mydev datapoint 1.RAMP_TIME 3.0
set mydev datapoint 1.ON_TIME 600
set mydev half


Umbenennen von Readings: Wenn Du sofort eine Lösung brauchst, kann ich Dir momentan nur die Definition eines Userreadings empfehlen (umständlich, ich weiß). Aber ich arbeite daran, zumal es mich selbst stört, dass ich aufgrund des Devicenames im Reading einige sinnvolle Defaults nicht definieren kann.

[Achiim]

Sorry, dass ich eine Zeit lang nicht mehr online war... Aber nun meine erste Rückmeldung zu den neuen Funktionen und Änderungen:

Neue Funktionen und Änderungen in der Version 3.2:

• Homematic Gruppen werden nun uneingeschränkt unterstützt und vom RPC-Server aktualisiert. Hierzu muss das Attribut rpcport im IO Device (HMCCU) um den Port 9292 ergänzt werden. Das Attribut mapdatapoint in HMCCUDEV Devices wird damit obsolet.
• Unterstützung für Rauchmeldergruppen (CCU Adressen beginnen mit einem '*')
• Das Modul 88_HMCCU enthält nun einen RPC-Server. Um diesen zu aktivieren muss beim IO Device das Attribut ccuflags auf 'intrpc' gesetzt werden. Dann wird ccurpcd.pl nicht mehr verwendet.
• Das Attribut ccuverify bei HMCCUDEV Devices kennt nun den Wert 2. Dieser bewirkt, dass beim Setzen eines Datenpunktes in der CCU das zugehörige Reading in FHEM sofort (d.h. noch vor der Rückmeldung durch den RPC Server) aktualisiert wird. Dadurch könnte das "Springen" des Sliders bei der Bedienung eines Jalousienaktors über das Webinterface vermieden werden (bitte testen!)
• Mit dem Attribut 'substitute' können nun auch Fließkommawerte ersetzt werden, sofern sich eine Regel auf einen bestimmten Datenpunkt (Präfix 'Name!') bezieht.
• Das Attribut 'statedatapoint' akzeptiert nun die gleiche Notation wie 'controldatapoint', d.h. <channelnumber>.<datapoint>

Port 9292:

Habe ich zusätzlich zu 2001 gesetzt und keine "Auswirkung" wahrgenommen.

Rauchmeldergruppen
Kann jetzt definiert und der Status ausgelesen werden. Diese Gruppe kann als HMCCUDEV definiert werden. Dann hat sie 2 Channels. Den Channel 0 und 1. Channel 1 kann ausgelesen werden. Channel 0 geht imemr auf Error. In der CCU hat die Rauchmeldergruppe nur einen Channel.  Siehe auch screenshot im Anhang. Komisch, ist da noch in Bug?

ccuverify Wert 2
Der Rolladenaktor springt immer noch. Auch bei einem Dimmer ist das so.

ccuflags auf 'intrpc' gesetzt

Ich erhalte bisher nicht bekannte Einträge im logfile, die ich gerne verstehen würde.

Code Auswählen Erweitern


2016.06.12 11:35:53 2 : HMCCU: Create child process with timeouts 0.01 and 0.25
2016.06.12 11:35:53 0 : HMCCU: Child process for server CB2001 started with PID 22639
2016.06.12 11:35:53 2 : HMCCU: Create child process with timeouts 0.01 and 0.25
2016.06.12 11:35:53 0 : HMCCU: Child process for server CB9292 started with PID 22640
2016.06.12 11:35:53 0 : RPC server(s) starting
2016.06.12 11:35:56 0 : HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.06.12 11:36:03 1 : HMCCU: Registering callback http://192.168.178.15:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.06.12 11:36:05 1 : HMCCU: RPC callback with URL http://192.168.178.15:7401/fh2001 initialized
2016.06.12 11:36:08 0 : HMCCU: Received IN event. RPC server CB2001 initialized.
2016.06.12 11:36:08 0 : HMCCU: Received SL event. RPC server CB9292 enters server loop
2016.06.12 11:36:15 1 : HMCCU: Registering callback http://192.168.178.15:14692/fh9292 with ID CB9292 at http://192.168.178.16:9292/groups
2016.06.12 11:36:25 1 : HMCCU: RPC callback with URL http://192.168.178.15:14692/fh9292 initialized
2016.06.12 11:36:31 0 : HMCCU: Received IN event. RPC server CB9292 initialized.
2016.06.12 11:36:31 2 : HMCCU: Update of device VIR0000001 failed
2016.06.12 11:36:31 2 : HMCCU: Device *MEQ0257246:0 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:2 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:1 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Updated devices. Success=13 Failed=4
2016.06.12 11:36:31 1 : HMCCU: All RPC servers running


Was bedeutet z.B.: "HMCCU: Update of device VIR0000001 failed"


Den Rest habe ich noch nicht getestet. Weiters Feedback folgt.