Anfänger Frage zu notifiy und 1W (DS2413 und DS2438)

[HeadCrash]

Hi,

ich hab einen Raspberry mit COC und daran einen paar 1W Chips. 1W wird per OWFS abgefragt und ist per OWServer/OWDevice in FHEM auch sichtbar.
Der "State" ändert sich auch. Soweit so gut.

Nur wie kann ich jetzt eine Aktion auslösen wenn sich z.B. der Status von "sensed.A" im DS2413 ändert oder "VAD" im DS2438 einen bestimmten Wert erreicht?

Ich dachte da an das "notify" nur wie muss ich den REGEXP befüllen ???

Sowas wie define Test notify 1W_TEST.sensed.A:0 { fhem("set WHATEVER on") } scheint nicht zuklappen.

Im Vorfeld schonmal Danke für alle Tips :)

[justme1968]

Code Auswählen Erweitern

define test notify 1W_TEST:sensed.A ...

gruss
  andre

[HeadCrash]

Hi,

jo den hatte ich probiert, der geht. Thx. Hat abba janz wilde Sachen mit mir gemacht :-D.
Aber ich glaube ich verstehe jetzt auch warum. Der Rückgabewert von dem 1W lautet "sensed.A: 1  sensed.B: 1" (wörtlich!) und mein RegEx muss quasi GENAU darauf zugeschnitten werden. Ohne wird die Aktion quasi bei jedem Poll ausgeführt, und das wollen wa ja net.

Sowas wie Port1 = 0 usw. gibts nicht zufällig oder? Bzw. kann man das selber definieren? Dann wäre das notifiy leichter.

Wenn nicht dann wird's heavy. Jetzt nicht wegen der RegEx'e, das bekomme ich hin. Aber ich muss dann ja sicher das ein oder andere Zeichen escapen - oder?
Weil der ":" z.B. wird ja schon verheizt, Oder hab ich mich da jetzt verlaufen, wenn nicht wie escape ich das ":" und die Leerzeichen.

Nochmals Dankeschön :).

[justme1968]

also... ganz viele möglichkeiten :)

- wenn du nur bei geänderten werten ein event möchtest -> event-on-change-reading setzen

- schau im event monitor was genau für events kommen. es sollte für jedes reading eins sein. also sensed.A und sensed.B getrennt

- der kombinierte wert ist nicht für ein 'normales' reading sonder für state. das kannst du für notifys normalerweise ignorieren

- du kannst entweder die regex in den notifys so genau wie möglich bauen oder im notify mit if im perl code und %EVENTPART deine reaktion genauer spezifizieren

gruss
  andre

[HeadCrash]

Okay, halten wir erstmal fest du hast Ahnung :-) und ich hab ungefähr 25% verstanden :-D.

- wenn du nur bei geänderten werten ein event möchtest -> event-on-change-reading setzen

Erledigt. Coole Funktion.

- schau im event monitor was genau für events kommen. es sollte für jedes reading eins sein. also sensed.A und sensed.B getrennt

Jupp, das passt.

- der kombinierte wert ist nicht für ein 'normales' reading sonder für state. das kannst du für notifys normalerweise ignorieren

Puh, ein Glück.

- du kannst entweder die regex in den notifys so genau wie möglich bauen oder im notify mit if im perl code und %EVENTPART deine reaktion genauer spezifizieren

Für den Anfang evtl. mal lieber nicht.


Nur leider scheint mir da immer noch ein Stück zu fehlen, sorry falls ich nerve.

Code Auswählen Erweitern

define Test_Log notify 1W_Flur_DS2413:sensed.A: 0 { Log 3, "@: 1W Test Wert: ".Value("1W_Flur_DS2413") }
Das kann nich richtig sein, der RegEx wird nach dem letzen ":" abgeschnitten, der Wert (hier "0") ist somit nicht mehr Teil der Prüfung :(

Code Auswählen Erweitern

define Test_Log notify 1W_Flur_DS2413:.* { Log 3, "@: 1W Test Wert: ".Value("1W_Flur_DS2413") }
Der geht und Dank dem "event-on-change-reading" wird er auch nur noch bei Änderung abgefahren, aber auch hier fehlt mir wieder die Prüfung auf den Wert von sensed.A.

Code Auswählen Erweitern

define Test_Log notify 1W_Flur_DS2413:sensed\.A.*0 { Log 3, "@: 1W Test Wert: ".Value("1W_Flur_DS2413") }
Der scheint das zu tun was ich möchte, aber das ".*" stört mich persönlich etwas.

Ich glaub ich mach da später weiter. Außerdem scheint mir "laggt" die Abfrage des 1W Busses obwohl ich das interval (Testweise) auf eine Sekunde runtergeschraubt habe.

Vielen Dank für Deine Unterstützung.

[justme1968]

Nur leider scheint mir da immer noch ein Stück zu fehlen, sorry falls ich nerve.

noch nicht :)

