Zonen-basierte Anwesenheitserkennung und -steuerung

Begonnen von KernSani, 15 März 2019, 19:06:04

Vorheriges Thema - Nächstes Thema

KernSani

Liebe FHEMler,

Ich hatte in der Vergangenheit nur einige wenige DOIF-gesteurte Bewegungsmelder, habe nun aber begonnen, das Haus mit den kleinen XIAOMI motion Sensoren zu pflastern, daher habe ich mir ein paar Gedanken über einen etwas strategischeren Weg gemacht. Das bisherige Ergebnis ist ein (bisher eher rudimentäres) Modul, mit dem ich versuche eine "Zonen-basierte Anwesenheitserkennung" zu verwirklichen. Mich würde interessieren:

  • ob ihr ähnliche Ansätze verfolgt und wie ihr die realisiert habt
  • ob ihr Interesse an einem solchen Modul hättet (oder ob ich mal wieder Arbeit mache, die andere schon besser gelöst haben)

Die Idee:
Das Haus wird in Zonen aufgeteilt - das können einzelne Räume sein, aber auch z.B. ein Stockwerk. Ziel ist es jederzeit zu wissen, ob sich jemand (idealerweise auch wer - aber dahin ist noch ein weiter Weg) in dieser Zone aufhält.

Anwesenheitswahrscheinlichkeit: Wenn eine Bewegung (oder ein anderes Ereignis, das "Anwesenheit" bedeutet) erkannt wird, ist es ziemlich wahrscheinlich (default 99%), dass jemand anwesend ist, je länger keine weitere Bewegung erkannt wird, desto unwahrscheinlicher wird es, dass noch jemand anwesend ist. Daher startet das Modul bei erkannter Bewegung einen Timer, je länger der Timer läuft, desto geringer wird die Wahrscheinlichkeit dass jemand da ist, bis sie schließlich auf 0 sinkt  (um keine zu Hohe Last zu erzeugen erfolgt der countdown in 10%-Schritten). Die Dauer des Timers kann tageszeit-abhängig gesteuert werden.

