Neues Modul HMCCU für Homematic CCU

[chris1284]

hier ist es halt zweischneidig da die handhabung in hmccu ja richtiger wäre als die von cul_hm (auch wenn es als erstes da war) weil es auf der offiziellen hm-doku aufbaut und man im script auf der ccu die selben readings (datenpunkte) wiederfindet....

[Loredo]

Deshalb macht es hier für mich auch Sinn beides parallel zu haben. Die userReadings sind ja genau dafür da. u.U. kann man aber auch zusätzlich noch etwas generisches ins Modul einbauen, welches neben der direkten 1-zu-1 Übernahme der CCU Datenpunkte für diese zusätzlich noch Readings anlegt und pflegt, die dann die Kompatibilität gewährleisten. Sollte eigentlich mit Hilfe dieses eq-3 Dokuments ziemlich einfach zu bewerten sein (habe auch schon darin gespickt für das HMCCUConf.pm Update). Das würde den komplexen userReadings-Verhau und auch die redundante Pflege der Templates in der HMCCUConf.pm reduzieren/vermeiden. Gleichzeitig bleibt die Flexibiltät des generischen Ansatzes aber erhalten, dass man neue und bisher unbekannte Geräte ebenfalls auch sofort nutzen kann. Im Gegenteil, ich sehe hier noch den Vorteil, dass man zusätzlich neu auf den Markt gekommene HM Gerät, die bereits bekannte CCU Datenpunkte verwenden, dann können diese auch direkt so verarbeitet werden wie bei all den anderen Devices auch bereits.

Beispielsweise kann man wohl davon ausgehen, dass die LEVEL Datenpunkte aus der CCU für die Kompatibilität immer auch zusätzlich als pct und level Readings verfügbar sein sollten (inkl. entsprechender Setter). Das wäre genauso generisch und unabhängig vom eigentlichen Device-Typ machbar, da eq-3 soweit ich das sehen kann schon sehr darauf achtet, dass sie einen Datenpunkt nicht doppelt und anders belegen. Datenpunkte mit dem gleichen Namen können also auch allesamt gleich behandelt werden.


Das einzige, was wirklich Device(typ) spezifisch bleibt ist auf jeden Fall die Berechnung von STATE. Das bliebe dann tatsächlich noch neben UI Anpassungen im Template übrig.

[Loredo]

[...] da die handhabung in hmccu ja richtiger wäre als die von cul_hm [...]

PS: es gibt hier wohl auch kein richtig oder falsch. Es gibt nur "legacy" und "neu" und die damit verbundene Frage, wie man die Brücken richtig baut. CUL_HM wurde eben AFAIK ohne eine offizielle eq-3 Dokumentation erstellt und daher kann man Martin da auch nicht sagen "du bist jetzt Schuld, dass dort alles gegen den eq-3 Standard funktioniert". Das wäre falsch und unfair. Richtig hingegen wäre es nun zu schauen, wie man als Fhem Gemeinde und zap als Modul Autor damit umgeht.


Es ist nunmal so, dass man für HMCCU nicht Fhem komplett umbauen wird und es auch weiterhin sehr gute Gründe gibt (und immer geben wird), dass Leute CUL_HM verwenden und nicht HMCCU. Allein deshalb sollte HMCCU nicht (nur) sein eigenes Süppchen kochen, möge es noch so nah an der echten eq-3 Welt sein. Ich denke diese Suppe funktioniert wie gesagt schon ganz hervorragend. Nun ist es Zeit für den nächsten Schritt sich der Fhem Welt anzunähern, damit das Modul auch irgendwann mal aus Contrib raus verschoben werden kann.

[zap]

Beispielsweise kann man wohl davon ausgehen, dass die LEVEL Datenpunkte aus der CCU für die Kompatibilität immer auch zusätzlich als pct und level Readings verfügbar sein sollten (inkl. entsprechender Setter). Das wäre genauso generisch und unabhängig vom eigentlichen Device-Typ machbar, da eq-3 soweit ich das sehen kann schon sehr darauf achtet, dass sie einen Datenpunkt nicht doppelt und anders belegen. Datenpunkte mit dem gleichen

Deine Worte in EQ-3's Ohr

Zumindest bei LEVEL werde ich das so implementieren, d.h. sobald ein Datenpunkt Level verfügbar ist, wird es einen "set pct" Befehl geben.

Die Readingnamen für Kanal 0 werden immer mit einem Punkt "." an den Devicenamen angeschlossen. Bei den höheren Kanälen (1,2,3 ...) ist es ein Bindestrich. Das ist inkonsequent und sollte vereinheitlicht werden

