Neues Modul HMCCU für Homematic CCU

[chris1284]

Hast Du ccudef-readingfilter im I/O Device gesetzt?

weder im dev noch im io weil ich keine readings filtern will

Abhilfe: im IO Device ccudef-readingfilter auf .* setzen!

bedeutet das es nun ein pflichtattribut ist damit überhaupt readings ankommen? dann sollte das per default auch ohne zutun des users gesetzt werdne wenn nicht schon anderst durhc den user konifguriert.
ich werds testen

[chris1284]

ccu-readingsfilter .* hilft wirklich! aber das olltest du vorraussetzen wenn das attribut nicht gestezt ist

[chris1284]

in ccudef-readingname würde ich in den defaults batterie ehr so definieren

..;^(.+\.)?LOW_?BAT$:+battery;

dann fehlt noch

..;^(.+\.)?BATTERY_STATE:+batteryLevel;

würde ich meinen
   

[cho]

Hallo zap,

zuerst einmal finde ich es cool, dass Du die Module ständig aktualisierst und erweiterst! Vielen Dank dafür!

Aber mit dem Wechsel von 3.7 auf 3.8 scheint sich jetzt ja einiges grundlegend zu ändern, was - soweit ich das verstehe - auch sinnvoll zu sein scheint. Eine gute Sache für alle, die gerade am Einrichten sind.

Aber was bedeutet das für Nutzer wie mich, die eine "fertige", funktionierende Konfiguration laufen haben?
- in ccureadingfilter und ccureadingname muss ich "," durch ";" ersetzen: ok
- statt substdefaults muss ich ccudef-substitute verwenden: kann, falls vorhanden, der alte Wert 1:1 übernommen werden oder gibt es irgendwas zu beachten?
- ccudef-readingfilter, ccudef-readingname und ccudef-readingformat sind neu hinzugekommen und können durch Vorgaben aus den Templates befüllt werden: welche Werte muss ich setzten, wenn ich nicht mit den Templates arbeiten möchte und eigentlich nur das gleiche Verhalten des Modules wie vorher benötige?

P.S. Noch läuft bei mir 3.7

Viele Grüße
Christian

[chris1284]

^(.+\.)?TEMPERATURE$:+measured-temp;

das kannst du so auch nicht in den defaults lassen das zb bei tempsensoren dann auch measured-temp steht. wenn du dich an cul_Hm orientierst müsste da temperature stehen.

dafür könntest du folgendes aufnehmen

^(.+\.)?ACTUAL_HUMIDITY:+humidity;^(.+\.)?ACTUAL_TEMPERATURE:+temperature

[zap]

Edit: ccudef-readingsfilter auf .* hilft, sollte aber Default sein.

Ja ich weiß. Ein Bug. Ich versuche, noch heute ein Update zu liefern.

@chris1284: Danke für die Hinweise zu den Defaults. Ändere ich.

@cho: Ich liefere die Einstellungen nach (damit alles so funktioniert wie vorher). Die Idee war eigentlich, dass das der Fall ist, wenn man keines der ccudef- Atribute setzt. Ist aber nicht so. Sorry.
Bei ccudef-substitute kannst Du die Einstellungen von substdefault einfach übernehmen. Da wurde sowieso schon ; als Trenner verwendet.

@loredo: evtl. hilft es, wenn ich noch ein ccudef-hmstate ergänze, mit dem man festlegen kann, welche Readings in hmstate einfließen (?)

[chris1284]

eins habe ich noch
ein

ccudef-substexcl

attribut wäre toll. somit kann ich das (weil überall wenn gesetzt gleich) auch aus den eigenen geräte defaults nehmen und in die ccudefaults packen

[ToM_ToM]

Hi zap,

habe die Änderungen vorgenommen und jetzt läufts.
Danke

VG, Thomas

[zap]

in ccudef-readingname würde ich in den defaults batterie ehr so definieren

..;^(.+\.)?LOW_?BAT$:+battery;