Offen/geschlossen: Eine Zone kann "offen" oder "geschlossen" sein. (repräsentiert z.B. durch einen Türkontakt). Wird innerhalb einer geschlossenen Zone eine Bewegung erkannt, wird Anwesenheit als sicher angenommen (100%) und bleibt auch so, bis die Zone geöffnet wird (Wasp-in-a-box Konzept). Der Klassiker für diesen Fall ist die ausgedehnte Toilettensitzung - solange ich auf der Toilette sitze wird keine Bewegung erkannt, ich will aber trotzdem nicht plötzlich im Dunklen sitzen.
Eine Ergänzung dazu (insbesondere für Zonen, in denen kein "geschlossen" Zustand erkannt werden kann ist folgendes Modell: Es wird bei erkannter Anwesenheit grundsätzlich angenommen, dass die Person weiterhin anwesend ist (auch wenn keine Bewegung erkannt wird) - Erst wenn in einer angrenzenden Zone (siehe nächster Punkt) eine Bewegung erkannt wird, wird angenommen, dass die Person sich weiter bewegt hat (und der Counter beginnt zu laufen)

Angrenzende Zonen. Häufig beeinflussen sich die Zonen gegenseitig, um obiges Beispiel nochmal aufzugreifen: Wenn ich aus der Toilette komme, will ich nicht in einen komplett dunklen Flur kommen, daher kann ich den Flur als "angrenzende Zone" der Toilette definieren. Dadurch wird die Anwesenheitswahrscheinlichkeit der Toilette auf den Flur gespiegelt (sofern Flur > 0% und Toilette > Flur).
Umgekehrt kann aber Bewegung in einer angrenzenden Zone bedeuten, dass jemand die aktuelle Zone verlassen hat. In diesem Fall ist eine Bewegung in der angrenzenden Zone ein Trigger für den Start des Counters (Attribut boxMode).

Hierarchie von Zonen: Mein ursprünglicher Gedanke war auch Es ist möglich Hierarchien von Zonen zu bauen, d.h. Zone Erdgeschoss enthält Zone Flur, Zone Wohnzimmer und Zone WC etc... Zumindest für meinen aktuellen Zweck reicht aber das Konzept der angrenzenden Räume aus. WC, Wohnzimmer und Flur haben alle "Erdgeschoss" als angrenzende Zone. Einer Zone können "Kinder" zugeordnet werden. Dadurch wird immer die höhste Anwesenheitswahrscheinlichkeit eines Raumes auf das Erdgeschoss gespiegelt (Und ich schalte die indirekte Beleuchtung z.B. erst aus, wenn sich niemand mehr im EG befindet).
Anmerkung: Derzeit verhält sich eine Zone mit Kindern genauso wie jede andere Zone, d.h. sie kann einen decay-Wert etc. enthalten - aus meiner Sicht macht das wenig Sinn - aber vielleicht hat jemand einen passenden Anwendungsfall.

Im Augenblick bildet das Modul den Status ab - Einzelne (einfache) Steuerungen (Licht an bei > 0%, Licht aus bei 0%, inkl. Abhängigkeit vom Helligkeitswert) sind im Modul selbst integriert. Komplexere Steuerung sollten besser über DOIF/notify realisiert werden. Ziel des Moduls ist mehr die Anwesenheitsberechnung, nicht die daraus folgenden Aktionen.

Ich habe noch einige weitere Ideen und Gedanken (z.B. eine irgendwie geartete Integration mit RESIDENTS/ROOMMATES oder eine "intelligentere" Steuerung der Timer)

Definiert wird eine Zone ohne irgendwelche Parameter:
define myZone homezone

Als Attribute gibt es bisher:
hz_occupancyEvent: Event das eine Anwesenheit signalisiert (also typischerweise Bewegung, kann aber auch z.B. "Fenster  auf" sein). Anzugeben in der Form <device regex>:<Event regex>, also z.B. myMotionSensor:state:.motion. Bei allen Event-Attributen können auch Komma-getrennte Listen von <device regex>:<Event regex> Paaren angegeben werden.
hz_absenceEvent: Event das eine sichere Abwesenheit signalisiert, z.B. wenn manuell das Licht ausgemacht wird, oder ein RESIDENTS device auf absent wechselt.
hz_openEvent: Event (z.B. Türkontakt) das anzeigt, dass ein Raum geöffnet wurde. Wenn eine Zone mehrere Türen hat, werden die Regexe für jede Tür durch Leerzeichen getrennt angegeben 
mySensorLeftDoor:state:.open mySensorRightDoor:state:.open
hz_closeEvent: Event (z.B. Türkontakt) das anzeigt, dass ein Raum geschlossen wurde:
mySensorLeftDoor:state:.close mySensorRightDoor:state:.close
hz_decay: "Verfallszeit" in Sekunden, also die Zeit, die vergehen soll bis der Timer nach erkannter Bewegung auf 0 runter gezählt hat. Wird ggf. überteuert von tageszeitabhängiger Steuerung (siehe hz_dayTimes)
hz_adjacent: Komma-getrennte Liste von angrenzenden Zonen (homezone Devices)
hz_state: Leerzeichen getrennte Liste von Wert:State Paaren -> Wenn Anwesenheitswahrscheinlichkeit >= Wert, dann wird State als state gesetzt (wird beim define wie folgt gesetzt: 100:present 50:likely 1:unlikely 0:absent)
hz_children: Komma-getrennte Liste von "Kindern", d.h. homezone devices. Der höhste Anwesenheitswert wird der Kinder wird an die Zone "vererbt". 
hz_dayTimes: Leerzeichen-getrennt Liste von Uhrzeit:Text Paaren. Dient zur Steuerung tageszeitabhängiger decay-Werte. Für jeden "text" wird ein zugehöriges decay-Userattribut erzeugt, mit dem die korrespondierenden Decay-Werte gepflegt werden. Das Attribut wird beim Define automatisch gesetzt und - sofern vorhanden - mit dem Wert aus HOMEMODE gefüllt. Die variablen $SUNRISE und $SUNSET können anstatt Uhrzeit verwendet werden.
hz_cmd_<state>: Userattribute werden beim setzen von hz_state erzeugt. Jedem der Attribute kann ein Kommando (z.B. set myLight on) mitgegeben werden, das beim Eintritt des states ausgeführt wird. Mehrere Kommandos werden durch ; getrennt. Statt FHEM Kommandos ist auch Perl Code (durch {} umschlossen) erlaubt. In Perlcode wird $name durch den Devicenamen ersetzt.
hz_luminanceReading:Reading in der Form <device>:<reading> das den Helligkeitswert für die Zone angibt
hz_lumiThreshold zwei durch ":" getrennte Werte für die untere und obere Schwelle der Helligkeit (aus hz_luminanceReading) bei der geschaltet werden soll (hz_cmd_<state). z.B. 0:40 (nur wenn Helligkeit < 40 ist wird Kommando ausgeführt), untere und obere Schwelle können auch leer bleiben (z.B. "200:" Es wird nur geschaltet, wenn die Helligkeit über 200 liegt) 
hz_lumiThreshold_<state>: Userattribute werden beim setzen von hz_state erzeugt. Jedem der Attribute kann ein threshold übergeben werden, der den default threshold für diesen state übersteuert.
disabled/disabledForIntervals wie üblich, dekativiert das Device
hz_disableOnlyCmdsWenn ein device disabled ist (egal ob permanent oder "for Intervall) wird - sofern dieses Attribut auf "1" steht trotzdem noch Anwesenheit erkannt und geloggt wie üblich, es werden aber keine Cmds ausgeführt.
hz_doAlwaysNormalerweise werden die "cmd_" Befehle nur bei Statusänderung ausgeführt. Wenn doAlways auf 1 gesetzt ist, werden die Kommandos auch ausgeführt wenn das (occupancy- oder absence-) Event eintritt aber keine Statusänderung bewirkt.

Set Befehle gibt es Folgende:
occupied: Manuelles setzen einer Zahl zwischen 0 und 100 für die Anwesenheitswahrscheinlichkeit
open: manuelles setzen des open Status, als optionaler Parameter kann das auslösende device mitgegeben werden (reading lastZone)
closed: manuelles setzen des closed Status, als optionaler Parameter kann das auslösende device mitgegeben werden (reading lastZone)
active: aktivieren eines deaktivierten Devices
inactive: deaktivieren eines Devices, als optionales Argument kann ein Zeitraum (in Sekunden) mitgegeben werden, für den das Device deaktiviert wird (Attribut hz_disableOnlyCmds wird bei set inactive identisch zum Attribut disable behandelt)

Als readings werden erzeugt:
occupied: Zahl zwischen 0 und 100 für die Anwesenheitswahrscheinlichkeit
condition: open oder closed (im Falle mehrerer Türen auch "partly closed"
state: siehe Attribut hz_state
lastLumi: der letzte gelesene Helligkeitswert (bei der letzten Statusänderung)
lastZone: das letzte Device, das einen occupied Wert im aktuellen Device gesetzt hat
lastChild: das letzte Child-Device, das einen occupied Wert im aktuellen Device gesetzt hat - bei mehrstufigen Parent-Child-Hierarchien wird das hier das unterste Device (das Blatt des Baumes) berichtet.
doorN: bei mehreren Türen je ein reading pro Tür mit dem jeweiligen Status (open oder closed)

Anmerkung: Die grundsätzliche Idee ist zwar mit Bewegungssensoren und Türkontakten zu arbeiten, Anwesenheit kann aber auch durch irgendein Event in der Zone ausgelöst werden, also z.B. wenn ein Schalter gedrückt wird, ist ziemlich sicher jemand da. Ebenso kann ein Raum "geschlossen" werden, ohne dass ein Türkontakt (oder gar eine Türe) vorhanden ist. Die Zone "Fernsehecke" wird bei mir "geschlossen", wenn der Fernseher angeht.

Todo/Backlog
* Commandref
* Code Cleanup
* Unterschiedliche Kommandos abhängig von der Tageszeit (z.B.: hz_cmd_likely_evening)
* "Probably Asscociated with" sollte alle Devices, die als trigger dienen oder in Kommandos genutzt werden auflisten (erledigt 0.0.16)
* "Do Always"-Attribut: Kommandos werden bei jedem Trigger-Event ausgelöst, nicht nur bei Status-Änderung (erledigt 0.0.17)
* Bug fixes   

Ich freue mich auf Feedback.

##############################################################################
#     Changelog:
#       0.0.22 (2021-04-21):      Bugfix        -   Fixed duplicating "associatedWith" entries
#       0.0.21 (2021-04-19):      Bugfix        -   Fixed various issues with "hz_dayTimes"-Attribute
#                                 Maintenance   -   Adjusted/Improved commandref
#       0.0.20 (2021-04-18):      Bugfix        -   Fixed $empty Bug
#       0.0.19 (2021-04-17):      Bugfix        -   Changed some loglevels
#                                 Maintenance   -   text-field long for all attributes (where it makes sense)
#       0.0.18 (2021-04-16):      Feature   -   added commandref
#                                 Feuture   -   allow daytime-dependent commands     
#       0.0.17: Feature         -   added doAlways attribute
# 0.0.16: Feature         -   "Probably associated with" will be populated
#                               -   Fixed Bug with absence event
#       0.0.15: Maintenance     -   Code cleanup
#       0.0.14: Bugfix          -   Unnecessary log messages (Execution failed) removed
#               Bugfix          -   Fixed a bug in attribute validation (occupanyEvent)
#               Feature         -   Configure that "asleep" roommates trigger "present" (hz_sleepRoommates)
#       0.0.13: Bugfix          -   Fixed another bug with diableOnlyCmds
#               Bugfix          -   Fixed a perl warning (uninitialized value in numeric)
#               Feature         -   Added possibility to set inactive for <seconds>
#       0.0.12: Bugfix          -   Fixed buggy diableOnlyCmds
#               Feature         -   $name allowed in perl commands
#               Feature         -   new reading lastChild
#       0.0.11: Bugfix          -   in boxMode incorrectly triggered presence from adjacent zone
#               Feature         -   added diableOnlyCmds Attribute
#       0.0.10: Bugfix          -   Multiline perl
#               Feature         -   Optimized boxMode
#       0.0.09: Bugfix          -   Adjacent zone stuck at occupied 100 in some cases
#               Bugfix          -   boxMode was stopped by timer in adjacent zone
#               Feature         -   Allow Perl in Commands (incl. big textfield to edit)
#               Bugfix          -   adjacent or children attributes could get lost at reload
#       0.0.08: Feature         -   Added disabled-Attributes and set active/inactive
#               Feature         -   Added boxMode
#       0.0.07: Bugfix          -   Fixed a minor bug with lastLumi reading not updating properly
#               Feature         -   Support for multiple doors (wasp-in-a-box)
#       0.0.06: Bugfix          -   Luminance devices not found on startup
#               Bugfix          -   Lumithreshold not properly determined
#               Maintainance    -   Improved Logging
#               Bugfix          -   Parent devices not updating properly
#               Feature         -   Added absenceEvent
#       0.0.05: Maintenance     -   Code cleanup
#               Maintenance     -   Attribute validation and userattr cleanup
#               Bugfix          -   Fixed bug when "close" comes after "occupancy"
#               Feature         -   Some additional readings
#       0.0.04: Feature         -   Added state-dependant commands
#               Feature         -   Added luminance functions
#       0.0.03: Feature         -   Added basic version of daytime-dependant decay value
#       0.0.02: Feature         -   Added "children" attribute
#               Feature         -   List of regexes for Event Attributes
#       0.0.01: initial version
#
##############################################################################


RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

binford6000

#1
Hallo KernSani,
coole Idee  :)

Habe es mal installiert und für alle Räume eine HOMEZONE angelegt. Aus Ermangelung von Türkontakten bekomme ich natürlich nie 100 occupied.
Dafür aber mit hz_decay=30 ein schönes Bewegungsmuster wenn man durch die Räume geht  8)

Es wäre also für mich (oder für alle mit ohne Türkontakten) interessant, wie man sowas auch ohne Türkontakte lösen könnte.
Könnte mir sowas in der Art von watchdog vorstellen: Einen für occupied und einen für unoccupied...

Hab mir mal mit stateFormat das occupied Reading als state geholt. Sonst steht es ja nur auf ? ? ?.
Vermutlich auch den mangelnden Kontakt-Sensoren geschuldet.

Ein get device summary
löste ein FHEM Neustart aus. Ist halt noch nicht implementiert  ;D
Undefined subroutine &main::homezone_getState called at ./FHEM/98_homezone.pm line 216.

Ansonsten verfolge ich weiterhin gespannt dieses Projekt und stehe auch gerne zum Testen zur Verfügung :)
VG Sebastian