Das ist dann ein Bug. Der Aufbau der Readingnames ist immer (je nach Attribut ccureadingformat):

Kanalname.Datenpunkt
Kanaladresse.Datenpunkt
Datenpunkt (nur bei HMCCUCHN möglich)

Allerdings werden Zeichen im Kanalnamen, die nicht der FHEM Konvention für Readingnames entsprechen, nach folgenden Regeln ersetzt:

Aus : wird .
Aus allem, was nicht [^A-Za-z\d_\.-] ist, wird _

Wenn das bei Dir anders ist, zeig mal, wie die entsprechenden Kanalnamen in der CCU aussehen. Vielleicht gibt es hier noch einen Bug bei der Zeichenersetzung.

[Loredo]

Zumindest bei LEVEL werde ich das so implementieren, d.h. sobald ein Datenpunkt Level verfügbar ist, wird es einen "set pct" Befehl geben.

Der Setter kann ruhig "level" heißen, pct wäre aber als Alias trotzdem noch gut. In CUL_HM ist das ebenfalls aus Kompatibilitätsgründen so eingebaut (wenn das als Argument zählt). Es geht halt darum, dass man eine Schnittmenge zwischen mehreren unterschiedlichen Fhem-Devices erreicht (einige haben nur level, andere haben nur pct), wenn man z.B. :FILTER benutzt. HMCCU sollte nicht notwendigerweise einer der Kandidaten sein, der da ein Showstopper ist bzw. bei dem man dann doch wieder mit eventMap rangehen muss... 

Das ist dann ein Bug. Der Aufbau der Readingnames ist immer (je nach Attribut ccureadingformat):

Kanalname.Datenpunkt
Kanaladresse.Datenpunkt
Datenpunkt (nur bei HMCCUCHN möglich)

Anbei ein Screenshot eines HMCCUDEV, taucht aber so überall durchweg auf.

[zap]

ist doch ehr die frage, wer gibt die fhem standards für die readingsbezeichnung vor(das ältere modul? rudi? )...
denn es gibt keinen festgelegten reading-bezeichnungsstandard in fhem (wenn ja, habe ich die doku noch nicht finden können). Nur weil ein  großteil etwas auf eine bestimmte art und weise macht, macht es das nicht zum standard 

Es gibt eine Festlegung, welche Zeichen in einem Readingname zulässig sind (ich habe die Festlegung selbst "verbockt", weil ich im Rahmen der HMCCU Entwicklung mal danach gefragt habe). Nun wird jeder Readingname mit einem unzulässigen Zeichen beim Starten von FHEM mit einer Fehlermeldung "belohnt".

Für das Thema Template wird sich eine Lösung finden. Z.B. könnte man dem Nutzer die Angabe einer Textdatei erlauben, die seine persönlichen Templates enthält.

Dass HMCCU noch im Contrib Zweig ist, hat nichts mit irgendwelchen FHEM Namenskonventionen zu tun sondern damit, dass bisher der RPC-Server sowie das Handling der Filequeues als separate Dateiene implementiert waren und das Einchecken in den FHEM Zweig auf wenig Gegenliebe bei den FHEM-Wächtern gestossen ist . (Was ich durchaus verstehen kann). Seit Version 3.2 sind diese Hindernisse ausgeräumt.

@Loredo: Zu dem Readingname Problem: Wie heißen diese Kanäle in der CCU??

[Loredo]

Es gibt eine Festlegung, welche Zeichen in einem Readingname zulässig sind (ich habe die Festlegung selbst "verbockt", weil ich im Rahmen der HMCCU Entwicklung mal danach gefragt habe). Nun wird jeder Readingname mit einem unzulässigen Zeichen beim Starten von FHEM mit einer Fehlermeldung "belohnt".

Das war auch gut so
Zum Verständnis: Chris und ich haben uns über den Namen eines Readings ausgetauscht, nicht über den dafür zur Verfügung stehenden Zeichensatz.

@Loredo: Zu dem Readingname Problem: Wie heißen diese Kanäle in der CCU??

Soweit ich das jetzt gesehen habe, würde ich folgende Korrelationen sehen (im Format CCU -> FHEM):


LEVEL (range: 0-1, steps: 0.005) => level,pct (range: 0-100, steps: 0.5)
LOWBAT (boolean) => battery (0=ok,1=low)
MOTION (boolean) => motion (0=no,1=yes)
BRIGHTNESS (range: 0-255) => brightness (range: 0-255)
UNREACH (boolean) => Activity (0=active,1=dead)