Wozu ist "..;" am Anfang gut?

[chris1284]

das sollte nur bedeuten das davor noch was ist  wie "...<einigedefinitionen >...;"

[zap]

Wenn Du in einem Client Device das Attribut 'ccureadingname' setzt und auch im I/O Device 'ccudef-readingname' gesetzt ist, werden beide Angaben einfach aneinander gehängt:

ccureadingname;ccudef-readingname

Da die Regeln von links nach rechts abgearbeitet werden, kann man die Angaben aus 'ccudef-readingname auch überschreiben. Ein Beispiel:

ccudef-readingname = LOWBAT:+battery
ccureadingname = LOWBAT:saft

Man beachte das fehlende '+' bei ccureadingname. Das ergibt die Regel:

LOWBAT:saft;LOWBAT:+battery

Da bereits im ersten Schritt LOWBAT durch 'saft' ersetzt wird, greift die folgende Regel nicht mehr, da LOWBAT umbenannt wurde. Ein ccureadingname = LOWBAT:+saft hingegen würde zu 3 Readings führen: LOWBAT, saft und battery

[zap]

So, die Änderungen sind eingecheckt. Dürften dann morgen verteilt werden. Die wichtigste Änderung: Default für ccudef-readingfilter ist '.*', d.h. alle Readings werden aktualisiert.

Um das Verhalten der Version 3.7 bei der Aktualisierung von Readings zu erreichen, sind im I/O Device folgende Attribute zu setzen:

ccudef-readingfilter = .* (muss nicht sein, da nun Vorgabe)
ccudef-readingformat = name

Die Attribute ccudef-substitute und ccudef-readingname sollten in diesem Fall nicht gesetzt werden.

Ggf. werde ich morgen noch 2 weitere Default-Attribute nachreichen. Muss ich aber erst noch drüber nachdenken ...

[Loredo]

Ich habe die 3.8v2 jetzt getestet und muss sagen: Die Grundlagen sind jetzt beinahe geschaffen, großes Lob! 

Dass man nach wie vor bei einem komplett neu angelegten HMCCU Gateway Device ein "set defaults" machen muss, um den sinnvollen Ausgangspunkt zu erhalten, finde ich nicht optimal, aber ich kann damit leben. Für Neulinge bedeutet das noch immer genaues lesen und verstehen statt "Hands on", was eigentlich schade ist. rpcserver=on gehört eigentlich auch noch in die Defaults rein würde ich sagen.

Chris hatte ja schon bemerkt, dass wir wohl noch etwas an vollständigen/sinnvollen Default-Werten für ccudef-readingname und ccudef-substitude feilen sollten. Das sind aber Details und hilft dann vor allem den Neuein- und Umsteigern. Da wohl keiner alle HM und HMIP Geräte auf dem Markt hat, müssen wir hier gemeinsam herausfinden, welche Datenpunkte man mit guter Sicherheit umschreiben kann (und wie). Der Temperaturbereich ist wohl einer der Bereiche und Chris hat schon beschrieben, dass das Verständnis über CUL_HM und andere FHEM-Module etwas anders ist (oder sein sollte), als die momentane Vorbelegung es nahelegt. Im Grunde ist es einfach: Die gemessene Temperatur bei reinen Sensoren heißt immer 'temperature' (z.B. Wetterstation draußen; HM Kanaltyp WEATHER.*), wenn es ein Sensor als Teil einer Klimaregelung ist heißt das Reading 'measured-temp' (z.B. Raumthermostat; HM Kanaltyp CLIMATECONTROL.*). Das lässt sich auch gut daraus ablesen, dass eq-3 diesen Unterschied ebenso macht: Bei der Wetterstation heißt der Datenpunkt TEMPERATURE, bei den Reglern ACTUAL_TEMPERATURE und es gibt bei letzterem deshalb konsequenter Weise zusätzlich SET_TEMPERATURE, was desired-temp entspricht. Das ist alles absolut logisch aufgebaut, wenn man mal genau liest

