Neues Modul HMCCU für Homematic CCU

[Loredo]

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 ?

Soweit ich weiß liegt das daran, dass neuere Geräte noch einen Kanal pro Taster(richtung) bereitstellen. Es gibt ein internes Peering zwischen dem 1. Kanal und dem 2.+3., damit bei betätigen der Taste für Kanal 2/3 dann der Kanal 1 geschaltet wird. Dieses Peering kann man wohl auch aufheben und den Taster damit anders konfigurieren oder komplett anders verwenden. Zumindest habe ich das bei CUL_HM so verstanden. Ob sich das auch mit der CCU so nutzen/verwenden lässt, habe ich nicht ausprobiert.

[Achiim]

immer noch 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.

und

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

Ich habe jetzt alles mögliche probiert und werde nicht schlauer....

mein aktuelles define sieht so aus: 1.LEVEL:0.01, da das Reading LEVEL in allen Kanälen des HM-Dimmers vorkommt. Ich möchte lediglich den LEVEL des Kanals 1 "skalieren". Leider scheint das keine Wirkung zu haben.

Ein set datapoint 1.LEVEL 30 bewirkt z.B. dass 1.LEVEL auf den Wert 1.0 gesetzt wird. Wo ist mein Denkfehler....

[Loredo]

immer noch ccuscaleval

und

Ich habe jetzt alles mögliche probiert und werde nicht schlauer....

mein aktuelles define sieht so aus: 1.LEVEL:0.01, da das Reading LEVEL in allen Kanälen des HM-Dimmers vorkommt. Ich möchte lediglich den LEVEL des Kanals 1 "skalieren". Leider scheint das keine Wirkung zu haben.

Ein set datapoint 1.LEVEL 30 bewirkt z.B. dass 1.LEVEL auf den Wert 1.0 gesetzt wird. Wo ist mein Denkfehler....

Es muss, wie schon mehrfach gesagt, nur der Datenpunkt ohne Kanal angegeben werden. Eine unterschiedliche Skalierung des gleichen Datenpunktes bei unterschiedlichen Kanälen ist wohl nicht vorgesehen, macht aber IMHO auch keinen Sinn, da es sich um das gleiche Datenformat handelt. Wenn du diese Unterscheidung möchtest, musst du wohl mehrere HMCCUCHN Devices anlegen anstatt ein einzelnes HMCCUDEV.

[zap]

mein aktuelles define sieht so aus: 1.LEVEL:0.01, da das Reading LEVEL in allen Kanälen des HM-Dimmers vorkommt. Ich möchte lediglich den LEVEL des Kanals 1 "skalieren". Leider scheint das keine Wirkung zu haben.

Ein set datapoint 1.LEVEL 30 bewirkt z.B. dass 1.LEVEL auf den Wert 1.0 gesetzt wird. Wo ist mein Denkfehler....

Da mit Deiner Definition die Skalierung nicht greift, wird der Wert 30 an den Datenpunkt durchgereicht. Das veranlasst die CCU, den Datenpunkt auf den Maximalwert 1 zu setzen.

Eine Skalierung auf einzelne Kanäle bei mehrfach vorhandenen Datenpunkten ist nicht möglich (macht m.E. auch nicht wirklich sinn, da gleich benannte Datenpunkte normalerweise auch die gleiche Funktion haben). Was funktionieren sollte:

Code Auswählen Erweitern


attr devname ccuscaleval LEVEL:0.01  # Damit werden alle LEVELS aller Kanäle des Dimmers skaliert
set devname datapoint 1.LEVEL 30


Also im Prinzip einfach die Kanalangabe beim Attribut ccuscaleval weg lassen.

Wenn sich das Ganze nur auf den Kanal 1 beziehen soll, nimm HMCCUCHN statt HMCCUDEV. Dann beim set Befehl den Kanal weglassen.

BTW: Da ich keinen Dimmer habe, habe ich die Skalierung nur beim Get getestet. Sollte aber tun.

[Loredo]

@zap: Protipp - vorher Antworten checken, spart Arbeit 