All diese Datenpunkte kann man denke ich problemlos unabhängig vom Devicetyp übernehmen.
Setter brauchts nur bei LEVEL und dazu hast du dich ja schon geäußert.


Nicht ganz sicher bin ich, ob man DIRECTION auch problemlos generalisieren kann, da die Readingnamen in CUL_HM dann doch vom Einsatzzweck abhängen (bzw. glaube ich größtenteils in die Berechnung von STATE einfließt). Der Vollständigkeit halber aber trotzdem als Beispiel für einen Rollladenaktor:


DIRECTION (range: 0-3, steps: 1) => motor (0=none,1=up,2=down,3=undefined)

[zap]

Missverständnis: Wie heißen die Kanäle in der CCU, die in FHEM mit dem Bindestrich dargestellt werden?

Ich glaube, ich weiß was Du meinst. Das Problem ist: Der Kanal 0 wird von der CCU eigenständig hinzugefügt für Datenpunkte wie LOWBAT, UNREACH usw. Das jeweilige Gerät selbst hat nur die Kanäle 1-n. Und auch nur die können in der CCU individuell benannt werden. Der Kanal 0 hat hingegen immer den Namen des Geräts selbst. Da kann ich leider nichts machen. Dürfte sich aber erledigt haben, sobald es möglich ist, in HMCCUDEV auch Readings ohne Kanalname zu verwenden. Die Readings werden dann den Datenpunkten entsprechen. Wenn ein Datenpunkt in mehreren Kanälen vorkommt, wird die Kanalnummer mit einem Punkt vorangestellt, also z.B. 0.LOWBAT

[Loredo]

Ha ja na klar, ich habe die Kanäle in der CCU so benannt, natürlich. 

[Achiim]

Frage zu ccuscaleval

2) Skalierung von Werten beim Lesen, Schreiben und bei Events. Mit dem Attribut "ccuscaleval" kann je Datenpunkt ein Faktor festgelegt werden. Beispiel: Skalierung des Levels eines Dimmers auf 0-100 (in der CCU 0-1):

attr devname ccuscaleval LEVEL:0.01

Durch diese Angabe wird beim Lesen und bei Events der Wert durch 0.01 geteilt, bevor das Reading geschrieben wird. Beim Schreiben per Set-Befehl wird der angegebene Wert mit 0.01 multipliziert.

Ich habe die Version 3.3 geladen und für meinen Dimmer das neue Attribut "ccuscaleval" gesetzt. Leider kann ich keine Wirkung feststellen. Wo liegt mein Denkfehler?

Code Auswählen Erweitern


Internals:
   DEF        Keller-LED-Bar 1
   IODev      myHomematicCCU
   NAME       Keller_LED_Bar
   NR         1316
   STATE      0.0
   TYPE       HMCCUDEV
   ccuaddr    MEQ0343850
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Keller-LED-Bar
   ccutype    HM-LC-Dim1PWM-CV
   channels   4
   statevals  devstate|on|off
   Readings:
     2016-08-02 23:47:24   Keller-LED-Bar.0.AES_KEY off
     2016-08-02 23:47:24   Keller-LED-Bar.0.CONFIG_PENDING false
     2016-08-02 23:47:24   Keller-LED-Bar.0.DEVICE_IN_BOOTLOADER false
     2016-08-02 23:47:24   Keller-LED-Bar.0.DUTYCYCLE false
     2016-08-02 23:47:24   Keller-LED-Bar.0.RSSI_DEVICE on
     2016-08-02 23:47:24   Keller-LED-Bar.0.RSSI_PEER 87
     2016-08-02 23:47:24   Keller-LED-Bar.0.STICKY_UNREACH false
     2016-08-02 23:47:24   Keller-LED-Bar.0.UNREACH false
     2016-08-02 23:47:24   Keller-LED-Bar.0.UPDATE_PENDING false
     2016-08-02 23:51:48   Keller-LED-Bar.1.DIRECTION off
     2016-08-02 23:51:48   Keller-LED-Bar.1.ERROR_OVERHEAT off
     2016-08-02 23:51:48   Keller-LED-Bar.1.ERROR_REDUCED off
     2016-08-02 23:47:24   Keller-LED-Bar.1.INHIBIT false
     2016-08-02 23:51:48   Keller-LED-Bar.1.LEVEL 0.0
     2016-08-02 23:51:48   Keller-LED-Bar.1.LEVEL_REAL 0.0
     2016-08-02 23:51:48   Keller-LED-Bar.1.WORKING off
     2016-08-02 23:47:24   Keller-LED-Bar.2.DIRECTION off
     2016-08-02 23:47:24   Keller-LED-Bar.2.ERROR_OVERHEAT false
     2016-08-02 23:47:24   Keller-LED-Bar.2.ERROR_REDUCED false
     2016-08-02 23:47:24   Keller-LED-Bar.2.INHIBIT false
     2016-08-02 23:47:24   Keller-LED-Bar.2.LEVEL 1.0
     2016-08-02 23:51:48   Keller-LED-Bar.2.LEVEL_REAL 0.0
     2016-08-02 23:47:24   Keller-LED-Bar.2.WORKING false
     2016-08-02 23:47:24   Keller-LED-Bar.3.DIRECTION off
     2016-08-02 23:47:24   Keller-LED-Bar.3.ERROR_OVERHEAT false
     2016-08-02 23:47:24   Keller-LED-Bar.3.ERROR_REDUCED false
     2016-08-02 23:47:24   Keller-LED-Bar.3.INHIBIT false
     2016-08-02 23:47:24   Keller-LED-Bar.3.LEVEL 1.0
     2016-08-02 23:51:48   Keller-LED-Bar.3.LEVEL_REAL 0.0
     2016-08-02 23:47:24   Keller-LED-Bar.3.WORKING false
     2016-08-02 23:51:48   control         0.0
     2016-08-02 23:51:48   state           0.0
