setreading: kein Event und Protokollierung aus einem notify heraus

Begonnen von roedert, 17 Oktober 2014, 08:35:12

Vorheriges Thema - Nächstes Thema

roedert

Zitat von: justme1968 am 17 Oktober 2014, 12:15:52
@roedert: das ganze sollte noch einfacher werden wenn man statt dem at ein fhem sleep verwendet. also etwa so:{my $state = (($EVENT eq "on" || $EVENT eq "dimup")?1:0); fhem("sleep1;; setreading $NAME $state")}

Ändert das was? Es wird doch nur verzögert - aber doch immer noch aus einem notify aufgerufen.
Durch das erstellte "at" kommt es aus einem völlig neuen Umfeld - unabhängig von dem Notify.

roedert

Zitat von: justme1968 am 17 Oktober 2014, 12:15:52@rudi: wie wäre es in der doku zu setreading zu erwähnen das es nicht innerhalb eines notify funktioniert

setreading selbst funktioniert ja, es löst aus dem notify heraus eben nur keinen Event und kein Log-Eintrag aus

justme1968

@roedert: es ist nur etwas kürzer zum hinschreiben und es gibt keine warnung falls es das at schon gibt.

@rudi: das ist klar. aber das kein event erzeugt wird steht nicht in der doku und hat schon mehr als ein mal verwirrt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Elektrolurch

Hallo,

ich hatte so ein ähnliches Problem, mit dem Codeschnipsel des Telefonmonitors:
Die Events hatte ich per notify auf den FB_CallMonitor ausgewertet und beim FB_Call_Monitor mir readings für die Darstellung einer Liste angelegt.
Die wurde nicht on-screen aktualisiert, erst nach  Drücken von F5.
Nachdem ich aus dem Codeschnipsel ein eigenes Modul "Neues Modul Telefonmonitor (TM)" gebastelt habe und die readings der Listendarstellung nicht mehr beim FB_CallMonitor abgelegt habe, funktioniert auch die Aktualisierung auf dem Screen.
Aber da muss man erst einmal draufd kommen.....!
Ich hatte im Forum hier nachgefragt, aber da wusste das auch niemand so recht, warum das nicht funktionierte.....

Gut, wieder was gelernt.
Also, in einem notify keine readings desselben Objektes aktualisieren, wenn man log oder events braucht....

Gruß


Elektrolurch
configDB und Windows befreite Zone!

roedert

Zitat von: justme1968 am 17 Oktober 2014, 09:42:18
hast du dir userreadings angeschaut?

ok, das ist der andere Ansatz:

attr Katzenklappe.Sensor userReadings drin:(on|off|dimup|dimdown) {((Value($name) eq "on" || Value($name) eq "dimup")?1:0)}

Dies berücksichtig aber wie schon geschrieben das event-min-intervall nicht. Kann ich in dieses Userreading irgendwie soviel Logik bringen, dass es nur gesetzt wird wenn das vorherige Event länger als zB 4sec alt ist?

Durch das Pendeln der Katzenklappe darf ich eben nur das erste Event auswerten (was die "Richtung" vorgibt), die folgenden Meldungen des Magnetkontakten muss ich für ein paar Sekunden ignorieren.

justme1968

wie oben schon geschrieben: mit ReadingsTimestamp solltest du dir den zeitpunkt des letzten draussen readings holen können und mit jetzt vergleichen. eventuell musst du dir die zeit extra in einem .drausenTimestamp reading merken.

alles in allem finde ich die version mit sleep am kürzesten und elegantesten.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

roedert

Zitat von: justme1968 am 17 Oktober 2014, 12:15:52
@roedert: das ganze sollte noch einfacher werden wenn man statt dem at ein fhem sleep verwendet. also etwa so:{my $state = (($EVENT eq "on" || $EVENT eq "dimup")?1:0); fhem("sleep1;; setreading $NAME $state")}

Habs ausprobiert - es ändert aber nix.
Leuchtet ja auch ein - das temporäre "at" ist ja nicht wegen der 1sec Pause eingebaut, sondern darum, weil ein setreading auf das gleiche Device aus einem notify eben kein Event/Logeintrag generiert.
Da ändert auch ein sleep nix dran.

justme1968

das fhem sleep macht genau das. es legt intern ein temporäres at an und alles was danach kommt wird unsbhängig und nicht mehr im notify ausgeführt.

siehst du etwas im log?

gruß
  ander
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

roedert

Sorry, es funktioniert doch ... es war nur ein kleiner Fehler drin und ich hatte vorhin gar nicht ins Log geschaut.

{my $state = (($EVENT eq "on" || $EVENT eq "dimup")?1:0); fhem("sleep1;; setreading $NAME $state")}

Er mag das Doppel-Semikolon nach dem sleep nicht, mit einem Semikolon geht es.
Klar, in der cfg-Datei muss das Doppel-Semikolon stehen - nicht aber wenn ich es in der WebGui einpflege.

Mit ;; kommt im Log
sleep 1;; setreading Katzenklappe.Sensor drin 0 : Cannot interpret 1; as seconds
Katzenklappe:Sensor_nfy return value: Cannot interpret 1; as seconds

rudolfkoenig

@andre: habe die Doku erweitert, mit deinem sleep Vorschlag. Einen direkten Einbau in setreading halte ich fuer gefaehrlich, weil man in manchen Faellen direkt nach dem Aufruf der Wert noch nicht gesetzt waere, und das kann verwirren.

justme1968

ich finde gut das es dokumentiert ist.

wenn man in setreading das readingsupdate sofort macht und mit sleep einen trigger aufruf hinterher schickt wenn es aus einem notify aufgerufen wird wäre der wert sofort aktuell und nur das event wäre in diesem fall verzögert.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968