[zap]

@zap: Protipp - vorher Antworten checken, spart Arbeit 

Jepp, die Finger waren schneller als das Auge (oder so ähnlich)

[Achiim]

Sorry für meine Begriffsstutzigkeit. Nun funktioniert's. Danke.

Anbei meine Defines für die Nachwelt:

Code Auswählen Erweitern


define Lagerfeuer HMCCUDEV Keller-Bar 1
attr Lagerfeuer IODev myHomematicCCU
attr Lagerfeuer ccuscaleval LEVEL:0.01
attr Lagerfeuer controldatapoint 1.LEVEL
attr Lagerfeuer group BeachBar
attr Lagerfeuer icon light_led_stripe
attr Lagerfeuer room 04_Keller
attr Lagerfeuer statechannel 1
attr Lagerfeuer statedatapoint 1.LEVEL
attr Lagerfeuer statevals on:100,off:0
attr Lagerfeuer stripnumber 1
attr Lagerfeuer substitute 100.0:on,0.0:off,100:on,0:off
attr Lagerfeuer webCmd control
attr Lagerfeuer widgetOverride control:slider,0,1,100,100


Und das Define für tabletUI:

Code Auswählen Erweitern


<div data-type="dimmer" data-device="Lagerfeuer" data-set="control" data-min="0" data-max="100" data-off="0" data-on="100" class="cell"></div>
<div data-type="label" class="cell">Lagerfeuer</div>


Danke für Eure Unterstützung.

[Loredo]

Es wäre übrigens sehr wünschenswert, wenn Geräte nach einem Fhem Neustart nicht den State "Initialized" bekämen, sondern die Readings einfach nicht angefasst würden bis die Daten von der CCU geladen und dann aktualisiert werden. Ein "Initialized" ist ok für frisch definierte Geräte, bei denen man noch kein Update gemacht oder ein Event bekommen hat. Ansonsten sollte die Aktualisierung der Readings ausschließlich Event getrieben sein.

[chris1284]

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!).

musst du eh... wenn die readings umbenannt werden musst du ja zwangsläufig auch viele attribute an den devices anpassen. da kann man auch gleich auf HMCCUCHN wechseln
ich denke mal es wäre dann auch nur EIN finales Hott statt hüs und hotts

[Loredo]

Noch ein weiterer Hinweis:
Ein Reading mit dem Namen "STATE" (groß geschrieben) macht wohl bei HMCCUCHN ein paar Probleme, wenn "attr ccureadingformat datapoint" gesetzt ist (so wie der ja nun wohl angedachte spätere Standard). So wird bei einer Definition eines HM-Sec-SC z.B. das Reading "state" (klein geschrieben) nicht aktualisiert und somit muss noch ein "attr stateFormat STATE" hinzugefügt werden, damit das Internal STATE dann korrekt den Wert des Reading STATE (statt dem Fhem Default "state")  enthält. Dabei hilft es auch nicht, "attr statedatapoint STATE" zu setzen.

Diese Überschneidung zwischen Fhem und der CCU bedarf also wohl noch einer Sonderbehandlung.

Das Reading "STATE", welches aus der CCU übernommen wird, sollte also für den definierten Kanal einfach in "state" umbenannt werden. Wenn mehrere Kanäle definiert sein sollten und HMCCUCHN das dann unterstützt, müssen die Readings ja dann eh unterschieden werden. Da gibt es dann keinen Konflikt und statedatapoint kann ganz normal greifen.


Edit:
Außerdem führt das auch dazu, dass nach einem Neustart der Initialized-Wert nicht überschrieben wird, wenn man nur event-on-change-reading gesetzt hat und nicht zusätzlich noch even-on-update-reading für .*STATE.* definiert hat. Das spricht auch dafür den Initialized Status nach dem Neustart nochmals zu überdenken, schließlich will man event-on-update-reading nur in Ausnahmefällen und nicht immer setzen müssen.

[zap]

Ich dachte eigentlich, dass ich den STATE Bug (keine Aktualisierung) mit der V3.3 behoben hatte. Da muss ich nochmal drüber schauen.

