Gelöst: Statusanzeige mit HM-OU-LED16 für ein structure aus Fensterkontakten

Begonnen von hdderror, 30 Juni 2019, 18:37:15

Vorheriges Thema - Nächstes Thema

hdderror

Hallo Leute!
Ich komme hier grad nicht mit einer Statusüberwachung von 2 Fenstern welche über structure zusammengefasst sind klar.
Eigentlich möchte ich was ganz simples realisieren:
Auf einem HM-OU-LED16 soll grün angezeigt werden wenn alle Fenster zu sind, orange wenn mindestens ein Fenster geöffnet ist und rot wenn alle offen sind.

Folgendes structure habe ich angelegt:

define UG_Fenster structure UG_Fenster F_UG_Keller_LI F_UG_Keller_RE
attr UG_Fenster clientstate_behavior relative
attr UG_Fenster stateFormat {substr(ReadingsVal('F_UG_Keller_LI','state',''),0,1).substr(ReadingsVal('F_UG_Keller_RE','state',''),0,1)}

Letzteres mit Dank von dt2510 von https://forum.fhem.de/index.php/topic,99129.msg924957.html#msg924957 übernommen.

Das funktioniert so dass mir je nach Fensterstellung cc,co,oc oder oo als STATE in UG_Fenster angezeigt wird.
Nun möchte ich ja den Status am Display ausgeben.

Dazu habe ich 4 notifys erstellt:

define statusanzeige_Led_03_oo notify UG_Fenster:oo set Statusdisplay_Led_03 led red
define statusanzeige_Led_03_cc notify UG_Fenster:cc set Statusdisplay_Led_03 led green
define statusanzeige_Led_03_oc notify UG_Fenster:oc set Statusdisplay_Led_03 led orange
define statusanzeige_Led_03_co notify UG_Fenster:co set Statusdisplay_Led_03 led orange

Nun hätte ich erwartet, dass je nach Zustand des STATE von UG_Fenster die Led des Statusdisplays die entsprechende Farbe anzeigt.
Stattdessen passiert aber einfach gar nichts.
So als ob der STATE Wert einfach ignoriert wird.

Einer eine Idee was hier falsch läuft?

LG
Nachtrag: Lösung am Ende.

amenomade

Ein notify reagiert nicht auf die Änderung von STATE, sondern auf ein Ereignis. Was kommt im Eventmonitor, wenn der Status sich ändert?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

hdderror

hallo amenomade,

da kommt dann "structure UG_Fenster undefined"
Da bin ich dann wieder bei meinem Problem, dass hier die structure selber nicht wie erwartet reagiert.
Ich hatte zunächst erst einmal das structure ohne den stateFormat erstellt.
Das Problem war aber, dass der State sich nicht dem Zustand der Devices angepasst hatte.
Also beide Devices der structure waren auf State closed oder beide auf open, aber der Status der structure blieb "undefined".
Ich habe dann mit clientstate_priority mit Angabe der drei möglichen Stati closed, open und undefined sowie mit clientstate_behavior auf relativeKnown herumprobiert.
Hat aber leider alles nix gebracht.
Daher hatte ich das dann mit dem stateFormat gemacht - die Anzeige stimmte dann mit den Devices überein.
LG

amenomade

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

hdderror

#4
Sorry grad erst was gegessen ...

Hier das List:

Internals:
   ATTR       UG_Fenster
   CHANGEDCNT 1386
   DEF        UG_Fenster F_UG_Keller_LI F_UG_Keller_RE
   FUUID      5d18d0af-f33f-8647-7f78-badf82336c17b794
   NAME       UG_Fenster
   NR         245
   NTFY_ORDER 50-UG_Fenster
   STATE      cc
   TYPE       structure
   READINGS:
     2019-06-30 21:47:01   LastDevice      F_UG_Keller_LI
     2019-06-30 21:47:01   LastDevice_Abs  F_UG_Keller_LI
     2019-06-30 21:47:01   state           undefined
