Bezeichnungen der Readings und Werte bei HMCCU

[martinp876]

Ich habe mein Protfoilio der HMIP devices erweitert und werde mich somit der Einbindung widmen... lange nichts gemacht - bin auf die Neuerungen gespannt.
nun, das einbinden ging schon einmal gut - unter den vielen Kommandos habe ich die richtigen gefunden.

1) Motion detector
1a) illumunation. wird das nicht immer als Brightness in fhem geführt? Warum muss ich nun neue Filter einführen?
1b) Voltage. Ist das nicht batteryLevel gemäß vereinbarung?
1c) was ist illumination_status? Eine CCU kennt den Status nicht. Wann ist der Status "normal"?
1d) what teh hack is "current_illumination". ist das andere ein Mittelwert? HM kennt das alles nicht - wo muss ich Doku suchen?
1e) devState und sabotage scheinen doppelt. Notwendig?

2) Presence
2a) illumination wie motion detector
2b) voltage wie Motion Detector
2c) ok, es ist ein Presenzmelder. Wäre es nicht einfacher, hier ebenso "motion" anstatt "Presence" zu nutzen? De facto ist es doch nichts anderes, macht die notifikationen nur komplexer und umständlicher.

3) Lagesensor
3a) volatage siehe oben
3b) nun, hier wird "motion" anstelle von "Position"  verwendet. Ist zwar weniger passend als bei Presence (der erkennt tatsächlich Bewegungen) aber es macht die Auswertung einfacher. Somit auf den ersten Blick sonderbar, auf den 2. Blick eine gute Wahl.

Sorry, für meine Einwände - aber die Benennung der Readings gerade bei ständig genutzten ist doch nun schon ewig vereinbart und fast überall genutzt. Faktisch ist es mir egal, ob ein Name passender wäre als ein anderer (da können wir gerne einmal diskutieren). Ich habe mich klaglos an die Normen gehalten und würde mich freune, wenn du da auch könntest.

[martinp876]

erster Nachtrag:
bei Motion gibt es "motion_detection_active" und "motion".
bei Presence gibt es "presence_detection_active" und "presence_detection_state".
Nun bin ich unverbesserlich für kurze aber bedeutungsvolle Namen - aber keine Romane  in diesen. Mein Problem, muss man nicht unterstützen. Dennoch - eine stringente Umsetzung der Namen wäre schön. "presence_detection_state" wäre dann "presence". Und ehrlich: "_detection_state" kann man an etliche Readings anhängen. Wird mich immer gruseln, wenn ich es sehe.

Wichtiger aber: Ich habe nun

Code Auswählen Erweitern

eventMap noPresence:noMotion presence:motion
eingebaut um es manuell zu vereinheitlichen. Das lustige ist, dass ich dann "motion" sehe, nach refresh aber nicht mehr - dann habe ich wieder "presence".
Ich will nun nicht  debuggen müssen - offensichtlich hält sich das Modul auch hier nicht an die Konventionen und ändert Readings unter Umgehung der Kernel Funktionen. Dabei werden dann die üblichen Funktionen wie eventMap ausser Kraft gesetzt. Das Logging spiegelt das  nicht wieder. Auch STATE wird nicht aktualisiert.

==> habe ich eine alte Version? Ich mache einmal einen update.... dann wäre es mein Fehler...

[Beta-User]

eventMap war und ist schon immer überall "Kosmetik".

[martinp876]

nun bin ich bei den Betrachtungen schon wieder einen Schritt weiter - inhaltlich leider nicht.
Reading 'motion' mit ReadingVal (motion|noMotion) ist ... zumindest schwierig. Das ist doch ein bool. Also sollte es on|off sein. manchmal yes|no (passt meist schlechter) und wenn es sein muss 0|1.
=> motion=motion ist doppelt
=> parsen ist schwieriger - viel einfacher wenn man die üblichen Konventionen nutzt. on|off ist nun schon weit verbreitet
=> bei einer solchen sonderLocke streikt eventMap komplett. ich wollten nun 'motion' loggen. Da beim Beschleunigungssensor aber "motion" sowieso nicht zutrifft mappe ich es also auf "open" bzw "closed". EventMap macht daraus nun open:motion und motion:closed.