In der 3.4, die ich gerade in der Mache habe, gibt es ein Attribut ccuackstate. Wenn das auf 0 gesetzt wird, lässt HMCCU die Finger vom Internal STATE und dem Reading state, d.h. kein "initialized" oder "ok". Lediglich im Fehlerfall wird ein "error" gesetzt.

Um es dem Anwender einfach zu machen, ist der Default = 0, d.h. die States werden nicht mehr mit (positiven) Statusmeldungen überschrieben.

[Loredo]

Das "OK" finde ich durchaus als Quittungsmeldung sinnvoll (Error ebenso). Allerdings habe ich auch schon beobachtet, dass das OK stehen bleibt, wenn man z.B. einen Dimmer oder Rollladen Befehl schickt und das Gerät bereits im angefragten Status ist (also z.B. schon komplett geöffnet ist). Die CCU schickt wohl nur bei einer Änderung eine Antwort, wohl aber nicht auf den Befehl ansich... von daher macht das für einige Geräte Sinn es komplett abzuschalten.

[Nic0205]

Hallo,

ich habe mal ein ganze blöde Anwenderfrage:

Ich würde gerne von meinem Jalousieaktor die Werte vertauschen, damit ich sie in Smartvisu visualisieren kann.

Aktuell steht level bei 1 wenn die Jalousie oben ist und bei 0 wenn die Jalousie unten ist. Smartvisu, bzw. icon.shutter erwartet es aber genau andersrum.

Kann ich das irgendwie einfach mit HMCCU ändern?

Grüße
Dominic

[zap]

Das "OK" finde ich durchaus als Quittungsmeldung sinnvoll (Error ebenso). Allerdings habe ich auch schon beobachtet, dass das OK stehen bleibt, wenn man z.B. einen Dimmer oder Rollladen Befehl schickt und das Gerät bereits im angefragten Status ist (also z.B. schon komplett geöffnet ist). Die CCU schickt wohl nur bei einer Änderung eine Antwort, wohl aber nicht auf den Befehl ansich... von daher macht das für einige Geräte Sinn es komplett abzuschalten.

ok, die fehlende Aktualisierung von STATE / state kann ich bestätigen. Werde ich beheben.

Wenn die CCU nicht zeitnah nach einem Set einen Event schickt und damit die Werte aktualisiert werden, hilft es ggf., das Attribut "ccuverify" auf 1 zu setzen. Das funktioniert nur, wenn der Datenpunkt auch lesbar ist.

Mit ccuverify = 2 wird der Wert direkt nach dem setzten einfach in das Reading geschrieben (d.h. ohne Rückfrage bei der CCU). Das Risiko dabei ist, dass ein falscher Status im Reading landet, wenn das Set fehlschlägt.

[zap]

Hallo,

ich habe mal ein ganze blöde Anwenderfrage:

Ich würde gerne von meinem Jalousieaktor die Werte vertauschen, damit ich sie in Smartvisu visualisieren kann.

Aktuell steht level bei 1 wenn die Jalousie oben ist und bei 0 wenn die Jalousie unten ist. Smartvisu, bzw. icon.shutter erwartet es aber genau andersrum.

Kann ich das irgendwie einfach mit HMCCU ändern?

Nur bei der Statusmeldung oder auch beim Setzen?

Wenn es nur um die Statusmeldung geht, per Attribut substitue (dann nur für die Endpositionen), also

attr devname substitute LEVEL!1.0:0.0,0.0:1.0

Müsste funktionieren. Um das 100% zu unterstützen (get und set), müsste es neben dem Attribut ccuscaleval noch sowas wie ein ccureverseval geben. Kann ich mal drüber nachdenken ...

P.S. Die Liste der Wünsche wird länger. Freut mich, da es mir zeigt, dass das Modul genutzt wird. Ich hoffe aber Ihr habt Verständnis, dass ich das nur nach und nach realisieren kann. Habe nebenher noch einen zwar interessanten, aber stressigen Job und jede Menge Hobbies