Attributes:
   IODev      myHomematicCCU
   ccuscaleval Keller-LED-Bar.1.LEVEL:0.01
   controldatapoint 1.LEVEL
   event-on-change-reading .*
   group      BeachBar
   icon       light_led_stripe
   room       04_Keller
   statechannel 1
   statedatapoint 1.LEVEL
   statevals  on:1.0,off:0.0
   stripnumber 1
   substitute 1.0:on,0.0:off,1:on,0:off
   webCmd     control
   widgetOverride control:slider,0,0.1,1,1


Code Auswählen Erweitern


define Keller_LED_Bar HMCCUDEV Keller-LED-Bar 1
attr Keller_LED_Bar IODev myHomematicCCU
attr Keller_LED_Bar ccuscaleval Keller-LED-Bar.1.LEVEL:0.01
attr Keller_LED_Bar controldatapoint 1.LEVEL
attr Keller_LED_Bar event-on-change-reading .*
attr Keller_LED_Bar group BeachBar
attr Keller_LED_Bar icon light_led_stripe
attr Keller_LED_Bar room 04_Keller
attr Keller_LED_Bar statechannel 1
attr Keller_LED_Bar statedatapoint 1.LEVEL
attr Keller_LED_Bar statevals on:1.0,off:0.0
attr Keller_LED_Bar stripnumber 1
attr Keller_LED_Bar substitute 1.0:on,0.0:off,1:on,0:off
attr Keller_LED_Bar webCmd control
attr Keller_LED_Bar widgetOverride control:slider,0,0.1,1,1


[Loredo]

es muss nur der Datenpunkt genannt werden, also nur LEVEL:0.01 statt Keller-LED-Bar.1.LEVEL:0.01


Gruß
Julian

[chris1284]

Der Kanal 0 hat hingegen immer den Namen des Geräts selbst. 

den kann man doch auch umbenennen / bzw das gerät in der ccu. ich habe nichts in der ccu mit originalem namen wwas devices angeht

Wenn ein Datenpunkt in mehreren Kanälen vorkommt, wird die Kanalnummer mit einem Punkt vorangestellt, also z.B. 0.LOWBAT

inkonsistent würde ich sagen wollen. entweder immer mit kanal vorweg oder halt keine HMCCUDEV mehr und nur noch HMCCUCHN. das wäre dann im übrigen genau so wie es CUL_HM macht, da gibts auch keine Devices somit auch nie das problem doppelter readings da ein fhem device (also ein hmccuchn) nur einmal in fhem existieren darf.
beispiel ein 4-fach aktor hat auf jeden fall doppelte readings und somit immer eine zahl davor. das mach den readingsnamen wieder unbrauchbar zu den "standards". wenn ich zb in einer readingsgroup alle state's anzeigen will würde ich das per .*:STATE machen. die 4-fach switsche würden als HMCCUDEV da völlig raus fallen, als HMCCUCHN jedoch nicht weil es pro chn nur 1 state gibt

thermostate habe ich zb nur mit HMCCUCHN eingebunden (chn4) als [raumkürzel]_hz_Clima. bei 1-fach switches nur chn1,bei sensroen nur chn1, bei 4-fach switches ch1-4