Ich habe also aktuell folgendes für ccudef-readingname:

Code Auswählen Erweitern


^(.+\.)?ACTUAL_HUMIDITY$:humidity;
^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;
^(.+\.)?AES_KEY$:sign;
^(.+\.)?BATTERY_STATE$:batteryLevel;
^(.+\.)?BRIGHTNESS$:brightness;
^(.+\.)?CONTROL_MODE$:controlMode;
^(.+\.)?DIRECTION$:direction;
^(.+\.)?ENERGY_COUNTER$:energy;
^(.+\.)?FREQUENCY$:frequency;
^(.+\.)?HUMIDITY$:humidity;
^(.+\.)?INHIBIT$:lock;
^(.+\.)?LEVEL$:+pct;
^(.+\.)?LEVEL$:level;
^(.+\.)?LOW_?BAT$:battery;
^(.+\.)?MOTION$:motion;
^(.+\.)?PARTY_START_TIME$:partyStart;
^(.+\.)?PARTY_STOP_TIME$:partyEnd;
^(.+\.)?PARTY_TEMPERATURE$:partyTemp;
^(.+\.)?POWER$:consumption;
^(.+\.)?SET_TEMPERATURE$:desired-temp;
^(.+\.)?TEMPERATURE$:temperature;
^(.+\.)?UNREACH$:Activity;
^(.+\.)?VALVE_STATE$:valve;
^(.+\.)?VOLTAGE$:voltage;
^(.+\.)?WORKING$:working;
^(.+\.)?STATE$:STATE;


Für ccudef-substitude habe ich:

Code Auswählen Erweitern


AES_KEY!(0|false):off,(1|true):on;
CONTROL_MODE!0:auto,1:manual,2:party,3:boost;
DIRECTION!0:stop,1:up,2:down,3:undefined;
INHIBIT!(0|false):unlocked,(1|true):locked;
LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;
MOTION!(0|false):noMotion,(1|true):motion;
UNREACH!(0|false):alive,(1|true):dead;
WORKING!(0|false):false,(1|true):true;


Was mir dabei nicht klar ist, auf welcher Grundlage ihr meint die umgeschriebenen Readings zusätzlich zu den Ausgangsreadings erzeugen zu müssen (also mit der '+' Notation). Mir fällt da (außer für LEVEL) kein Grund ein, warum das so sein muss, habt ihr einen? Mir ist nicht klar, weshalb man bei ccuref-readingname Regex verwenden kann und bei ccudef-substitude nicht (sieht man schön am Beispiel LOW_BAT/LOWBAT), ggf. ließe sich das angleichen.

Der Eintrag für STATE (bzw. müsste es eigentlich sogar ^\d+\.:; lauten) bei mir in ccudef-readingname ist eher dem geschuldet, dass ich es nach wie vor für die eigene Berechnung von stateHM ohne den Channel-Prefix benötige, was mich zu deiner Frage führt, @zap:

@loredo: evtl. hilft es, wenn ich noch ein ccudef-hmstate ergänze, mit dem man festlegen kann, welche Readings in hmstate einfließen (?)

So wie du hmstate aktuell gemeint hast (lt. Commandref), hilft es für die Steuerung von Geräten nicht, sondern ist nur eine bessere Zusammenfassung von Warn- und Fehlerstatus. Damit lässt sich nichts steuern. Sagen zu können welche Datenpunkte/Readings mit in die Berechnung einfließen und mit welcher Priorität wäre essentiell, ja. Zentral in ccudef-hmstate zu konfigurieren wäre auch wünschenswert. Man müsste aber auch einen anderen Statuswert angeben können statt dem, der im Reading aktuell ist. Es macht beispielsweise keinen Sinn den Wert von Activity in hmstate direkt zu übernehmen, es müsste bei Activity=dead nämlich stattdessen "unreachable" rauskommen. Die Logik lässt sich dabei prima aus meinem 99_myutils Schnipsel weiter vorne im Thread herauslesen. Die Grundlogik bei der Reihenfolge ist:


1. Zuerst echte Fehler anzeigen, die eine Bedienung des Geräte unmöglich machen. Ein entsprechender Prefix err_ o.ä. ist hier essentiell notwendig (in meinem Beispiel mit dem Kommentar versehen: eval error parameters)

2. Dann die Bediensperre, sofern INHIBIT=1|locked; Gerät lässt sich ebenfalls nicht bedienen (in meinem Beispiel mit dem Kommentar versehen: eval operational parameters)

3. Den Geräte-Arbeitsstatus, wenn es gerade aktiv ist: erst DIRECTION, wenn vorhanden und ungleich stop|0, dann WORKING wenn ungleich 0 (in meinem Beispiel mit dem Kommentar versehen: eval operational parameters)

4. Dann den Datenpunkt als Status, den das jeweilige Gerät für den Gerätestatus anbietet/verwendet; Reihenfolge MOTION, LEVEL, STATE, VALVE_STATE, ACTUAL_TEMPERATURE, CONTROL_MODE (in meinem Beispiel mit dem Kommentar versehen: eval state parameters). Für LEVEL muss berücksichtigt werden, dass Änderungen >100 laut eq3 Doku ein Spezialstatus bedeuten und der vorherige LEVEL-Wert deshalb für eine korrekte Statusanzeige erhalten bleiben muss. Außerdem braucht es die Möglichkeit die Top-Werte 100 und 0 in on bzw. off umzubenennen. Zudem ist es notwendig dies auch umdrehen zu können (100=off,0=on), weil Schalter auch (absichtlich) verkehrt herum eingebaut sein können. Das wiederum muss sich pro Gerät einzeln als Abweichung zur Norm ändern lassen.

4a. Bei vorhandenem Datenpunkt TEMPERATURE oder HUMIDITY wird die Notation für einen WEATHER Datentyp angenommen. Das bedeutet sowas wie "T: 10 °C H: 40 %". Wenn weitere Datenpunkte für WIND.*, RAIN.*, SUNSHINEDURATION, BRIGHTNESS vorhanden sind, handelt es sich um eine Wetterstation und diese Werte müssen entsprechend hinzugefügt werden. Ich wollte es an dieser Stelle bisher nicht noch komplizierter machen und habe die Unterstützung von Unit.pm für die korrekte Zuweisung von Readings-Datentypen bisher nicht berücksichtigt (gleichwohl machte es dann die makeSTATE() Funktion aus Unit.pm leichter dieses Statusfeld zu erzeugen). Die Verheiratung von Unit.pm, 98_powerMap etc. mit HMCCU ist dann nochmal ein ganz eigenes Kapitel...

5. Optional könnte an dieser Stelle jetzt tatsächlich noch LOWBAT und all die anderen Warning-Only Datenpunkte angezeigt werden, sofern das Gerät eben keinen normalen Status-Datenpunkt hat. Ein entsprechender Prefix warn_ o.ä. ist hier analog zu err_ auch nötig.

6. Default Wert 'ok' sofern keiner der Status Datenpunkte vorhanden ist und UNREACH nicht 1 ist. Wenn UNREACH nicht vorhanden ist, dann ist der Default Wert "Initialized".


Warnungen wie LOWBAT sollen für hmstate keine Rolle spielen, da sie für die Bedienung des Gerätes unerheblich sind. Dafür haben wir ja gesonderte Readings und können separat reagieren. hmstate soll sich also hauptsächlich auf die Bedienfunktion konzentrieren.

Wenn sich hmstate über hmstatevals so, wie gerade beschrieben, definieren ließe (und dann noch global als ccudef-hmstatevals), dann ließe sich das Reading sinnvoll für eine Steuerung verwenden.
Außerdem ist das Reading dann dafür geeignet den Stromverbrauch mittels powerMap in akkurater Weise zu errechnen.

