ERLEDIGT: Problem mit event-on-change - oder: was mache ich falsch?

[tschennings]

Hallo,
ich habe mit FHEM und der Suche bisher viele Probleme lösen können und bereits umfangreiche Funktionen implementiert (Bewässerung, Garage, Licht, Entenfütterungsautomat...) aber bei diesem Problem hier stehe ich grad da wie zur ersten Stunde:
Ich frage mit einem define at... alle 10 Sekunden verschiedenste Stati zahlreicher Sensoren ab und bekomme damit eine dummy namens Alles_Status entweder "grün"oder "rot".
Bei "rot" soll eine Pushbullet-Nachricht geschickt werden:
define ticker_Statsus_Alle notify Status_Alle:rot { fhem("set Ticker message Status rot | Haussteuerung") }

Das klappt - nur kommt die Meldung dann alle 10 Sekunden. Der Status ändert sich zwar nicht, wird aber alle 10 Sekunden aktualisiert - und damit neu versendet. Nach meinem Verständnis sollte dafür "event-on-change" helfen, in der Art: attr Alle_Status event-on-change-reading (oder?)
tuts aber nicht. Hat vielleicht jemand den notwendigen Tip für mich?
Danke & Grüße
tschennings

[jojoja]

Hallo tschennings,

probiers doch mal mit

Code Auswählen Erweitern

attr Alle_Status event-on-change-reading <reading>
wobei <reading> wahrscheinlich state ist. Falls noch andere readings vorhanden sind sollten die Wechselwirkungen beachtet werden: http://www.fhemwiki.de/wiki/Event-on-change-reading

Gruß Johannes

[tschennings]

Hallo Johannes,
genauso hatte ich das auch verstanden - allerdings ändert die Zeile

attr Alle_Status event-on-change-reading state

garnix. Alle-Status ist ein dummy, das event ist ein state.

NAME Alle_Status
NR 723
STATE gruen
TYPE dummy

...der Pushbullet-Ticker kommt alle 10 Sekunden.
Was check ich da nicht??

[KernSani]

Hi,

poste doch mal den kompletten Output von "list Alle_Status". Wenn das oben der komplette Status ist, dann hat dein dummy kein reading, also macht auch event-on... nichts. WIe setzt du den Dummy? Mit set oder mit setstate? (Bei ersterem sollte ein Reading erzeugt werden, bei setstate nicht)

Grüße,

Oli

[tschennings]

Hallo KernSani,
list Alle_Status:

Internals:
   CFGFN      ./FHEM/haussicherung.cfg
   NAME       Alle_Status
   NR         721
   STATE      rot
   TYPE       dummy
   Readings:
     2016-09-26 20:06:55   state           rot
Attributes:
   group      Tuerueberwachung
   room       Haussicherung
   setList    gruen rot

der state wird per set gesetzt

[Ellert]

Hallo Johannes,
genauso hatte ich das auch verstanden - allerdings ändert die Zeilegarnix. Alle-Status ist ein dummy, das event ist ein state....der Pushbullet-Ticker kommt alle 10 Sekunden.
Was check ich da nicht??

attr Alle_Status event-on-change-reading state

funktioniert nicht, weil  ein state-Event kein "state" als Readingsname  enthält.

attr Alle_Status event-on-change-reading

funktioniert nicht, weil die Regexp weggelassen wurde.

Vielleicht funktioniert

attr Alle_Status event-on-change-reading .*

[KernSani]

Falls das auch nicht geht, fällt mir noch ein: du triggerst die message mit DOIF ohne das "do" Attribut zu setzen. DOIF löst per default nur einmal aus, wenn keine Zustandänderung erfolgt.

[tschennings]

Hi,
Danke erstmal für den support!
leider klappt "attr Alle_Status event-on-change-reading .*" auch nicht 

DOIF muss ich mich mal eben einlesen - probiere ich aus!
so?