1-2 device habe ich als ccudev, davon ist aber keines genutzt, er  zum mal anschauen


vorteil nur noch HMCCUCHN
-so holt man sich nur den chn in fhem rein welchen man braucht zum schalten / für readings
-das ist ein vorteil gegenüber CUL_HM der immer alle channels will und auch anlegt, egal ob man sie gebrauchen kann oder nicht (da man peering und config in der ccu macht braucht man viele mit HMCCU halt nicht )
-du must nicht 2 module pflegen
-keine doppelten readings
-esgibt keien grund für hmccudev

nachteil
-wüsste ich keinen außer das sich das auf bestehende installationen auswirken würde wo hmccudevs definiert sind
- man würde einfach das modulnicht weiter bearbeiten und nur noch hmccuchn, wer dann nach 3 monaten noch HMCCUDEV definiert hat hat halt was verpasst

[zap]

den kann man doch auch umbenennen / bzw das gerät in der ccu. ich habe nichts in der ccu mit originalem namen wwas devices angeht

Das Gerät kann man natürlich umbenennen. Ich meinte, dass der Kanal 0 in der CCU nicht separat aufgeführt wird und nicht wie die anderen Kanäle - unabhängig vom übergeordneten Gerät - umbenannt werden kann.

inkonsistent würde ich sagen wollen. entweder immer mit kanal vorweg oder halt keine HMCCUDEV mehr und nur noch HMCCUCHN. das wäre dann im übrigen genau so wie es CUL_HM macht, da gibts auch keine Devices somit auch nie das problem doppelter readings da ein fhem device (also ein hmccuchn) nur einmal in fhem existieren darf.

Mit inkonsistent hast Du recht. Also immer mit Kanalnummer. Das macht die Umsetzung auch einfacher.

Ein Verzicht auf HMCCUDEV wäre natürlich aus Entwicklersicht eine große Vereinfachung, da es deutlich komplexer ist als HMCCUCHN. Allerdings möchte ich grundsätzlich den Kanal 0 dabei haben wegen LOWBAT und UNREACH. Es gibt einige Geräte (z.B. Tür-/Fensterkontakte), die auch im Kanal 1 LOWBAT bereitstellen. Aber leider eben nicht alle. D.h. ich müsste ein HMCCUCHN bauen, dass immer auch den Kanal 0 mitführt. Muss ich mal drüber hirnen . Ein einziges Client-Modul hat schon einen gewissen Charme, zumal es mir Arbeit erspart (Informatiker sind ja von Natur aus faul und hassen sich wiederholende Tätigkeiten bzw. neigen zum KISS Prinzip  ).

Noch was anderes: Ich habe leider keinen Dimmer. In der EQ-3 Doku habe ich gesehen, dass es bei den Dimmern virtuelle Kanäle gibt, die die gleichen Datenpunkte wie Kanal 1 enthalten. Welche Funktion haben diese virtuellen Kanäle ?

[chris1284]

ich fände die aufnahme von kanal 0 in hmccuchn, den wegfall von hmcudev und den wegfall der vorangestellten kanalnummer bei readings auch für die optiomalste lösung

wenn man quasi das device ohne angabe der kanalnummer definiert nimmt er nu chan 0

define <def> HMCCUCHN <ccudefname> legt den 0erchannel an , nat. mit readings ohne vorzeichen

define <def> HMCCUCHN <ccudefname>:<n> legt den n channel an , nat. mit readings ohne vorzeichen, gibt man 0 an legt er dannnatürlich auch nur den chn 0 an

[Loredo]

Ich empfinde es schon als Vorteil, wenn man nicht wie bei CUL_HM zwingend für jeden Kanal ein eigenes Device benötigt.
Das ist z.B. bei einem LED-Display mit 16+1 Kanälen total nervig. Außerdem noch zu bedenken: Bisher war der Favorit HMCCUDEV eben genau wegen der LOWBAT und UNREACH Infos etc. Es macht bei einer großen Installation viel Arbeit dem Hü und Hott zu folgen (sprich: die >20 mühsam einzeln erstellten Kanäle müssen wieder komplett neu umgeschrieben werden -> Horror!).


Die Trennung zwischen HMCCUDEV und HMCCUCHN aufzuheben finde ich prinzipiell gut. Vielleicht lässt sich das Define für HMCCUCHN ja so anpassen, dass man auch mehrere Kanäle mit Komma getrennt angeben kann.


Die Readings sollten nur wenn unbedingt notwendig die Kanalnummer beinhalten, damit Fhem Scripts, Attribute etc. portabler und weniger von den Kanalnummern abhängig sind.