Metadata: "Expiration Timer" (Reset/Update verbessern)

[Oekel]

Moin,

ich denke ich muss die grundlegende Funktion des "Expiration Timer" nicht erst erklären.
(Ich wähle hier send comand = OFF, was bedeutet der Timer startet bei ON)

Was jedoch für folgende Betrachtung wichtig erscheint, ist die Tatsache dass ein erneuter Trigger (sendCommand ON) den Timer erneut zählen lässt.

Meine Idee ist, einen Timer mit ca 1min zu setzen und den entsprechenden Ausgang(Licht) per Regel über einen PIR-Sensor or Radar-Sensor zu aktivieren.
Im Grunde genommen funktioniert dies auch, aber nur solange der Mensch vor dem Sensor immer wieder kleine Bewegungspausen macht und somit eine neue Flanke OFF->ON generiert.
Findet eine kontinuierliche Bewegung und somit ein dauer ON (beim Sensor) statt, wird der Timer ablaufen (dunkel), was kontraproduktiv erscheint.

Bislang habe ich keine bessere Notlösung als eine Regel/Schleife zu bauen, welche kontinuierlich alle paar Sekunden (per Cron) ein neues "sendCommand ON" feuert und dann zwei weitere Regeln (basierend auf der ON-Zeit des Sensors) die jene Regel aktiviert/deaktiviert.

Für meinen Geschmack relativ viel Overhead.
Geht das nicht auch einfacher?

Weihnachtliche Grüße

[udo1toni]

Es kommt halt darauf an, wie Dein Sensor funktioniert.

Gewöhnlich wird ein Sensor entweder ON melden wenn er Bewegung erkennt und OFF melden, wenn er nach einem Timeout selbst immer noch keine weitere Bewegung erkennt, oder er wird bei jeder erkannten Bewegung ein ON melden, aber nichts tun, wenn er keine Bewegung erkennt.

In openHAB kann man diese beiden Typen daran unterscheiden, dass für Typ 1 immer wieder changed Ereignisse auftreten, und zwar immer dann, wenn aus "keine Bewegung erkannt" ein "Bewegung erkannt" wird und später wieder, wenn aus "Bewegung erkannt" wieder "keine Bewegung erkannt" wird.
Typ 2 triggert nur ein einziges Mal ein Changed Ereignis, und zwar bei der ersten Bewegung nach einem Systemstart. Danach ist das Item bereits auf Zustand ON und es gibt nur noch ein Update, aber kein changed Ereignis mehr.

Bei Typ 2 sollte es reichen, den Expiration Timer auf das Item zu konfigurieren, welches das Licht schaltet und dieses direkt per follow Profile mit dem Channel zu verbinden, welches die Bewegung meldet. Ganz wichtig: Es darf kein Haken bei "ignore state updates" gesetzt sein. Nur dann wird das wiederholte ON update den Expiration Timer immer wieder zurück setzen.

Bei Typ 1 wäre es sinnvoll, den Ausschalttimer über eine Rule auszulösen, und zwar dann, wenn der Melder selbst das OFF sendet. Also ON -> Licht an. OFF -> Timer starten. Timer läuft ab -> Licht aus. Logischerweise muss man bei der Wahl der Ausschaltzeit den Timeout des Melders dann mit berücksichtigen. Außerdem muss der Einschaltimpuls auch per Rule durchgereicht werden, weil sonst auch der Ausschaltimpuls als Befehl interpretiert wird.

Das Normalverhalten ist, dass Channel nur einen Status melden. Um einen Status als Command zu verwenden, muss man dann den Channel per follow Profile an das Item binden, so dass das Item den Status als Befehl interpretiert. Dazu muss der gemeldete Status natürlich auch einen gültigen Befehl darstellen (z.B. ist OPEN/CLOSED eines Contact Channels KEIN gültiger Befehl für ON/OFF eines Switch Items)

[Oekel]

Hi Udo,

da ich den Sensor an einem selbst gelötetem Modul (Tasmota) betreibe sprechen wir mit dem Logisch HIGH vs. LOW wohl defintiv über Typ1.
(Ich gehe den Umweg über MQTT und ein Generic MQTT Item.)

Typ2 habe ich glaube nicht wirklich verstanden.

Ich muss mir das mit dem "Follow" noch mal genau durchlesen, denn adhoc habe ich die Minimalversion in deiner Beschreibung noch nicht erkannt

Liebe Grüße

[udo1toni]

da ich den Sensor an einem selbst gelötetem Modul (Tasmota) betreibe sprechen wir mit dem Logisch HIGH vs. LOW wohl defintiv über Typ1.
(Ich gehe den Umweg über MQTT und ein Generic MQTT Item.)

Nö. Die Frage ist nur, was das Modul in Richtung MQTT Broker als Payload schickt. By the way ist MQTT kein Umweg, sondern ein Protokoll, welches genau für diesen Zweck eines der besten Protokolle ist (viel besser als http).
Sendet das Modul ON und OFF, oder ausschließlich ON. Im ersten Fall musst Du in openHAB einen Zwischenschritt gehen, um zu verhindern, dass das OFF die Leuchte ausschaltet, sendet das Modul ausschließlich ON, musst Du lediglich dafür sorgen, dass dieses ON auch korrekt in openHAB verarbeitet wird. Und ganz wichtig ist in dem Zusammenhang, dass der mqtt Channel als Switch Channel definiert ist und der Channel NICHT als isCommand markiert wird, sondern stattdessen im Link das Profile auf follow konfiguriert wird.