define ticker_tueralarm_2 DOIF ([Alle_Status] eq "rot") (set Ticker message Status rot! | Haussteuerung)

Yaeh! Danke! DOIF does the job!!

[Ellert]

[Alle_Status:gruen]

Was meinst Du damit? Ist gruen ein Reading? Oder ein Event?

Beispiel: Reading in der Bedingung
Beispiel Event in der Bedingung

leider klappt "attr Alle_Status event-on-change-reading .*" auch nicht

Hast Du das Attribut im Frontend in der Geräteübersicht gesetzt oder direkt in der cfg-Datei? Ggf. das Leerzeichen vor .* weglassen.

[tschennings]

sorry - habs inzwischen geändert, war ein denkfehler. so wie oben passts und GEHT! 
Danke nochmal!

...wie Ändere ich nun den Thread-Titel auf : gelöst:...?

[KölnSolar]

Bin ich auf dem Holzweg, wenn ich aus Ellert's Aussage schließe, dass es nur eines readings zB. Ampelfarbe bedarf, welches mit setreading auf seine Farbe gesetzt wird ?
Grüße Markus
Edit: ich Holz..kopf. setreading löst ja kein event aus

[Ellert]

Bin ich auf dem Holzweg, wenn ich aus Ellert's Aussage schließe, dass es nur eines readings zB. Ampelfarbe bedarf, welches mit setreading auf seine Farbe gesetzt wird ?
Grüße Markus
Edit: ich Holz..kopf. setreading löst ja kein event aus

setreading löst ein Ereignis aus

[Pfriemler]

Bin ich auf dem Holzweg, wenn ich aus Ellert's Aussage schließe, dass es nur eines readings zB. Ampelfarbe bedarf, welches mit setreading auf seine Farbe gesetzt wird ? Grüße Markus

Wofür meinst Du das? Wenn es um das Abspeichern eines beliebigen Datums oder Wertes geht, benötigt man dafür nicht zwingend einen Dummy als Variable, sondern kann ein eigenes Reading in nahezu jedem Device anlegen. Und das erzeugt ein Event, auf das man mit den einschlägigen Mechanismen reagieren kann.

Abgesehen davon: Gibt es keine elegantere Methode, als die Sensoren alle 10 Sekunden zu pollen? Wenn die einen in FHEM darstellbaren Status (als STATE oder reading) haben, ist es doch sicher einfacher, die Neuberechnung des [Alle_Status] nur bei einer Änderung eines Einzelstatus anzustoßen?

BTW: Der Themenersteller kann durch Editieren des eigenen ersten Beitrags den Fred als gelöst markieren (Betreff ändern) oder ganz schließen.

[tschennings]

Hallo,
ja - zu den "alle 10 Sekunden pollen" werde ich (ebenfalls mit DOIF) eine deutlich elegantere Lösung (und quasi echtzeit-response) umsetzen!
Ich hatte DOIF voll unterschätzt und viel zu wenig beachtet!
Grüße
tschennings

[KölnSolar]

Wofür meinst Du das?

Ellert schrieb ja,

Zitat

attr Alle_Status event-on-change-reading state


funktioniert nicht, weil  ein state-Event kein "state" als Readingsname  enthält.

Meine Logik: muss man halt ein reading anlegen, auf das dann abgefragt und mit setreading gesetzt wird. Später kam mir dann in den Sinn, dass ein setreading nur das reading befüllt ohne ein event zu erzeugen, deshalb mein Edit:. Aber das hat Ellert dann richtigerweise auch wieder widerlegt.
Und natürlich brauchts dafür keinen Dummy. Aber den hatte der TE sich ja extra angelegt. Vielleicht wg. Übersichtlichkeit oder aber Unwissenheit ......
Jetzt frag ich mich nur, wie genau der TE das Problem gelöst hat.

so wie oben passts und GEHT! 

sagt MIR es nicht 
Grüße Markus