HM-Sec-RHS: Events kommen doppelt

[roedert]

Ich habe gerade die HM-Komponenten für die Heizungssteuerung installiert - klappt soweit auch prima.

HM-CC-RT-DN als Stellantrieb
HM-TC-IT-WM-W-EU als Wandthermostat - *_Climate und *_Weather mit dem Stellantrieb gepeert
HM-Sec-RHS als Fensterkontakt - gepeert mit _WindowRec vom Wandthermostat

Beim Betätigen des Fensters erhalte ich die Events allerdings doppelt - dementsprechend lösen auch notifys doppelt aus:

Code Auswählen Erweitern

2014-10-09 19:18:36 CUL_HM Arbeitszimmer.Fenster.R battery: ok
2014-10-09 19:18:36 CUL_HM Arbeitszimmer.Fenster.R closed
2014-10-09 19:18:36 CUL_HM Arbeitszimmer.Fenster.R contact: closed (to Arbeitszimmer.Thermostat)
2014-10-09 19:18:37 CUL_HM Arbeitszimmer.Thermostat_WindowRec trig_Arbeitszimmer.Fenster.R: closed
2014-10-09 19:18:37 CUL_HM Arbeitszimmer.Thermostat_WindowRec trigLast: Arbeitszimmer.Fenster.R :closed
....
2014-10-09 19:18:37 CUL_HM Arbeitszimmer.Fenster.R trigDst_23A5BB: noConfig
2014-10-09 19:18:37 CUL_HM Arbeitszimmer.Fenster.R battery: ok
2014-10-09 19:18:37 CUL_HM Arbeitszimmer.Fenster.R closed
2014-10-09 19:18:37 CUL_HM Arbeitszimmer.Fenster.R contact: closed (to HMLAN)

Hat da wer ne Erklärung für und evtl eine Lösung das umgehen? Momentan löst das notify hinter dem "closed" 2mal nacheinander aus ... ist zwar nicht weiter schlimm, aber unnütz und unschön.

[justme1968]

du solltest zum einen event-on-change-reading setzen so das du nur events bei tatsächlichen änderungen bekommst und zum anderen die regex im notify genau genug machen das sie nur auf das contact reading und nicht auch noch auf state reagiert.

gruss
  andre

[roedert]

die regex im notify genau genug machen das sie nur auf das contact reading und nicht auch noch auf state reagiert.

regex ist genau genug - es reagiert nur auf state (open|closed|tilted)
Aber wie du im Eventmonitor siehst, kommen die Events ja doppelt - state, contact und battery.

Ok, mit dem on-change-reading könnte man das in den Griff bekommen - aber mich interessierte der Grund.
Wenn ich mir contact ansehe, scheint der Fensterkontakt seine Daten ja tatsächlich doppelt zu senden - einmal an das gepeerte Wandthermostat contact: closed (to Arbeitszimmer.Thermostat) und einmal an FHEM selbst  contact: closed (to HMLAN) 

Soll/muss das wirklich so?

[frank]

Wenn ich mir contact ansehe, scheint der Fensterkontakt seine Daten ja tatsächlich doppelt zu senden - einmal an das gepeerte Wandthermostat contact: closed (to Arbeitszimmer.Thermostat) und einmal an FHEM selbst  contact: closed (to HMLAN)

gut erkannt. einmal an die zentrale und einmal an den peer. würdest du weitere peers anlegen kommen entsprechend mehr messages.

also deine regex zb auf "closed (to HMLAN)" matchen lassen.

gruss frank

[martinp876]

also deine regex zb auf "closed (to HMLAN)" matchen lassen.

kann man - aber warum?
ist es nicht besser attr <entity> event-on-change-reading .* zu setzen? Das macht deutlich mehr Sinn - auch für für Performance

Ich empfehle

Code Auswählen Erweitern

attr TYPE=CUL_HM event-on-change-reading .*

dann ist alles "gut". Setze ich im "fhemUser.cfg", das ich post-init aufrufe.

[roedert]

....oder um weiterhin regelmäßige Einträge für die Plots zu haben

Code Auswählen Erweitern