[Loredo]

Nachtrag:

Ich habe jetzt nochmals versucht hmstatevals zu erraten:

Code Auswählen Erweitern


UNREACH!1:unreachable;
FAULT_REPORTING!1:err_VALVE_TIGHT;
FAULT_REPORTING!2:err_ADJUSTING_RANGE_TOO_LARGE;
FAULT_REPORTING!3:err_ADJUSTING_RANGE_TOO_SMALL;
FAULT_REPORTING!5:err_UNSPECIFIED;
FAULT_REPORTING!7:err_VALVE_ERROR_POSITION;
ERROR_OVERHEAT!1:err_overheated;
ERROR_OVERLOAD!1:err_overloaded;
ERROR_REDUCED!1:err_reduced;
ERROR!1:err_1;
ERROR!2:err_2;
ERROR!3:err_3;
INHIBIT!1:locked;
DIRECTION!1:up;
DIRECTION!2:down;
DIRECTION!3:undefined;
WORKING!1:working;
MOTION!0:noMotion;
MOTION!1:motion;
LEVEL!0:off;
LEVEL!(1-99):??;
LEVEL!100:on;
STATE!.*:??;
VALVE_STATE!.*:??;
ACTUAL_TEMPERATURE!.*:??;
CONTROL_MODE!.*:??;
TEMPERATURE!.*:+T: ??;
HUMIDITY!.*:+H: ??;
WIND_SPEED!.*:+W: ??;
RAIN_COUNTER!.*:+R: ??;
RAINING!.*:+IR: ??;
WIND_DIRECTION!.*:+WD: ??;
WIND_DIRECTION_RANGE!.*:+WDR: ??;
SUNSHINEDURATION!.*:+S: ??;
BRIGHTNESS!.*:+B: ??;
FAULT_REPORTING!6:warn_battery;
LOW_BAT,LOWBAT!1:warn_battery;
ERROR!4:warn_battery;
UNREACH!0:ok;

Wie man dabei sieht, fehlt es an der Möglichkeit das bereits per ccudef-substitude umgewandeltes Value hier 1-zu-1 durchzureichen, wenn der Datenpunkt existiert (Beispiele LEVEL, STATE, VALVE_STATE, ACTUAL_TEMPERATURE, CONTROL_MODE). Deshalb die ?? in dem Beispiel.
Außerdem fehlt es für die ganzen WEATHER Datenpunkte daran diesen einen Präfix voranzustellen und sie hintereinander zu ergänzen. Die Notation dazu habe ich jetzt einfach mal erraten.
LEVEL>100 müsste auch noch so abgefangen werden, dass sich der Status dann gar nicht ändert und der vorherige LEVEL Wert erhalten bleibt.

Disclaimer: Das obige Beispiel funktioniert (derzeit) gar nicht, also z.B. auch nichtmal für Bewegungsmelder mit dem Datenpunkt MOTION.


Gruß
Julian

[chris1284]

Was mir dabei nicht klar ist, auf welcher Grundlage ihr meint die umgeschriebenen Readings zusätzlich zu den Ausgangsreadings erzeugen zu müssen (also mit der '+' Notation).

die grundlage für die (korekten) readings sind die datenpunkte wie sie eq3 beschreibt (das ist ein definierter, dokumentierter standard bezogen auf homematic produkte).
die möchte ich schon gerne haben/sehen. die umgeschriebenen readings erzeuge ich nur um readings an gepflogenheiten in fhem anzupassen (mach einer bezeichnet diese fälschlicherweise als"standards"  ) , da dies das arbeiten mit einigen anderen modulen (wie dewpoint zb) erleichtert bzw eine einheitliche namensgebung geräteübergreifend erfmöglicht (ich könnte auch einfach die anderen readings per userreadings an die datenpunkte anpassen da diese in der minderzahl sind aber per hmccu gehts das nun deutlich einfacher). und die doppelten readings (sind ja eh nicht alle) fressen kein heu