KernSani

Hi Sebastian,

du bist ja wieder schnell beim Testen dabei :)
stateFormat hatte ich vergessen zu erwähnen, habe ich genauso - bzw. hatte ich. Ich habe nämlich gerade noch ein state reading implementiert und den ersten Post aktualisiert (siehe Attribut hz_state im ersten Post) und den get Summary-Befehl rausgeworfen (copy/paste Fehler :-[)

Ich habe nur in ganz wenigen Räumen einen Türkontakt (bei uns stehen sowieso meistens die Türen offen). In den meisten Räumen setze ich daher einen relativ hohen decay-Wert. Innerhalb von 10 Minuten wird sich schon jemand bewegen... In der TV-Ecke habe ich "Fernseher an" als "closed Event" definiert. Damit kann ich stundenlang unbeweglich vor dem Fernseher sitzen bleiben. Erst wenn ich den Fernseher ausmache läuft der Timer los...

Grüße,

Oli 
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

loescher

Hi!

Finde ich eine super Idee!
Ganz klasse finde ich die Abbildung mit Wahrscheinlichkeiten.
Das stört mich schon an meinen aktuellen PRESENCE, dass das nur "ist da" und "ist weg" kennt, denn selbst wenn z.B. alle Handies da sind, könnten trotzdem alle kurz weg sein...
Mangels Sensoren kann ich leider nicht wirklich testen, aber meine Sensoren werden ja noch mehr...

LG,
Stephan.

binford6000

#4
ZitatIn der TV-Ecke habe ich "Fernseher an" als "closed Event" definiert. Damit kann ich stundenlang unbeweglich vor dem Fernseher sitzen bleiben. Erst wenn ich den Fernseher ausmache läuft der Timer los...

Gute Idee. Habe ich gleich mal übernommen.  :D

Was hältst du von einer Attribut-basierten decay Einstellung? Kürzere Zeiten nachts, längere am Tag/Abend.
Oder auch in Abhängigkeit von einem RESIDENTS device (home/(goto|a)sleep)?

VG Sebastian


KernSani

Zitat von: binford6000 am 15 März 2019, 21:16:51
Was hältst du von einer Attribut-basierten decay Einstellung? Kürzere Zeiten nachts, längere am Tag/Abend.
Wäre denkbar... Wobei mir im Augenblick ein bisschen der Anwendungsfall fehlt... Die Annahme wäre, dass du nachts nur mal schnell ein Glas Wasser in der Küche holst, tagsüber aber längere Koch-orgien veranstaltest?

Zitat von: binford6000 am 15 März 2019, 21:16:51
Oder auch in Abhängigkeit von einem RESIDENTS device (home/(goto|a)sleep)?
Das wäre ein möglicher Ansatz zur Residents-Integration, Ich dachte auch daran, ROOMMATES als "close" Event zu integrieren - heisst, eine Zone wird als Schlafbereich für einen ROOMMATE definiert, wenn er "asleep" ist, wird der ROOMMATE als 100% anwesend in der Schlafzone erkannt...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

binford6000

#6
Moin Oli,
ZitatWäre denkbar... Wobei mir im Augenblick ein bisschen der Anwendungsfall fehlt... Die Annahme wäre, dass du nachts nur mal schnell ein Glas Wasser in der Küche holst, tagsüber aber längere Koch-orgien veranstaltest?

Ja genau. Nachts ist man ja idR nur mal kurz unterwegs.

ZitatDas wäre ein möglicher Ansatz zur Residents-Integration, Ich dachte auch daran, ROOMMATES als "close" Event zu integrieren - heisst, eine Zone wird als Schlafbereich für einen ROOMMATE definiert, wenn er "asleep" ist, wird der ROOMMATE als 100% anwesend in der Schlafzone erkannt...

Jepp. Habe im Schlafzimmer asleep als "close" Event und awoken als "open" Event meines ROOMMATES eingetragen.
VG Sebastian

enno

Moin KernSani,

ich habe dein Modul mal eingebaut. Ich mache so etwas zur Zeit mit einem DOIF, mit deinem Modul sieht es aber eleganter aus.

Frage:
Zitathz_occupancyEvent: Event das eine Anwesenheit signalisiert (also typischerweise Bewegung, kann aber auch z.B. "Fenster  auf" sein. Anzugeben in der Form <device regex>:<Event regex>, also z.B. myMotionSensor:state:.motion

Kann ich mehrere Bewegungsmelder einfügen? In Form eine Liste? Oder muss das in einem regex verpacken?

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

KernSani

Moin Enno,

aktuell geht nur Regex, das sollte eigentlich genug Flexibilität bieten. Um Einstiegshürden zu verringern kann ich das aber gerne erweitern.

Grüße,

Oli


Kurz, weil mobil
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

enno

Zitat von: KernSani am 16 März 2019, 12:00:54
aktuell geht nur Regex, das sollte eigentlich genug Flexibilität bieten. Um Einstiegshürden zu verringern kann ich das aber gerne erweitern.

ok, für Nichtprogrammierer ist Liste einfacher, aber https://regex101.com/ führt auch zum Ziel. Also meinetwegen kein Aufwand. Ich habe jetzt ein paar Zonen eingerichtet, mal sehen was ich damit anstellen kann... Fehlermeldungen habe ich keine, super!

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

netsrac4th

Zitat von: enno am 16 März 2019, 14:24:13
ok, für Nichtprogrammierer ist Liste einfacher, aber https://regex101.com/ führt auch zum Ziel. Also meinetwegen kein Aufwand. Ich habe jetzt ein paar Zonen eingerichtet, mal sehen was ich damit anstellen kann... Fehlermeldungen habe ich keine, super!

Gruss
  Enno

Ja, das Ganze sollte etwas unkomplizierter sein und mehr User friendly. Ansonsten eine Gute Idee.

KernSani

Sehr schön, das Projekt scheint nicht völlig sinnlos zu sein, steckt aber natürlich noch in den Kinderschuhen. Ich habe mittlerweile doch eine kleine Änderung gebaut, die es mir ermöglicht "Hierarchien" von Zonen besser abzubilden, d.h. man kann Zonen einrichten, denen man über ein Attribut untergeordnete Zonen mitgibt. Die "Eltern"-Zone übernimmt dann immer den höhsten occupancy-Wert aller Kinder - ich teste das gerade noch mit "Erdgeschoss" und "Obergeschoss"-Zone und werde es i Laufe des Abends im ersten Post zur Verfügung stellen.

Geplant habe ich dann noch:
* Liste (zusätzlich zu Regex) für die Event-Attribute
* Zeitabhängige decay Werte, meine Idee wäre ein zusätzliches Attribut, in dem man Zeiträume definieren kann (z.B. 22:00-06:00,06:00-14:00,14:00-22:00), das decay-Attribut müsste dann auch eine Liste bekommen (30,120,180) die den decay-Wert für den korrespondierenden Zeitraum angibt - wäre das ein sinnvoller Ansatz?
* Erster Wurf für die Commandref

@netsrac4th: Bezog sich deine Anmerkung nur auf die Regexe bei den Events oder hast du noch andere Anregungen, was man einfacher machen könnte?   

Danke,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

netsrac4th

Zitat von: KernSani am 16 März 2019, 15:33:42
Sehr schön, das Projekt scheint nicht völlig sinnlos zu sein, steckt aber natürlich noch in den Kinderschuhen. Ich habe mittlerweile doch eine kleine Änderung gebaut, die es mir ermöglicht "Hierarchien" von Zonen besser abzubilden, d.h. man kann Zonen einrichten, denen man über ein Attribut untergeordnete Zonen mitgibt. Die "Eltern"-Zone übernimmt dann immer den höhsten occupancy-Wert aller Kinder - ich teste das gerade noch mit "Erdgeschoss" und "Obergeschoss"-Zone und werde es i Laufe des Abends im ersten Post zur Verfügung stellen.

Geplant habe ich dann noch:
* Liste (zusätzlich zu Regex) für die Event-Attribute
* Zeitabhängige decay Werte, meine Idee wäre ein zusätzliches Attribut, in dem man Zeiträume definieren kann (z.B. 22:00-06:00,06:00-14:00,14:00-22:00), das decay-Attribut müsste dann auch eine Liste bekommen (30,120,180) die den decay-Wert für den korrespondierenden Zeitraum angibt - wäre das ein sinnvoller Ansatz?
* Erster Wurf für die Commandref

@netsrac4th: Bezog sich deine Anmerkung nur auf die Regexe bei den Events oder hast du noch andere Anregungen, was man einfacher machen könnte?   

Danke,

Oli

Ich bin ja nur Nutzer, aber ich denke das schreckt viele ab, etwas neues einzubauen, wenn man nur über Attribute und Regex etwas machen will.
Ist halt nicht mehr zeitgemäß, aber halt FHEM.

KernSani

Zitat von: netsrac4th am 16 März 2019, 16:03:16
Ich bin ja nur Nutzer, aber ich denke das schreckt viele ab, etwas neues einzubauen, wenn man nur über Attribute und Regex etwas machen will.
Ist halt nicht mehr zeitgemäß, aber halt FHEM.
Sorry, aber ich kann dir nicht ganz folgen. Wie wäre denn konkret deine Vorstellung? Mir fehlt irgendwie die Fantasie, welche benutzerfreundlicheren Möglichkeiten es gäbe, dem Modul zu sagen, auf welche Events es reagieren soll. Ich bin durchaus offen da was cleveres zu basteln- ich hab nur keine Idee...


Kurz, weil mobil
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

binford6000

ZitatIst halt nicht mehr zeitgemäß, aber halt FHEM.
Entweder einfach und (meistens) unflexibel oder extrem flexibel aber dafür mit mehr Aufwand und Einarbeitung verbunden.
VG Sebastian