Philips Hue Bewegungsmelder - Zeit in Minuten seit der letzten Bewegung in State

Begonnen von PS915, 07 Februar 2019, 22:43:34

Vorheriges Thema - Nächstes Thema

DeeSPe

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. Auch wenn es bei mir über HOMEMODE läuft, lässt sich das auch ohne HOMEMODE umsetzen.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

PS915

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

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

KernSani

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...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...