attr <device> event-min-interval .*:3

[martinp876]

....oder um weiterhin regelmäßige Einträge für die Plots zu haben

kommt drauf an, wie man es verarbeitet.
wenn 10 man hintereinander 20.5C kommt und dann 20C - alles im 2,5min raster - dann könnte man es mit "step" darstellen. Das ist letztlich genau das gemessene, die Grafik in FHEM macht das absolut korrekt.
Für Stellwerte ist das ebenso mehr als hinreichend - sie sind quasi immer Sprünge.
Auch hier reicht - zumindest in allen meinen Darstellungen - events nur bei Change aufzuzeichnen.

min-interval brauche ich nie - wäre mir klar zu unpräzise. klappt meistens, könnte aber auch doppelte Events durchlassen oder neue Events wegfiltern. Event-on-change-reading ist da einfach eindeutig.
Timer zum Filtern sind fast immer ein Notbehelf, wenn man die Ursache nicht wirklich lösen kann oder will. Hier kann man.

[roedert]

kommt drauf an, wie man es verarbeitet.
wenn 10 man hintereinander 20.5C kommt und dann 20C - alles im 2,5min raster - dann könnte man es mit "step" darstellen.

Richtig, Problem ist nur, dass der Plot auch bei Steps beim letzten Messwert aufhört ... und der kann ja bereits schon Stunden zurück sein.
Deshalb habe ich bisher entweder permanent geloggt, oder sogar periodisch den letzten Wert immer wieder in die DB geschrieben.

Ein Thread mit einer Funktion "addlog" um einen "Plotabriss" zu vermeiden gabs hier schon.....

Oder hast du dazu einen besseren Lösungsansatz?

[justme1968]

min-interval und on-change kann man zusammen verwenden. d.h. du bekommst einen log eintrag für jede änderung und zusätzlich wenn ein event kommt und sich im intervall nichts geändert hat.

das funktioniert aber nur für sensoren die regelmäßig senden.

für alle anderen ist addLog zur zeit die einzige möglichkeit.

sobald ich den logProxy fertig habe braucht man beides nicht mehr um kontinuierliche plots zu bekommen.

gruss
  andre

[roedert]

sobald ich den logProxy fertig habe braucht man beides nicht mehr um kontinuierliche plots zu bekommen.

Uiii, klingt Interessant 

Gibts da schon nähere Infos was du da vorhast?

[Puschel74]

Hallo,

Gibts da schon nähere Infos was du da vorhast?

Jep.
Nach Eingabe von logproxy in das Suchfeld  bekomme ich ua folgenden Beitrag:
http://forum.fhem.de/index.php/topic,26108.msg191260.html#msg191260

Grüße

[justme1968]

und es gibt sogar einen wiki artikel

[Puschel74]

Hallo,

und es gibt sogar einen wiki artikel

Sag bloss es genügt auf der Wikiseite im Suchfeld die Eingabe von logproxy um an den Artikel zu kommen 

Grüße

Edith: Grad versucht - tatsächlich. Es klappt 

[martinp876]

ich habe so ein Problem aktuell nicht. Liegt evtl am Aufbau.
Zum ersten versuche ich das Logfile, aus dem ich Graphen erzeuge minimal zu halten. i.a. habe ich für Graphen Device, die auch temperatur messen und sich regelmäßig melden(sollten). Ich stelle also sicher, das alles was ich darstellen will in einer Zeile/Reading steht, bei mir im status. Nur diese Zeile kommt ins "graphen-log".
das spart zum einen Platz, zum anderen wird ein kleines File schneller durchgearbeitet, bei der Darstellung.

Nun ist in jeder Zeile immer eine gemessene temperatur liegt. Diese schwankt bei mir eigentlich immer um ein Zehntel, wird also faktisch immer geschrieben, da es eine Änderung ist. Lücken sind (für mich) vernachlässigbar klein. Damit liegen auch alle anderen relevanten Werte (desired-temp, valvePos,....) im logfile vor - und die Darstellung passt. Muss ich nichts kompliziertes machen. event-on-change-reading .* funktioniert also auch hier hervorragend, ohne Zusätze und Extras.