Attributes:
   clientstate_behavior relative
   stateFormat {substr(ReadingsVal('F_UG_Keller_LI','state',''),0,1).substr(ReadingsVal('F_UG_Keller_RE','state',''),0,1)}



Probably associated with
F_UG_Keller_LI                   closed    MAX
F_UG_Keller_RE                   closed    MAX
statusanzeige_Led_03_cc   active    notify
statusanzeige_Led_03_co   active    notify
statusanzeige_Led_03_oc   active    notify
statusanzeige_Led_03_oo   active    notify


amenomade

Mit clientstate_behavior relative musst Du noch clientstate_priority definieren.

Ich weiss nicht, ob Du die structure noch für andere Bedarfe brauchst, aber nur für das Led-Display würde ich clientstate_beahvior auf absolute setzten. Somit kriegst Du ein Event "opened" oder "open" wenn alle Mitglieder auf "opened" stehen, und ein Event "closed" oder "close" wenn alle Mitglieder auf "closed" stehen, sonst ein Event "undefined".

Dann kannst Du deine notifies abhängig von open/close/undefined  auf grün/rot/orange die LED setzen lassen
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

hdderror

#6
ich hatte noch
attr UG_Fenster clientstate_priority closed open undefined
(Grad auch wieder erstellt)
drin, hatte aber nichts geändert.

Ja, und die Led's folgen dem status entsprechend dem notify.
Nur leider bleibt er dann meist bei undefined - obwohl entweder beide Fenster auf oder zu sind.
Das wechselt einfach (fast) nie von undefined wieder auf open oder closed obwohl der Status der Devices entsprechend ist.

Sicherheitshalber mal alles gelöscht und neu angelegt:


Internals:
   ATTR       UG_Fenster
   CHANGEDCNT 34
   DEF        UG_Fenster F_UG_Keller_LI F_UG_Keller_RE
   FUUID      5d18d0af-f33f-8647-7f78-badf82336c17b794
   NAME       UG_Fenster
   NR         245
   NTFY_ORDER 50-UG_Fenster
   STATE      undefined
   TYPE       structure
   READINGS:
     2019-06-30 22:21:46   LastDevice      F_UG_Keller_LI
     2019-06-30 22:21:46   LastDevice_Abs  F_UG_Keller_LI
     2019-06-30 22:21:46   state           undefined
Attributes:
   clientstate_behavior relative
   clientstate_priority closed open undefined


notifys wie folgt:
define statusanzeige_Led_03_open notify UG_Fenster:open set Statusdisplay_Led_03 led red
define statusanzeige_Led_03_closed notify UG_Fenster:closed set Statusdisplay_Led_03 led green
define statusanzeige_Led_03_undefined notify UG_Fenster:undefined set Statusdisplay_Led_03 led orange

Leider selbes Problem...


amenomade

#7
Mit so einer priority, sollte der Status auf closed gehen, sobald ein Device auf "closed" steht. Damit kannst Du aber nicht entscheiden, ob grün oder orange. Was haben die Mitglieder für mögliche Stati? "opened" oder "open"? "closed" oder "close"? Gibt es bei MAX Geräte wie bei Homematic Zwischenstati, wie z.B. "set_open" oder "set_close"?

Hast Du etwas besonderes in jedem Device wegen der Struktur auch definiert? (attr UG_Fenster_map)

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

hdderror

Das sind MAX Fensterkontakte.
Die haben open und closed.
Es gibt aber in den Devices ein eventMap open.*:open closed.*:closed
Die Kontakte liegen am Rand der Funkleistung und liefern manchmal den Status mit (rf error).
Mit dem eventMap wird das ggf. vorkommende (rf error) weggefiltert.

Zitat
Hast Du etwas besonderes in jedem Device wegen der Struktur auch definiert? (attr UG_Fenster_map)
Nein habe ich nicht.

amenomade

#9
Du musst im Eventmonitor genauer schauen, was für Events kommt, wenn Du mit den Fenster spielst. Events auf jedem Device und Events auf der Struktur.

