Hallo zusammen,
ich versuche in StateFormat meines Philips Hue Bewegungsmelders die Zeit in Minuten seit der letzten Bewegung zu berechnen, doch ich scheitere leider.
Der Sensor hat folgendes "Internal":
lastupdated_local: 2019-02-07 22:04:38
Nun versuche ich mit folgender Formel die Minuten auszugeben.
{POSIX::strftime("%M",time_str2num(InternalVal("motion.FlurOG","lastupdated_local","")) - time_str2num(localtime))}
Doch leider erhalte ich immer wieder diverse Fehlermeldungen. Mit dieser Formel erhalte ich den Error:
Error evaluating motion.FlurOG stateFormat: Usage: POSIX::strftime(fmt, sec, min, hour, mday, mon, year, wday = -1, yday = -1, isdst = -1) at (eval 2900) line 2.
Ich habe keinerlei Perl-Kentnisse, nur ein wenig PHP und C, sodass ich grundlegende Dinge verstehe, aber hierdran gerade scheitere.
Gruß,
Phil
POSIX::strftime mag das Format von time_str2num nicht.
sowas
time() - time_str2num(InternalVal("motion.FlurOG","lastupdated_local",""))
sollte die Sekunden seit dem letzten Update geben...
Danke, das funktioniert.
Mir ist allerdings aufgefallen, dass die Berechnung nur ausgeführt wird wenn man das Attribut "stateFormat" ändert/aktualisiert oder den Bewegungsmelder erneut ausgelöst wird.
Gibt es eine Möglichkeit, die Berechnung alle x Sekunden erneut ausführen zu lassen damit ich jederzeit die aktuelle Differenz bekomme?
Gruß,
Phil
Es wird nur aktualisiert, wenn ein Event kommt... Du könntest also mit einem at alle x Sekunden ein Event triggern (https://fhem.de/commandref_DE.html#trigger), ob das Sinn macht, wenn du 99% der Zeit nicht auf das Reading starrst, überlasse ich dir ;-)
Wie würde man es denn eleganter umsetzen? Es würde ja auch ausreichen, wenn die Aktualisierung nur jede Minute kommt.
Mein Hintergedanke ist folgender:
Schalte das Licht in Raum X nach Sonnenuntergang aus, wenn für x Sekunden keine Bewegung in stattgefunden hat.
Es wird doch sicherlich Readings geben die ausschließlich bei Bewegung entsprechend geändert werden, oder?
Zeig mal bitte ein list vom Device.
müsste das auch gehen wenn man auf das Userreading ein event-min-interval oder halt aufs state legt?
Also event-min-interval state:60 das sollte doch das at überflüssig machen oder?
es gibt keine attribute die ein device dazu bringen öfter zu senden als es möchte. die event attribute sind nur dazu da events zu ignorieren die öfter kommen als man möchte.
such mal im forum nach beispielen für counter auf on-for-timer. die funktionieren genau so und du kannst den code für dich abwandeln.
ansonsten ist das hier:
ZitatSchalte das Licht in Raum X nach Sonnenuntergang aus, wenn für x Sekunden keine Bewegung in stattgefunden hat.
ein typischer Anwendungsfall für einen WATCHDOG oder ein benanntes sleep. auch dafür gibt es viele beispiele hier im forum.
oder du schaltest einfach bei jeder bewegung mit on-for-timer für etwas mehr als das doppelte meldeintervall an. sobald keine neue bewegung kommt geht das licht von ganz alleine kurz danach aus.
du siehst: es gibt viele möglichkeiten dir out of the box mit fhem gehen.
Zitat von: justme1968 am 08 Februar 2019, 07:08:44
es gibt keine attribute die ein device dazu bringen öfter zu senden als es möchte. die event attribute sind nur dazu da events zu ignorieren die öfter kommen als man möchte.
such mal im forum nach beispielen für counter auf on-for-timer. die funktionieren genau so und du kannst den code für dich abwandeln.
Im Wiki steht aber
" Mit dem Attribut event-min-interval kann für Readings eines Gerätes festgelegt werden, dass nach einer bestimmten Zeit ein Event, auch ohne Wertänderung ausgelöst wird. "
???
Das Wiki ist da in der Tat etwas unklar. Bei event-on-change ist der Zusammenhang klarer: https://wiki.fhem.de/wiki/Event-on-change-reading
Kurz, weil mobil
okay ich habe jetzt gerade das event-min-interval verstanden. Bisher habe ich immer angenommen, das nach dem Interval ein event generiert wird, automatisch sozusagen. Es wird aber nur ein event generiert wenn das reading auch getriggert wird. Also das reading muss aktualisiert werden.
efmod DummyTest dummy
attr DummyTest event-min-interval .*:60
attr DummyTest setList on off
setstate DummyTest on
setstate DummyTest 2019-02-08 08:10:09 state on
Habe das mit meinem DummyTest mal nachgestellt, drücke ich auf on wechselt der state und ein event wird generiert. in den nächsten 60 sekunden kann ich soviel on off drücken wie ich will es kommt kein event, das reading state bekommmt aber imme einen neuen zeitstempel. nach 60 sekunden wird wieder ein event generiert und alles föngt von vorn an.
Und ich dachte immer das ich on drücke und nach 60 sekunden wird wieder ein event erzeugt mit dem aktuellen readingsstatus.
Ich glaube das Problem ist, dass die HueDevices keine Statusmeldungen in einem gewissen Abstand senden, sondern ausschließlich wenn eine Bewegung erkannt wurde.
Hier das aktuelle List device. Das letzte reading (Bewegung) war um 07:06.
Internals:
DEF sensor 3 1 IODev=huebridge
FUUID 5c5c96e5-f33f-1bb7-8097-12468e37eb9a6ace
ID S3
INTERVAL 1
IODev huebridge
NAME motion.FlurOG
NR 220
STATE 10236
TYPE HUEDevice
lastupdated 2019-02-08 06:06:44
lastupdated_local 2019-02-08 07:06:44
manufacturername Philips
modelid SML001
name Flur OG
on 1
reachable 1
sensitivity 2
swversion 6.1.0.18912
type ZLLPresence
uniqueid 00:17:88:01:02:02:6b:b3-02-0406
READINGS:
2019-02-08 07:06:44 battery 80
2019-02-08 07:06:44 reachable true
2019-02-08 07:06:44 state nomotion
helper:
devtype S
update_timeout 1
setList:
Attributes:
IODev huebridge
room Bewegung
stateFormat {time() - time_str2num(InternalVal("motion.FlurOG","lastupdated_local",""))}
Das ist doch gut.
Schau Dir watchdog an wie von Andre erwähnt. Der kann genau das was du willst.
Trigger auf state nomotion und wenn nach x Sekunden sich der state nicht ändert soll geschalten werden. Übe erstmal mit einem Dummy als Lampe.
oder wie oben schon ergänzt: einfach on-for-timer bei motion
Zitat von: justme1968 am 08 Februar 2019, 10:21:14
oder wie oben schon ergänzt: einfach on-for-timer bei motion
Ich würde eher bei "nomotion" ein "at" definieren, welches dann nach einer bestimmten Zeit die Lampe ausschaltet.
Der Grund dafür ist: wenn Du mit "on-for-timer" bei "motion" arbeitest und Dich die ganze Zeit im Raum bewegst (also es nicht zu "nomotion" kommt), dann stehst Du nach dem Ende von "on-for-timer" im Dunkeln und kannst im Raum rumhüpfen wie Du willst, es wird nicht wieder hell.
Du darfst Dir gerne ansehen wie ich das gelöst habe (https://wiki.fhem.de/wiki/Modul_HOMEMODE#HomeCMDmotion). Auch wenn es bei mir über HOMEMODE läuft, lässt sich das auch ohne HOMEMODE umsetzen.
Gruß
Dan
das kommt drauf an ob es mehrere motion events gibt oder nicht.
Da ich den WATCHDOG leider nicht programmiert bekommen habe, habe ich mich nochmal an
at gemacht und es funktioniert soweit ganz gut.
At triggert jede Minute den dummy, in dem die Berechnung als StateFormat eingetragen ist.
Folgende zwei Fragen hätte ich noch.
1. Ich habe es ohne meine Dummy (motion.FlurOG.min) versucht und die Berechnung per StateFormat in dem HUE Device (z.B motion.FlurOG) einzutragten und per
at zu triggern, nur leider hat sich dort nichts verändert. Jemand eine Idee, warum das Triggern dort nicht funktioniert hat?
2.
ZitatEs wird nur aktualisiert, wenn ein Event kommt... Du könntest also mit einem at alle x Sekunden ein Event triggern (https://fhem.de/commandref_DE.html#trigger), ob das Sinn macht, wenn du 99% der Zeit nicht auf das Reading starrst, überlasse ich dir ;-)
Mir ist bewusst, dass ich auf den Bewegungsmelder nur in den seltensten Fällen zurückgreifen muss und frage mich daher, ob ich bei einem Intervall von 1 Minute Probleme bekommen kann? Kann das die Prozessorleistung negativ beeinflussen, oder ist das zu vernachlässigen? Welche anderen Nachteile bietet dieses Methode?
define motion.FlurOG.min dummy
define motion.FlurUG1.min dummy
define motion.FlurUG2.min dummy
define motion.HWSRaum.min dummy
attr motion.FlurOG stateFormat [motion.FlurOG:lastupdated_local]
attr motion.FlurUG1 stateFormat [motion.FlurUG1:lastupdated_local]
attr motion.FlurUG2 stateFormat [motion.FlurUG2:lastupdated_local]
attr motion.HWSRaum stateFormat [motion.HWSRaum:lastupdated_local]
attr motion.FlurOG.min stateFormat {round((time() - time_str2num(InternalVal("motion.FlurOG","lastupdated_local",""))) / 60,0)}
attr motion.FlurUG1.min stateFormat {round((time() - time_str2num(InternalVal("motion.FlurUG1","lastupdated_local",""))) / 60,0)}
attr motion.FlurUG2.min stateFormat {round((time() - time_str2num(InternalVal("motion.FlurUG2","lastupdated_local",""))) / 60,0)}
attr motion.HWSRaum.min stateFormat {round((time() - time_str2num(InternalVal("motion.HWSRaum","lastupdated_local",""))) / 60,0)}
define motion.FlurUOG.update at +*00:01:00 set motion.FlurOG.min on
define motion.FlurUG1.update at +*00:01:00 set motion.FlurUG1.min on
define motion.FlurUG2.update at +*00:01:00 set motion.FlurUG2.min on
define motion.HWSRaum.update at +*00:01:00 set motion.HWSRaum.min on
STATE ändert sich nicht wenn es im device selber keine änderung gibt. stateFormat mit werten aus einem anderen device ist deshalb meist nicht sinnvoll.
aber warum machst du es dir so schwer und versucht es nicht erst mal mit den einfachen vorschlagen von oben:
je nach dem ob die bewegungsmelder nur ein oder mehrere motion events erzeugen:
- bei jedem motion event die lampe mit on-for-timer ein schalten. wenn sie schon an ist bleibt sie an, wenn kein motion mehr kommt geht sie aus. das geht ganz ohne zusätzliche dummys oder at oder berechnungen
- gleiches prinzip mit benanntem sleep und cancel bei no motion. das spart etwas funk last wenn die lampen per fs20 oder hm angesteuert werden
- beide varianten lassen sich mit einem einzigen notify das für alle melder und lampen funktioernt bauen wenn die devices in fhem sinnvoll benannt sind.
Zitat von: PS915 am 08 Februar 2019, 16:28:09
2. Mir ist bewusst, dass ich auf den Bewegungsmelder nur in den seltensten Fällen zurückgreifen muss und frage mich daher, ob ich bei einem Intervall von 1 Minute Probleme bekommen kann? Kann das die Prozessorleistung negativ beeinflussen, oder ist das zu vernachlässigen? Welche anderen Nachteile bietet dieses Methode?
Ich hatte oben den Eindruck, dass es dir rein um die Visualisierung geht... Da du das ganze wirklich als Timer verwenden willst, würde ich doch eher auf die dafür gedachten Mechanismen (watchdog, on-for-timer - letzteres mache ich bei mir) zurückgreifen. Vielleicht postest du hier (oder in einem neuen Thread) mal deine Watchdogversuche und wir versuchen den zum Laufen zu bringen.
Jede Minute ein Event sollte nicht spürbar sein (außer das Event stößt wieder eine ganze Kette an nachgelagerten Aktivitäten an). Wenn es dann aber mehr Devices werden, die womöglich noch geloggt werden und einen Rattenschwanz an notifies auslösen...