Code Auswählen Erweitern

define Test_Log notify 1W_Flur_DS2413:sensed.A: 0 { Log 3, "@: 1W Test Wert: ".Value("1W_Flur_DS2413") }
Das kann nich richtig sein, der RegEx wird nach dem letzen ":" abgeschnitten, der Wert (hier "0") ist somit nicht mehr Teil der Prüfung :(

doch. ist es. die syntax ist <device>:<reading>. der doppelpunkt ist das trennzeichen und danach wird intern geparsed. im prinzip gehört alles was nach dem zweiten doppelpunkt im event kommt auch nicht mehr zum reading  namen sondern ist der wert des readings (<device>: <reading>: <wert>).

Code Auswählen Erweitern

define Test_Log notify 1W_Flur_DS2413:.* { Log 3, "@: 1W Test Wert: ".Value("1W_Flur_DS2413") }
Der geht und Dank dem "event-on-change-reading" wird er auch nur noch bei Änderung abgefahren, aber auch hier fehlt mir wieder die Prüfung auf den Wert von sensed.A.

das matched auf alle events vom 1W_Flur_DS2413. wenn du wirklich auf alles matchen willst kannst du das ':.*' auch weg lassen und nur das <device> hin schreiben.

Code Auswählen Erweitern

define Test_Log notify 1W_Flur_DS2413:sensed\.A.*0 { Log 3, "@: 1W Test Wert: ".Value("1W_Flur_DS2413") }
Der scheint das zu tun was ich möchte, aber das ".*" stört mich persönlich etwas.

wie oben schon gesagt: normalerweise verwendest du <device>:<reading> als pattern im notify. also so:

Code Auswählen Erweitern

define test notify 1W_TEST:sensed.A ...das matched genau auf das eine reading sensed.A. wenn du dann etwas wertabähngig machen möchtes geht das normalerweise mit perl code (die version von oben den wert mit zu matchen geht wird aber sehr schnell unhandlich wenn es nicht mehr nur um 0 oder 1 geht.) im perl code bekommst du dann in deinem fall mit %EVTPART1. also so etwas:

Code Auswählen Erweitern

define test notify 1W_TEST:sensed.A {
  if( "%EVTPART1" == 1 )
    ...
  } else {
    ...
  }
} (sowas am besten erst mal nur mit {} eingeben und dann im web frontend mit klick auf das DEF editieren. das spart sich um das maskieren von ';' und zeilenenden gedanken zu machen.)

je nach anwendung ist sensed vielleicht auch das falsche reading. bei einem DS2406 z.b. gibt es zusätzlich noch ein latch reading. das wird genau ein mal getriggered wenn sich das signal das erste mal ändert und bleibt so lange stehen bis es von hand zurück gesetzt wird.

Außerdem scheint mir "laggt" die Abfrage des 1W Busses obwohl ich das interval (Testweise) auf eine Sekunde runtergeschraubt habe.

im owserver ist ein cache timeout konfiguriert. alle anfragen die schneller als dieser timeout rein kommen werden aus dem cache beantwortet und spiegeln nicht den 'realen' wert des 1-wire devices dar. du kannst zwar im prinzip diesen timeout sehr weit runter setzen oder die ungecacheten werte verwenden. da es aber immer eine gewisse zeit braucht die werte aus dem 1-wirte device auszulesen (bei den DS18B20 z.b. etwa eine sekunde um die temperatur zu messen) macht das keinen sinn und du blockiertst damit nur alles.

im übrigen solltest du (je nach devices die bei dir am 1-wire bus hängen) für das OWserver device dsa attribut nonblocking setzen. sonst wird fhem sehr träge wenn du z.b. 10 temperaturen abfragst weil das alleine schon 10 sekunden dauert.

1-wire ist nicht wirklich für echtzeit gedacht.

gruss
  andre

[HeadCrash]

wenn du dann etwas wertabähngig machen möchtes geht das normalerweise mit perl code

Okay, dann war das der Teil den ich übersehen hatte.

Leider ist bei meinem RasPi gestern das Filesystem (mal wieder) kaputt gegangen (SD-Karten Problemchen). Daher muss ich das 1W erstmal wieder erneut-installieren, das fehlte in meiner Backup SD-Karte.

Aber ich glaub ich weiß jetzt was ich zu tun hab.

Nochmals vielen Dank für die ausführlichen Infos.