EDIT: den Eventmonitor kannst Du mit
(UG_Fenster|F_UG_Keller_LI|F_UG_Keller_RE).*zB filtern
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

hdderror

Ich glaube zu ahnen was das Problem ist....
Mein grundsätzlicher Fehler ist auf den state zu sehen - wie du oben aber sagtest schaut das structure auf die readings.
Und hier habe ich 4 Möglichkeiten:
opened, opend (rf error), closed und closed (rf error).

ich habe jetzt die clientstate_priority auf closed opened undefined opened.(rf.error) closed.(rf.error) geändert
(ich hoffe das funktioniert an der Stelle mit den Punkten statt der Leerzeichen).
Aber wie bekomme ich es hin, dass wenn ein Fensterkontakt opened und der andere opened (rf error) liefert dann der status auf opened geht?

amenomade

Mit deiner neue clientstate_priority hat closed Vorrang auf close.(rf.error), somit sollte die structure auf closed gehen.

Aber wie gesagt, schau im Eventmonitor, mit einem Filter, der die 3 Geräte mitloggt.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

hdderror

Das mit der clientstate_priority  ist aber eigentlich nicht dass was ich erreichen möchte.
Ich möchte ja:
rot = alle Fenster offen
grün = kein Fenster offen
orange = ein Fenster offen

Da soll ja eigentlich kein Zustand priorisiert werden.
Dann sollte ich wohl eher auf clientstate_behavior absolute stellen.
Aber wegen des einen Device mit (rf error) bekomme ich ein undefined.
Kann ich definieren, das z.B. closed (rf error) und closed als das Gleiche angesehen wird?

amenomade

#13
ZitatDann sollte ich wohl eher auf clientstate_behavior absolute stellen.
Ja, das habe ich schon am Anfang gesagt...

ZitatKann ich definieren, das z.B. closed (rf error) und closed als das Gleiche angesehen wird?
Ja, im attr UG_Fenster_map in jeweiligen Devices

Zitat von: CommandRef<struct_type>_map
Mit diesem Attribut, das dem Struktur-Mitglied zugewiesen werden muss, koennen die Werte, die die einzelnen Struktur- Mitglieder melden, umdefiniert werden, damit man unterschiedliche Geraeteklassen zusammenfassen kann. Es existieren drei Varianten:

    readingName
    nehme den Wert von readingName anstatt von state
    oldVal:newVal
    falls der Wert der state Reading oldVal (als regex) ist, dann ersetze diesen mit newVal.
    readingName:oldVal:newVal
    falls der Wert der readingName oldVal (als regex) ist, dann ersetze diesen mit newVal.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

hdderror

#14
In den Fenster- Kontakt Devices
UG_Fenster_map close.*:closed open.*:opened
hinzugefügt.

Das DEF vom notity angepasst:
UG_Fenster:open.* set Statusdisplay_Led_03 led red
so das dies auf opend oder opend (rf error) reagiert
Für closed natürlich analog
UG_Fenster:close.* set Statusdisplay_Led_03 led green

;D Und siehe da es geht!

Damit andere das besser Nachbauen können hier nochmal die kompletten Lists die zusammen Funktionieren:

structure Device:

define UG_Fenster structure UG_Fenster F_UG_Keller_LI F_UG_Keller_RE
attr UG_Fenster clientstate_behavior absolute


Fensterkontakte UG_Fenster_map hinzufügen :

attr F_UG_Keller_LI UG_Fenster_map close.*:closed open.*:opened
attr F_UG_Keller_RE UG_Fenster_map close.*:closed open.*:opened


und diese 3 notifys:
(korrigierte Version - siehe nachfolgenden Kommentare)

define statusanzeige_Led_03_open notify UG_Fenster:open.* set Statusdisplay_Led_03 led red
define statusanzeige_Led_03_close notify UG_Fenster:closed.* set Statusdisplay_Led_03 led green
define statusanzeige_Led_03_undefined notify UG_Fenster:undefined set Statusdisplay_Led_03 led orange


Vielen lieben Dank für deine Geduld amenomade!