#> was eventMap macht kann man hinterfragen. Das Replace ist wieder einmal "allgemeingültig" - ich würden sagen "leider nicht stringent definiert/implementiert". Wäre schön, wenn man etwas expliziter sein könnte und das ersetzen von kommandos/readingName/readingValue/... angeben könnte. So allerdings bekommt man immer wieder eine Überraschung  - hat ja auch etwas.

Ist es möglich, die Konventionen einzuhalten? Dann wäre das garnicht notwendig. Wenn das in absehbarer Zeit nicht korrigiert werden kann muss ich einen workaround einbauen - so kann ich die Funktion schlicht nicht realisieren.

[martinp876]

so, ich muss wohl zurück rudern und mich entschuldigen. eventMap verändert (bei Readings) nur das Event, nicht aber das Reading.
Das ist so nicht explizit beschrieben. Nun ja, wer es dennoch nutzen will muss bei events eben hinnehmen, dass Readings und Events nicht mehr matchen. FHEM Web macht dann "merkwürdige Dinge" - nachvollziehbar, aber für mich am Ende nicht tragbar. Damit ist (für mich) eventMap noch zum Umbenennen von Kommandos (also commandMap) nutzbar, nicht aber für Readings. Zu viel durcheinander...

Meine Anmerkungen zu den Readings-Namen bleiben bestehen.

[martinp876]

ok, mit ccureadingname kann man selbst manuell die FHEM Regeln bei den Name einhalten.
-> hier ist zur Eingabe ein EditierFenster vorgesehen - sehr gut
Allerdings kann man keinen Zeilenumbruch nutzen. Das wäre (für mich) schon hilfreich - damit kann man die Darstellung deutlich einfacher lesbar machen.
ccureadingname voltage:batteryLevel;illumination_status:brightState;illumination:brightness;presence_detection_active:motionMode;presence_detection_state:motion

und dann doch noch... bei event-on-change-reading .* sollten

Code Auswählen Erweitern

2022-12-30 09:06:33 mfHall motion noPresence
2022-12-30 09:07:26 mfHall motion noPresence
2022-12-30 09:07:31 mfHall motion presence
2022-12-30 09:07:48 mfHall motion noPresence
2022-12-30 09:08:06 mfHall motion noPresence
2022-12-30 09:08:11 mfHall motion presence
2022-12-30 09:08:29 mfHall motion noPresence
2022-12-30 09:11:47 mfHall motion noPresence
2022-12-30 09:17:07 mfHall motion noPresence
2022-12-30 09:17:14 mfHall motion presence
nicht vorkommen. mehrfach hintereinander npPresence ist wohl nur möglich, wenn das Reading zwischendurch manuell (ohne funktions aufruf) geändert oder gelöscht wird. Sonst kann ich es mir nicht erklären.

[Beta-User]

War mich auch so in Erinnerung, dass man bei HMCCU.* praktisch alles per Attribut selbst regeln kann. Damit wären wir wieder bei der Frage, ob AttrTemplate zur "üblichen" Standardisierung beitragen kann (wo nicht aus dem Modul sowieso schon selbst "sinnvolle" Vorgaben kommen). Falls (!) SetExtensions eingebunden sind, sollte das ohne weiteres gehen, man müßte nur anfangen, eine attrTemplate-File zu bauen...

(Etwas) Doku dazu ist im Wiki zu finden, vermutlich ist es dann aber einfacher, mal eine "kleine" attrTemplate-File nach (einfacheren) Beispielen zu durchforsten, z.B. max.template oder huedevice.template.