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 homezoneAls 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
#
##############################################################################
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
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
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.
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
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...
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
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
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
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
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.
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
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.
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
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
Zitat* 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?
Ja genau. hz_decay_periods zB. mit frei wählbaren Zeiträumen wie in deinem Vorschlag.
Und dann entweder über eine Liste in hz_decay oder für jeden Zeitraum ein neues Attribut zB. hz_decay_06:00_22:00
Oder auch sowas:
05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
und dann hz_decay_morning usw. Der Zeitraum ergibt sich jeweils aus den Abständen.
Dann ist es entwas sprechender. Letztlich Geschmackssache...
VG Sebastian
Zitat von: binford6000 am 16 März 2019, 17:45:08
Und dann entweder über eine Liste in hz_decay oder für jeden Zeitraum ein neues Attribut zB. hz_decay_06:00_22:00
(..)
und dann hz_decay_morning usw.
Hi Sebastian, Attribute werden normalerweise beim "define" gesetzt und nicht dynamisch erzeugt... Kennst du ein Modul, das sowas macht? Ich fände das durchaus schick (auch wenn mir nicht ganz klar ist, wie ich z.B. mit Änderungen des Attributnamens) dann umgehen sollte. Wenn du da einen Tipp hast schau ich mir das gerne an :-)
Zitat von: KernSani am 16 März 2019, 15:33:42Die "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.
Das passt genau in mein Anwendungsfall. Ich habe eine Zone für das ganze Haus, dann pro Etage und dort noch mal einzelne Räume/Ecken. Wenn du das so bereitstellt, bin ich auf einen Schlag 6 DOIF los. Hat was!
Liste ist für Anwender die wie ich von DOIF "verdorben" worden sind und sich nicht mit Notify anfreunden konnten einfacher. Ist halt eine Frage wie tief man einsteigen möchte. Irgendwann kommt man auch als User auf den Trichter das Regex interessante Möglichkeiten hat. Das ist aber beim Einstieg schon eine Hürde.
Gruss
Enno
Neue Version ist im ersten Post angehängt. Diese erlaubt jetzt die Angabe von mehreren Device:Event Paaren in den EVent-Attributen und enthält das schon angesprochene Attribut hz_children zum Bau von Hierarchien.
ZitatHi Sebastian, Attribute werden normalerweise beim "define" gesetzt und nicht dynamisch erzeugt... Kennst du ein Modul, das sowas macht? Ich fände das durchaus schick (auch wenn mir nicht ganz klar ist, wie ich z.B. mit Änderungen des Attributnamens) dann umgehen sollte. Wenn du da einen Tipp hast schau ich mir das gerne an :-)
22_HOMEMODE.pm macht das zB. so. Daher kommt auch mein Beispiel von HomeDaytimes:
05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|nightFüge ich dort weitere Zeiten hinzu (zB. 14:30|Nachmittag) so wird ebenfalls ein weiteres userattr HomeCMDdaytime-Nachmittag
hinzugefügt.
VG Sebastian
Achso, klar... als userattr geht... ich schaue mir das Mal bei HOMEMODE an, vielleicht kann cih das ja gleich als default ziehen, wenn vorhanden
Kurz, weil mobil
Zitat von: binford6000 am 16 März 2019, 19:28:02
22_HOMEMODE.pm macht das zB. so. Daher kommt auch mein Beispiel von HomeDaytimes:
05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
und schon umgesetzt... Achtung - ich habe mich noch nicht darum gekümmert die User-Attribute bei Änderungen aufzuräumen - Setzen sollte aber funktionieren.
Zitat von: KernSani am 16 März 2019, 21:08:50
und schon umgesetzt... Achtung - ich habe mich noch nicht darum gekümmert die User-Attribute bei Änderungen aufzuräumen - Setzen sollte aber funktionieren.
Während ich darüber nachdenke... Irgendwie würde auch ein einfacherer Modus Sinn machen, der schlicht und einfach unterschiedliche Werte für Tag/Nacht erlaubt (basierend auf sunrise/sunset)
Weitere Idee: Basierend auf den in hz_state definierten states werden userAttribute angelegt, denen man ein Kommando mitgeben kann (sowas wie attr myZone hz_CMD_absent set myLight off)
Zitathz_dayTimes: Leerzeichen-getrennt Liste von Text|Uhrzeit 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.
Sehr cool 8) Sogar mit HOMEMODE import! Musste das zwar jetzt manuell nachziehen mit einem defmod für jedes homezone-device.
Aber das ist zu verschmerzen. Ist ja nur jetzt während des Testens ;)
ZitatWährend ich darüber nachdenke... Irgendwie würde auch ein einfacherer Modus Sinn machen, der schlicht und einfach unterschiedliche Werte für Tag/Nacht erlaubt (basierend auf sunrise/sunset)
Das würde die manuellen Zeiten aus dayTimes perfekt ergänzen.
ZitatWeitere Idee: Basierend auf den in hz_state definierten states werden userAttribute angelegt, denen man ein Kommando mitgeben kann (sowas wie attr myZone hz_CMD_absent set myLight off)
Das wäre natürlich Bombe! Damit könnte man ja eine komplett zonen-basierte Lichtsteuerung aufbauen - ohne weitere DOIFs und notifys... :)
Mit Perl kann man sich dann auch noch Helligkeitswerte der einzelnen Räume oder global aus Twilight holen usw...
Soviel zum Thema FHEM und Flexibilität ein paar Posts weiter oben... 8)
Tolle Arbeit, weiter so Oli!!
VG Sebastian
Ich sehe wir denken in die selbe Richtung ;-)
Neue Funktionalitäten im ersten Post:
* State-abhängige Kommandos
* Angabe eines "Luminance-Readings" und Steuerung der Kommandos mittels Helligkeits-Schwellwerten
* $SUNRISE und $SUNSET als Variablen für Uhrzeit in dayTimes
Zitathz_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
Nach mehrmaligen Ändern des state werden die userattr leider nicht erzeugt.
Habe die Zone aber nicht neu angelegt sondern "nur" mit defmod geändert. Sollte aber eigentlich auch so gehen :o
Internals:
DEF
FUUID 5c8d2444-f33f-0308-7de3-bff15558551011af
FVERSION 98_homezone.pm:v0.0.3-s18522/2019-02-07
NAME bu_zone
NR 413
NTFY_ORDER 50-bu_zone
STATE present
TYPE homezone
VERSION 0.0.4
READINGS:
2019-03-17 12:48:46 condition closed
2019-03-17 12:49:46 dayTime day
2019-03-17 12:49:46 occupied 100
2019-03-17 12:49:46 state present
helper:
TIMER 1552823386
Attributes:
devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
hz_adjacent fl_zone
hz_closedEvent shuttle.pc:on
hz_dayTimes $SUNRISE|sr $SUNSET|ss 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 600
hz_decay_afternoon 300
hz_decay_evening 3600
hz_lumiThreshold 0:40
hz_luminanceReading fl_bwm:brightness
hz_occupancyEvent bu_bwm:on
hz_openEvent shuttle.pc:off
hz_state 100:present 50:likely 1:unlikely 0:absent
icon floor
userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_nightVG Sebastian
Was passiert, wenn du einfach mal das hz_state Attribut änderst? (oder ohne zu ändern den "attr" Knopf drückst? Wenn das hz_state-Attribut bereits vorhanden ist, wird es beim define/defmod nicht gesetzt (und daher auch keine userattribute erzeugt)
Edit: Für den Rest des Tages habe ich mir vorgenommen (soweit es die Zeit erlaubt) das ganze Ding aufzuräumen, d.h. Validierungen von Attributen, Aufräumen der Userattribute bei Änderung etc...
Zitatoder ohne zu ändern den "attr" Knopf drückst?
Das wars. Danke.
VG Sebastian
Hallo bin gerade in einem anderen Thread in dem ich eine Umsetzung von "Wasp in a box" anregen wollte, da ich es mit dem Programmieren nicht wirklich selbst habe, aber hier im Forum nichts bezüglich dieser doch recht raffinierten Logic gefunden habe,
Habe das ganze mal schnell in mein Fhem geworfen, dabei sind mir zwei Kleinigkeiten aufgefallen
1. Wenn ein Raum offen ist, und es wird gerade runtergezält, aber keine Bewegung mehr festgestellt und dann der Raum geschlossen wird, ohne das eine weitere Bewegung festgestellt wird, springt der Raum auf 100% Anwesenheit und bleibt auch dort.
Bedeutet das nicht, das wenn ich nachdem ich einen Raum verlassen habe, und von Aussen die Tür schließe dieser Raum nie auf Leer springt?
Wäre es nicht sinvoller einfach den Timer weiter ablaufen zu lassen, und nur wenn erneut eine Bewegung festgestellt wird den Raum auf 100% Anwesenheit zu stellen und dann auch dort zu belassen, bis das nächste mal eine Tür geöffnet wird?
2. Ich habe mehrere Flure in der Wohnung in die kein Tageslicht fällt. Diese schalte ich je nachdem zustand des Residents Devices asleep/awoken bzw home in einen stark gedimmten zustand oder volle Helligkeit. Dabei ist die Uhrzeit eigentlich egal. Das Licht soll sowohl morgens um 6, tagsüber um 16 Uhr und abends um 11 Uhr voll angehen, mich aber bitte nicht wenn ich nachts um 2 durch die Wohnung wandere oder morgens um 5 wenn ich gerade aufgestanden bin, blenden. Es kommt aber auch mal vor das ich erst um 4 Uhr morgens nach hause komme, dann hätte ich es gerne richtig hell und will nicht im Dämmerlicht den Kleiderhaken suchen müssen.
Vielleicht bin ich ja nicht der einzige der sowas braucht und du kanns, genau wie für die Uhrzeiten und die Helligkeit, eine Möglichkeit je nach Resident status verschiedene Befehle abzusetzen einbauen
Hi patlabor,
zu 1. Da gab's tatsächlich noch einen Bug, danke für den Hinweis. Ist in der am ersten Post hängenden Version behoben
zu 2. Eine Integration mit RESIDENTS/ROOMMATES/GUESTS macht definitiv Sinn. Ich bin aber immernoch am überlegen, wie ich das flexibel hinbekomme, ohne eine Unmenge von Attributen zu erzeugen. Ich kann mir neben asleep/awoken auch noch vorstellen z.B. eine andere Steuerung zu haben, wenn nur die Putzfrau im Haus ist... Vielleicht beschränke ich mich im ersten Schritt aber vielleicht mal auf die 6 möglichen RESIDENTS states, dann ist das überschaubar...
Grüße,
Oli
Moin,
wäre es evtl. noch möglich ein Userattribut einzubauen, welches das sofortige setzen einer Zone auf ,,absent" stellt? Ich benutze die Homematic Bewegungsmelder mit den zwei Tastern. Wenn ich das Licht manuell abschalte, dann ist auch keiner mehr im Raum.
...Ich gehe mal besser ins Bett...
habe gerade gesehen, dass es bereits open- und close-Events gibt...
Sehr schönes Modul, ist dir echt gelungen!
@Pythonf
Zitat von: KernSani am 15 März 2019, 19:06:04
das Haus mit den kleinen XIAOMI motion Sensoren zu pflastern
Link?
Das Problem bei allen derzeitigen Bewegungssensoren ist ja im Grunde, dass die sehr auftragen. Ein Balanceakt zwischen "wir sind die Guten" und "wir sind die gute NSA" ...
Als derzeitiger Tester falle ich aus - nicht genügend Sensoren vorhanden.
Zitat von: KernSani am 15 März 2019, 19:06:04
mit dem ich versuche eine "Zonen-basierte Anwesenheitserkennung" zu verwirklichen.
Nur das käme für mich in Frage. Ich will weder ein Familienmitglied noch einen Gast überwachen - ich will lediglich wissen, ob jemand da ist. Die Draußen-Katze ist übrigens ein kritischer Sonderfall: Die darf drin sein, soll aber nicht als anwesend zählen.
Zitat von: KernSani am 15 März 2019, 19:06:04
Mich würde interessieren:
Das da jemand einen vielleicht spannenden ersten Ansatz hat: https://forum.fhem.de/index.php/topic,95971.0.html
Zitat von: KernSani am 15 März 2019, 19:06:04
ob ihr Interesse an einem solchen Modul hättet
Ja.
Moin Oli,
als Feedback zu 0.0.5:
nach dem reload kommt folgende Meldung:
2019.03.18 09:58:40 1: PERL WARNING: Subroutine homezone_Initialize redefined at ./FHEM/98_homezone.pm line 48.
2019.03.18 09:58:40 1: PERL WARNING: Subroutine homezone_Define redefined at ./FHEM/98_homezone.pm line 74.
2019.03.18 09:58:40 1: PERL WARNING: Subroutine homezone_Undefine redefined at ./FHEM/98_homezone.pm line 109.
Danach habe ich ein Update gemacht um auch shutdown/restart zu machen:
Messages collected while initializing FHEM:
configfile: Couldn't get a luminance value for reading brightness of device fl_bwm
fl_bwm ist ein Homematic device mit brightness Reading.
Bei folgendem device bekomme ich partout keine hz_cmd userattr - auch nach manuellem attr hz_state:
Historie löschen
Internals:
FUUID 5c8bead4-f33f-0308-08a7-e01e244c7c0155f4
FVERSION 98_homezone.pm:v0.0.5-s18522/2019-02-07
NAME fl_zone
NR 404
NTFY_ORDER 50-fl_zone
STATE absent
TYPE homezone
VERSION 0.0.5
READINGS:
2019-03-17 20:24:33 condition open
2019-03-18 07:37:39 dayTime morning
2019-03-18 10:05:27 lastDayTime day
2019-03-18 10:05:27 lastZone timer
2019-03-18 10:05:27 occupied 0
2019-03-18 10:05:27 state absent
helper:
TIMER 1552899927
Attributes:
devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
hz_dayTimes $SUNRISE|sr $SUNSET|ss 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 300
hz_occupancyEvent fl_bwm:motion
hz_state 100:present 50:likely 1:unlikely 0:absent
icon floor
userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss
Füge ich einen weiteren state hinzu:
100:present 50:likely 30:test 1:unlikely 0:absent
bekomme ich nur für diesen ein hz_cmd_test userattr:
hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss hz_cmd_test hz_lumiThreshold_test
VG Sebastian
Mir ist gerade noch eine Sache aufgefallen. Liegt aber vermutlich eher daran das ich noch lange nicht alle Möglichkeiten von fhem durchschaut habe.
Wenn es zu einem Raum mehrere Türen gibt, reicht es wenn eine einzige Tür wieder geschlossen wird, damit der Raum als closed gilt. Unabhängig davon ob noch andere Türen auf sind.
Als Beispiel: Ein Flur mit einer Tür in einen weiteren Flur (tk_flur) und einer Tür zu einer Abstellkammer (tk_abstellkammer). Als hz_openEvent ist tk_(flur|abstellkammer):contact:.false, als hz_closedEvent ist tk_(flur|abstellkammer):contact:.true definiert.
Geht jetzt jemand durch tk_flur und lässt die Tür offen ist der Raum open. Danach öffnet man die Abstellkammer, der Raum bleibt weiter open. Schließe ich jetzt die Abstellkammer ist der Raum closed obwohl tk_flur noch offen ist. Auf dem Weg durch den Flur, löse ich den Bewegungsmelder aus, jetzt ist occupied 100 %. Verlasse ich den Raum jetzt, ohne tk_flur zu schließen bleibt occupancy auf 100 % stehen, auch ein nachträgliches schließen von tk_flur ändert nichts. Erst wenn die Tür geschlossen und wieder geoffnet wird, zählt der contdown wieder runter.
Hallo,
interessanter Ansatz, werde ich mal testet. Gibt es die Möglichkeit bei bestimmten Events einen festen Wert zu setzen. Als Beispiel: Ist der PC im Kinderzimmer an kann ich zu 80% davon ausgehen das jemand im Raum ist und mit 90% Sicherheit auch wer das in dem Moment ist.
Das über mehrere Räume und diverse Bedingungen sollte dann für jeden Raum und Person eine Wahrscheinlichkeit ergeben. Geht schon in Richtung Rasterfahndung oder KI ::)
Gruß
Eisix
Zitat von: ComputerZOO am 17 März 2019, 23:53:03
Moin,
wäre es evtl. noch möglich ein Userattribut einzubauen, welches das sofortige setzen einer Zone auf ,,absent" stellt? Ich benutze die Homematic Bewegungsmelder mit den zwei Tastern. Wenn ich das Licht manuell abschalte, dann ist auch keiner mehr im Raum.
open und close Events sind dafür nicht geeignet. ein "absenceEvent" würde aber tatsächlich Sinn machen - bei Licht aus wäre ein möglicher Anwendungsfall, bei RESIDENTS absent macht es aber sicherlich auch Sinn :-)
Zitat von: curt am 18 März 2019, 05:07:22
Link?
https://www.google.com/search?q=xiaomi+motion+sensor
ZitatAls derzeitiger Tester falle ich aus - nicht genügend Sensoren vorhanden.
Als "Anwesenheits-Event" kann z.B. auch ein gedrückter Lichtschalter oder das Einschalten des Fernsehers dienen ;-)
ZitatNur das käme für mich in Frage. Ich will weder ein Familienmitglied noch einen Gast überwachen - ich will lediglich wissen, ob jemand da ist. Die Draußen-Katze ist übrigens ein kritischer Sonderfall: Die darf drin sein, soll aber nicht als anwesend zählen.
Das ist das realistischste Szenario - noch besser aber wenn man tatsächlich die Person erkennt und auf deren Bedürfnisse oder Verhaltensweisen reagieren kann (Wenn Oma auf Toilette geht, wird dort Helene Fischer gespielt :-D) Es geht nicht um Überwachung
ZitatDas da jemand einen vielleicht spannenden ersten Ansatz hat: https://forum.fhem.de/index.php/topic,95971.0.html
Schau ich mir definitiv genauer an
Zitat von: binford6000 am 18 März 2019, 10:25:44
Moin Oli,
als Feedback zu 0.0.5:
nach dem reload kommt folgende Meldung:
(..)
Ich war gestern ein bisschen voreilig mit dem Hochladen, nach der großen Umbau-Aktion. Schaue ich mir an, ich habe auch noch ein/zwei Bugs bei mir, die ich fixen muss.
Zitat von: patlabor am 18 März 2019, 15:23:44
Mir ist gerade noch eine Sache aufgefallen. Liegt aber vermutlich eher daran das ich noch lange nicht alle Möglichkeiten von fhem durchschaut habe.
Wenn es zu einem Raum mehrere Türen gibt, reicht es wenn eine einzige Tür wieder geschlossen wird, damit der Raum als closed gilt. Unabhängig davon ob noch andere Türen auf sind.
Als Beispiel: Ein Flur mit einer Tür in einen weiteren Flur (tk_flur) und einer Tür zu einer Abstellkammer (tk_abstellkammer). Als hz_openEvent ist tk_(flur|abstellkammer):contact:.false, als hz_closedEvent ist tk_(flur|abstellkammer):contact:.true definiert.
Geht jetzt jemand durch tk_flur und lässt die Tür offen ist der Raum open. Danach öffnet man die Abstellkammer, der Raum bleibt weiter open. Schließe ich jetzt die Abstellkammer ist der Raum closed obwohl tk_flur noch offen ist. Auf dem Weg durch den Flur, löse ich den Bewegungsmelder aus, jetzt ist occupied 100 %. Verlasse ich den Raum jetzt, ohne tk_flur zu schließen bleibt occupancy auf 100 % stehen, auch ein nachträgliches schließen von tk_flur ändert nichts. Erst wenn die Tür geschlossen und wieder geoffnet wird, zählt der contdown wieder runter.
Korrekte Beobachtung... Mist, habe ich nicht bedacht... Die Lösung wäre, dass man mehrere "closed"-Events definiert, die alle erfüllt sein müssen - mal schauen, wie ich das elegant hinbekomme
Zitat von: Eisix am 18 März 2019, 16:26:46
Hallo,
interessanter Ansatz, werde ich mal testet. Gibt es die Möglichkeit bei bestimmten Events einen festen Wert zu setzen. Als Beispiel: Ist der PC im Kinderzimmer an kann ich zu 80% davon ausgehen das jemand im Raum ist und mit 90% Sicherheit auch wer das in dem Moment ist.
Das über mehrere Räume und diverse Bedingungen sollte dann für jeden Raum und Person eine Wahrscheinlichkeit ergeben. Geht schon in Richtung Rasterfahndung oder KI ::)
Gruß
Eisix
Zum ersten Punkt: Man kann über set occupied einen Wert setzen - sofern der Raum nicht "geschlossen" ist, wenn der nicht 100 ist, wird dann aber runtergezählt. Ich habe tatsächlich meinen PC als "closedEvent" definiert - solange er an ist, ist jemand im Raum. Wenn ich weggehe geht er nach ein paar Minuten in Standby und der Timer läuft los. (Der Fernseher ist auch ein "closedEvent")
Zum zweiten Punkt: Tatsächlich habe ich mir dazu auch schon Gedanken gemacht, bin aber noch nicht wirklich zu einem Ergebnis gekommen. Mal angeommen ich identifiziere alle Familienmitglieder über Roomates alle 4 sind zu Hause, ein Sohn sitzt an seinem PC, die Bewegung im Arbeitszimmer war wahrscheinlich ich, dann ist die Bewegung in der Küche mit hoher Wahrscheinlichkeit meine Frau etc... Das geht dann aber wahrscheinlich in die oben verlinkte KI Ecke ;-)
Google findet da relativ viel mit Xiaomi Motion Sensor.
Hast du da eine genauere Modell-Bezeichnung?
LG, Stephan.
Zitat von: loescher am 18 März 2019, 20:56:42
Google findet da relativ viel mit Xiaomi Motion Sensor.
Hast du da eine genauere Modell-Bezeichnung?
LG, Stephan.
Sorry, hatte das Stichwort "aqara" vergessen, das sind die die ich habe. In aller Kürze (es gibt genügend Bewertungen und Erfahrungen zu den Dingern, auch hier im Forum):
+ günstig (insbesondere aus China)
+ über zigbee2mqtt ohne proprietäres Gateway an FHEM anzubinden
+ klein und unauffällig
+ lange Batterielaufzeit (angeblich 2 Jahre)
- nicht konfigurierbar
- lange "dead"-Zeit nach erkannter Bewegung
ZitatIch war gestern ein bisschen voreilig mit dem Hochladen, nach der großen Umbau-Aktion. Schaue ich mir an, ich habe auch noch ein/zwei Bugs bei mir, die ich fixen muss.
Ergänzung: Bei allen meinen homezone devices aktualisiert sich das dayTime reading nicht mehr. Alle anderen readings schon:
Internals:
DEF
FUUID 5c8d2444-f33f-0308-7de3-bff15558551011af
FVERSION 98_homezone.pm:v0.0.5-s18522/2019-02-07
NAME bu_zone
NR 413
NTFY_ORDER 50-bu_zone
STATE present
TYPE homezone
VERSION 0.0.5
READINGS:
2019-03-18 21:40:34 condition closed
2019-03-17 23:06:55 dayTime night
2019-03-18 22:12:47 lastDayTime evening
2019-03-18 22:12:47 lastZone self
2019-03-18 22:12:47 occupied 100
2019-03-18 22:12:47 state present
helper:
TIMER 1552941969
Attributes:
devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
hz_adjacent fl_zone
hz_closedEvent shuttle.pc:on
hz_cmd_absent set bu_scene scene abwesend
hz_cmd_present set bu_scene scene anwesend
hz_dayTimes $SUNRISE|sr $SUNSET|ss 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 500
hz_decay_afternoon 300
hz_decay_evening 3600
hz_occupancyEvent bu_bwm:on
hz_openEvent shuttle.pc:off
hz_state 100:present 50:likely 1:unlikely 0:absent
icon floor
userattr hz_cmd_absent hz_cmd_likely hz_cmd_present hz_cmd_unlikely hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_lumiThreshold_absent hz_lumiThreshold_likely hz_lumiThreshold_present hz_lumiThreshold_unlikely hz_decay_sr hz_decay_ssVG Sebastian
Hi Sebastian,
ich habe dayTime durch lastDayTime ersetzt (da das Reading nur bei einem Anwesenheitsevent aktualisiert wird und nicht den aktuellen Wert anzeigt). Letzteres scheint korrekt aktualisiert zu werden.
Grüße,
Oli
@Sebastian: Was mir noch aufgefallen ist, unabhängig von dem Fehler, den ich noch finden muss:
hz_dayTimes $SUNRISE|sr $SUNSET|ss 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
wird nicht funktionieren, da die jeweiligen Zeiträume wie bei HOMEMODE über den Abstand von Zeitpunkt x - Zeitpunkt y berechnen und sortiert sein müssen. Bei variablen Angaben mit $SUNRISE/$SUNSET macht eigentlich nur sowas Sinn
hz_dayTimes $SUNRISE|day $SUNSET|night
oder vielleicht in der Art:
hz_dayTimes 03:00|earlyMorning $SUNRISE|morning 11:30|lunch 13:00|afternoon $SUNSET|night
neue Version, mit einigen Bugfixes und neuem "absenceEvent" im ersten Post.
Zitat von: KernSani am 18 März 2019, 20:34:15
ZitatLink?
https://www.google.com/search?q=xiaomi+motion+sensor
Kannst Du bitte kurz sagen, was die erwartete FHEM-Gegenstelle ist? Ich würde sodann mal einen bestellen wollen. Anscih weiß ich aber nicht, ob das in einem Haushalt, der extrem sensibel auf das Wort "Überwachung" hört, so gut kommt. Will sagen: Der trägt immer noch stark auf.
Zitat von: KernSani am 18 März 2019, 20:34:15
ZitatAls derzeitiger Tester falle ich aus - nicht genügend Sensoren vorhanden.
Als "Anwesenheits-Event" kann z.B. auch ein gedrückter Lichtschalter oder das Einschalten des Fernsehers dienen ;-)
Das habe ich alles nicht. Also schon, nur nicht sooo ... ok, kurz OT:
FHEM-geeignet und angebunden sind (ca.) 10 Temperatursensoren, 10 Fenstermelder, 10 Strom-Zwischenstecker (die durchaus zur Abschätzung dienen könnten).
Nicht FHEM-geeignet sind alle Taster/Schalter, weiterhin 20 Rolladen-Taster Marke Somfy-sehr_alt. Da könnte man überlegen - allerdings neige ich zu dem Modell "muss auch alles bei FHEM-Ausfall funktionieren". Es ist nicht so, dass ich ausnehmend arm bin, also da ginge schon was. Andererseits lernt man bei den Reichen das sparen: Ich würde ungern auf Verdacht hin sämtliche Stromschalter austauschen wollen (da fand ich auch noch nichts Sinnvolles).
Zitat von: KernSani am 18 März 2019, 20:34:15
ZitatDas da jemand einen vielleicht spannenden ersten Ansatz hat: https://forum.fhem.de/index.php/topic,95971.0.html
Schau ich mir definitiv genauer an
Der Kollege @Pythonf codet da offensichtlich was - hat aber noch nichts gezeigt. Dessen nur erzählter Ansatz könnte aber eine schlaue Ergänzung Deines Ansatzes sein - so jedenfalls mein erster Eindruck.
Zu mir: Ich habe Deinen derzeitigen Code nicht eingebunden, siehe oben. Zudem habe ich mich bisher erfolgreich vor dem doif-Konzept gedrückt. Ich selbst bin von der damaligen Ausbildung her Verfahrenstechniker mit Schwerpunkt Systemanalyse. Ein naher Verwandter ist Mathematiker mit Schwerpunkt Statistik.
ZitatDer Kollege @Pythonf codet da offensichtlich was - hat aber noch nichts gezeigt.
Ich möchte an dieser Stelle gerne mal mein Interesse zeigen. Ich schreib gerade an einem Python Programm, welches in erster Version Daten aus FHEM (aktuell nur dblog + mysql möglich) liest und diese einem Reinforcment Learning Modell übergibt. Vieles funktioniert schon, allerdings fehlt eine konkrete Einsatzmöglichkeit. Ich fände es sehr spannend, ein Modell hier zusammen zu entwickeln, was die Vorhersagen verbessert. Ob es die Ergebnisse dabei dann wirklich verbessern wird, müsste man testen und lässt sich schwer voraussagen. Da wir aber hier von Wahrscheinlichkeiten sprechen, stehen die Chancen einer deutlichen Verbesserung nicht schlecht. Ich bin allerdings an Python gebunden, zum einen, weil ich bisher nichts in Perl geschrieben habe und zum anderen weil die verwendeten Bibliotheken (Tensorflow, tf_agents) für Python geschrieben sind.
Wie könnte denn ein möglicher Ansatz aussehen?Was für mich bzw. ein Modell wichtig wäre, dass sind 3 Dinge:
- Observation: Der Zustand des smartHome (Sensoren, Zeit, etc.), die Hierarchie der Räume,
- Aktion: Die Änderung der Anwesenheit
- Reward: Eine Rückmeldung an das Modell, ob seine Vorhersage gut oder schlecht war
1. ist für dblog mit mysql relativ einfach umzusetzen, für sqlite etwas schwieriger aber ebenfalls möglich.
FileLog wäre für mich mit der meisten Arbeit versehen, aber später auch möglich. Ich würde mich aber gerne erstmal auf dblog festlegen wollen. FileLog Reader für Python https://github.com/PythonFZ/FHEM-FileLog-Reader (https://github.com/PythonFZ/FHEM-FileLog-Reader)
2. Wäre im Optimalfall ein binärer Wert: Anwesend oder nicht Anwesend. Hier ist mir noch keine Idee eingefallen, wie sich das umsetzten ließe. In deinem Modul verwendest du ja soweit ich das verstanden habe zwei verschiedene Ansätze "Wasp-in-a-box Konzept" und eine Abnahme der Anwesenheitswahrscheinlichkeit mit der Zeit.
3. Hier verwendet man zumeist irgendwelche Integer, aber auch hier fällt mir noch nichts konkretes ein.
Die Voraussetzung wäre also eine Idee, wie man Daten über die Anwesenheit gewinnt, welche man eigentlich vorhersagen will. In verschiedenen Publikationen wurden die Bewohner gebeten, ihre Aktivitäten über Tage/Wochen zeitlich datiert aufzuschreiben und damit wurde dann trainiert. Das ist aber in dieser Form definitiv nicht alltagstauglich. Falls jemand Ideen oder auch Fragen hat, dann versuche ich die gerne zu beantworten. Da das ganze aber alles noch eher auf theoretischer Ebene abläuft, würde ich das gerne erstmal hier: https://forum.fhem.de/index.php/topic,95971.15.html (https://forum.fhem.de/index.php/topic,95971.15.html) besprechen wollen, damit sich dieser Thread auf das Modul konzentrieren kann.
Zitat von: Pythonf am 19 März 2019, 01:23:59
FileLog wäre für mich mit der meisten Arbeit versehen, aber später auch möglich.
Also in der hohen Theorie nimmt sich FileLog und DB bzgl. der Parameter bgzl. der vorrangig eingesetzten Hardware ja nichts. Ok, ich bin parteiisch - ich habe FileLog. Und vermutlich eigentlich alle, die anfangen und später zu faul oder zu unmutig sind.
Die Frage ist, ob es schon ein Zwischenmodul gibt - welches also in Sinne von Auswertung sowohl FileLog als auch DB adressiert. Diese Frage kann ich nicht beantworten. - Falls es das noch nicht gibt, würde es wohl darauf hinauslaufen.
Zitat von: KernSani am 18 März 2019, 23:23:21
neue Version, mit einigen Bugfixes und neuem "absenceEvent" im ersten Post.
Cool, danke, komme erst am Samstag dazu das testen, werde dann berichten.
Oh Mann KernSani,
du bist Schuld, dass ich jetzt wieder in paar Tür- und Bewegungssensoren bestellt habe. :P
Werde mich also demnächst auch in die Riege der Tester einreihen...
Zitat von: curt am 19 März 2019, 00:24:18
https://www.google.com/search?q=xiaomi+motion+sensor
Kannst Du bitte kurz sagen, was die erwartete FHEM-Gegenstelle ist?
ich habe die mit zigbee2mqtt und MQTT2 angebunden. https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#zigbee2mqtt
Zitat von: Thyraz am 19 März 2019, 14:03:58
Oh Mann KernSani,
du bist Schuld, dass ich jetzt wieder in paar Tür- und Bewegungssensoren bestellt habe. :P
Hmm... wo kann ich meine Provision abholen? :D
Neue Version, die mehrere Türen unterstützt ist im ersten Post verfügbar. im open- und closed- Event kann jetzt eine Leerzeichen-getrennte Liste von kommagetrennten Regexen gepflegt werden. Jeder der Leerzeichen-getrennten Werte entspricht einer Tür - Reihenfolge und Anzahl sollte also bei open- und closed- Event identisch sein. Jede Tür bekommt ein eigenes Reading mit dem jeweiligen Status. Nur wenn alle Türen geschlossen sind, geht die Zone auf closed. Sobald (mindestens) eine Tür geöffnet wird, geht die Zone auf "open".
Ein paar Fragen, zu denen ich gerne eure Meinung hätte:
1. Wie zufrieden seid ihr mit der Anwesenheitskontrolle bisher? Meine Erfahrung in wenigen Sätzen: Wasp-in-a-box funktioniert gut, auch die hierarchische Abbildung macht Sinn, wo ich noch nicht zufrieden bin sind die angrenzenden Räume, ich habe aber aktuell keine konkrete Idee, wie man das noch verbessern könnte - aktuell wird der Anwesenheitsstatus da ja quasi gespiegelt - dadurch wird z.B die Lichtsteuerung einfacher (aber das ist eigentlich nicht das Ziel - siehe nächster Punkt). In vielen Fällen würde ich mir aber je nach Situation - einen schnelleren oder langsameren decay statt einer Spiegelung wünschen.
2. Zumindest meine Steuerung ist zu komplex, um sie über die bestehenden Attribute komplett abzudecken, nun könnte ich noch x zusätzliche Attribute einführen und miteinander ausmultiplizieren (um dann 100 userattribute der Form hz_cmd_present_morning_ROOMMATEx_... zu produzieren) - oder ich konzentriere mich auf die bessere Anwesenheitserkennung und mache die Steuerung wie gehabt über DOIF/notify - Ich tendiere zu Letzterem.
3. Die zeitabhängigen decay-Zeiten klangen für mich wie eine gute Idee - in der Praxis nutze ich sie aber nicht.
4. Insbesondere als Folge der Punkte 1 und 2 würde ich folgenden Ansatz bez. angrenzender Räume verfolgen:
a) Steuerung angrenzender Zonen (Licht im Flur soll nicht ausgehen, wenn ich auf der Toilette sitze) erfolgt nicht über das Modul selbst, sondern extern - im Modul könnte ich evtl. einen entsprechenden Set Befehl bereitstellen (sowas wie set hz_WC adjacentZones present|likely|unlikely|absent)
b) Tatsächlich ist es vermutlich so, dass die Anwesenheitswahrscheinlichkeit im aktuellen Raum sinkt, wenn in einem angrenzendem Raum Anwesenheit erkannt wird (oder umgekehrt - sie sinkt im angrenzendem Raum, wenn im aktuellen Raum Anwesenheit erkannt wird), da ich dann wahrscheinlich von einem Raum in den anderen gegangen bin. Meine Idee wäre daher, bei erkannter Anwesenheit in Raum A die Anwesenheitwahrscheinlichkeit in den angrenzenden Räumen zu reduzieren (z.B. auf 30% zu setzen, wenn aktuelle Wahrscheinlichkeit > 30% und < 100%) Was denkt ihr?
Danke,
Grüße,
Oli
Moin Oli,
Zitat1. Wie zufrieden seid ihr mit der Anwesenheitskontrolle bisher? Meine Erfahrung in wenigen Sätzen: Wasp-in-a-box funktioniert gut, auch die hierarchische Abbildung macht Sinn, wo ich noch nicht zufrieden bin sind die angrenzenden Räume, ich habe aber aktuell keine konkrete Idee, wie man das noch verbessern könnte - aktuell wird der Anwesenheitsstatus da ja quasi gespiegelt - dadurch wird z.B die Lichtsteuerung einfacher (aber das ist eigentlich nicht das Ziel - siehe nächster Punkt). In vielen Fällen würde ich mir aber je nach Situation - einen schnelleren oder langsameren decay statt einer Spiegelung wünschen.
Die Anwesenheitskontrolle funktioniert super. Angrenzende Räume nutze ich nicht (mehr). Ist in meinem Fall auch auf asleep
und damit auf Schlafzimmer, Flur, Klo und Küche begrenzt. Die könnte ich dann schalten wenn die Bewegung im sz bei asleep erkannt wird.
Zitat2. Zumindest meine Steuerung ist zu komplex, um sie über die bestehenden Attribute komplett abzudecken, nun könnte ich noch x zusätzliche Attribute einführen und miteinander ausmultiplizieren (um dann 100 userattribute der Form hz_cmd_present_morning_ROOMMATEx_... zu produzieren) - oder ich konzentriere mich auf die bessere Anwesenheitserkennung und mache die Steuerung wie gehabt über DOIF/notify - Ich tendiere zu Letzterem.
Ein klares jein ;D
Ja: Es wird (teils) unübersichtlich und vermutlich wird auch etwas Code dupliziert.
Nein: einmal dran gewöhnt (ich liebe HOMEMODE...) geht das schon mit den ganzen userattr.
Zitat3. Die zeitabhängigen decay-Zeiten klangen für mich wie eine gute Idee - in der Praxis nutze ich sie aber nicht.
Ich finde sie immer noch eine gute Idee und nutze sie weiterhin.
Zitat4. Insbesondere als Folge der Punkte 1 und 2 würde ich folgenden Ansatz bez. angrenzender Räume verfolgen:
a) Steuerung angrenzender Zonen (Licht im Flur soll nicht ausgehen, wenn ich auf der Toilette sitze) erfolgt nicht über das Modul selbst, sondern extern - im Modul könnte ich evtl. einen entsprechenden Set Befehl bereitstellen (sowas wie set hz_WC adjacentZones present|likely|unlikely|absent)
b) Tatsächlich ist es vermutlich so, dass die Anwesenheitswahrscheinlichkeit im aktuellen Raum sinkt, wenn in einem angrenzendem Raum Anwesenheit erkannt wird (oder umgekehrt - sie sinkt im angrenzendem Raum, wenn im aktuellen Raum Anwesenheit erkannt wird), da ich dann wahrscheinlich von einem Raum in den anderen gegangen bin. Meine Idee wäre daher, bei erkannter Anwesenheit in Raum A die Anwesenheitwahrscheinlichkeit in den angrenzenden Räumen zu reduzieren (z.B. auf 30% zu setzen, wenn aktuelle Wahrscheinlichkeit > 30% und < 100%) Was denkt ihr?
4.a) Siehe Kommentar zu 1.
4.b) Klingt gut. Du wirst eh nicht alle Eventualitäten abdecken können. Bei einer Etage und nur einem Bewohner ist die Sache relativ klar.
Bei mehreren Etagen und/oder mehreren Bewohnern wirds tricky.
VG Sebastian
Zitateine Leerzeichen-getrennte Liste von kommagetrennten Regexen...
Damit stellst du selbst HOMEMODE in den Schatten... ;D
Moin Oli,
zu 1: Sehr zufrieden ich nutze das Modul bisher in zwei Räumen => einer Etage => und dem Haus. Die schnelleren oder langsameren decay würde ich mir stark wünschen.
zu 2: Weitere Steuerung über Attribute würde ich stark hinterfrage. Für mich ist ASC ein negativ Beispiel. Ich habe es genutzt, es ist aber inzwischen so komplex, dass ich nicht mehr durchblicke welches Attribut zu welchem Ergebnis führt. Ich bin daher wieder zu selbstprogrammierten DOIF zurück gekehrt. Dein Modul in Kombination mit DOIF tut eigentlich einfach und übersichtlich was es soll. Was komplizierter wird, kann man mit DOIF/notify anflanschen.
zu 3: nutze ich noch nicht, könnte mir aber einige Anwendungsmöglichkeiten vorstellen.
zu 4: a würde ich auch extern sehen,
b: macht bei mir keinen Sinn, da ich nicht allein Wohne. Eine Person kann gerade den Raum verlassen haben und eine andere ist über die zweite Tür in den Raum gekommen sein. Bei Kindern ein Bewegungsmuster zu finden, das habe ich aufgegeben.
Für mein einfach strukturiertes Anwendergehirn macht das Modul schon genau das was ich benötige wenn Punkt 1 noch kommt, dann bin ich glücklich.
Gruss
Enno
@KernSani
Ich habe damit noch nicht angefangen; wegen fehlender/falscher Melder ist der derzeitige Nutzwert bei mir nicht soo groß. Aber ich möchte gern mal probieren...
Ich weiß nicht, ob meine Bitte zu unverfroren ist: Wäre es denn möglich, mal ein einfaches Beispiel (ich weiß nicht, zwei Zonen, zwei doif) zu veröffentlichen? Und natürlich die Moduldefinition mit Attributen.
Also *mir* würde es den Start deutlich erleichtern.
Mal kleines Beispiel vielleicht hilft das beim Verständnis - die Toilette besteht im Wesentlichen aus den Default-Attributen und ein paar zusätzlichen Attributen:
- die .*Event-Attribute zur Erkennung von Bewegung und open/close der Türe
- die cmd.* Attribute steuern in welchem state das Licht an und aus geht.
Zusätzlich ist noch ein genereller Threshold für die Helligkeit hinterlegt, d.h. die cmds werden nur ausgeführt wenn die Helligkeit < 40 ist. Nur das absent-Cmd wird immer ausgeführt (threshold 0 - unendlich)
defmod hz_EG_WC homezone
attr hz_EG_WC userattr hz_cmd_absent hz_cmd_likely hz_cmd_present hz_cmd_unlikely hz_lumiThreshold_absent hz_lumiThreshold_likely hz_lumiThreshold_present hz_lumiThreshold_unlikely
attr hz_EG_WC alias EG WC Anwesenheit
attr hz_EG_WC devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
attr hz_EG_WC group Zonen
attr hz_EG_WC hz_closedEvent EG_WC_Tuer:contact:.close
attr hz_EG_WC hz_cmd_absent set EG_WC_Licht off
attr hz_EG_WC hz_cmd_likely set EG_WC_Licht on
attr hz_EG_WC hz_cmd_present set EG_WC_Licht on
attr hz_EG_WC hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr hz_EG_WC hz_decay 120
attr hz_EG_WC hz_lumiThreshold 0:40
attr hz_EG_WC hz_lumiThreshold_absent 0:
attr hz_EG_WC hz_occupancyEvent EG_WC_motion2:occupancy:.true
attr hz_EG_WC hz_openEvent EG_WC_Tuer:contact:.open
attr hz_EG_WC hz_state 100:present 50:likely 1:unlikely 0:absent
Hilft das schon?
Hallo KernSani,
erstmal danke für das interessante Modul.
Kann es sein, daß man beim cmd-Attribut nur einen Befehl angeben kann? Ich hätte da mehrere Aktoren zu schalten.
Habe schon mit ; oder , oder ;; versucht zwei set-Befehle zu trennen. Es klappt aber nicht, es wird dann gar kein Befehl ausgeführt.
Zitat von: Laffer72 am 21 März 2019, 22:57:17
Hallo KernSani,
erstmal danke für das interessante Modul.
Kann es sein, daß man beim cmd-Attribut nur einen Befehl angeben kann? Ich hätte da mehrere Aktoren zu schalten.
Habe schon mit ; oder , oder ;; versucht zwei set-Befehle zu trennen. Es klappt aber nicht, es wird dann gar kein Befehl ausgeführt.
Bei mir funktioniert das (mit einfachem ";" getrennt). Hst du mal ins Log geschaut? Da sollte eine Meldung stehen, wenn der Befehl nicht funktioniert.
Zitat von: KernSani am 21 März 2019, 21:25:04
Hilft das schon?
Das kann ich noch nicht beantworten; ich ärgere mich erstmal mit einem SignalDuino-Dingens rum. Danach ... ich habe zwei Bewegungsmelder, die ich mal aus einer Laune heraus beschaffte. Den einen habe ich jetzt so auffällig auf den Esstisch gelegt, dass es schon wieder unauffällig ist.
Ich danke Dir für den Beispielcode.
Ich habe nochmal "gehirnt", was bei mir noch nicht so gut funktioniert. Das Ergebnis des "Hirnens" ist im ersten Post zu finden.
Die Grundannahme bisher war, dass eine Person mit einer gewissen Wahrscheinlichkeit abwesend ist, wenn keine Bewegung erfolgt (sofern keine Sensoren existieren, dass ein Raum geschlossen ist). Die Ergänzung ist nun: Ich kann für eine Zone das Attribut hz_boxMode auf 1 setzen. Die Annahme ist dann: Wenn in einer Zone eine Bewegung erkannt wird, ist eine Person anwesend (d.h. der Counter läuft nicht). Erst wenn in einer angrenzenden Zone eine Anwesenheit erkannt wird, habe ich mich (wahrscheinlich) bewegt und der Counter läuft los.Man könnte das Konzept noch erweitern und sagen erst wenn im aktuelle Raum eine Bewegung erkannt wird und kurz darauf im angrenzenden Raum, dann bin ich wahrscheinlich aufgestanden und weg, aber das hebe ich mir für die nächste Iteration auf.
Zitat von: KernSani am 21 März 2019, 23:30:31
Ich habe nochmal "gehirnt", was
Ich habe ja nur ganz theoretisches Wissen - besser gesagt begründete Vermutungen, was da real abgebildet wird. Im Grunde macht das Modul ja das ja nichts als eine Modellbildung im Sinne der Systemanalyse.
Von daher darf ich mal das Fenster einwerfen, natürlich nur im Sinne der Diskussion. Ein Fenster dürfte abhängig von der Außentemperatur sein: Bei -10° bedeutet ein offenes Fenster: Im Raum ist niemand. Bei +15° dürfte für Schlafzimmer zutreffen: Fenster offen, (definierte) Nachtzeit, Zone Schlafraum --> jemand im Raum.
@KernSani - Du sprachst von Türsensoren bei Dir:
1) Welche konkret?
2) Was sagte die Familie, als Du sie angebaut hast? Bzw. aus welchem Grund akzeptierte die Familie das?
Zitat von: curt am 22 März 2019, 01:11:03
Ich habe ja nur ganz theoretisches Wissen - besser gesagt begründete Vermutungen, was da real abgebildet wird. Im Grunde macht das Modul ja das ja nichts als eine Modellbildung im Sinne der Systemanalyse.
Von daher darf ich mal das Fenster einwerfen, natürlich nur im Sinne der Diskussion. Ein Fenster dürfte abhängig von der Außentemperatur sein: Bei -10° bedeutet ein offenes Fenster: Im Raum ist niemand. Bei +15° dürfte für Schlafzimmer zutreffen: Fenster offen, (definierte) Nachtzeit, Zone Schlafraum --> jemand im Raum.
[\quote]
Genau das meine ich damit, dass nicht notwendigerweise Bewegungssensoren verbaut sein müssen, um Anwesenheit zu erkennen. Die Problematik ist aber die selbe. Vielleicht wurde einfach vergessen, das Fenster zu schließen.
Zitat
@KernSani - Du sprachst von Türsensoren bei Dir:
1) Welche konkret?
2) Was sagte die Familie, als Du sie angebaut hast? Bzw. aus welchem Grund akzeptierte die Familie das?
Ich habe relativ wenige Türsensoren. Ich habe auch relativ wenige Türen und die stehen meistens offen. Verbaut habe ich sowohl Homematic (optisch) als auch XIAOMI (magnetisch). Für die Familie ist das kein Problem, da die Automatisierungen i.d..R. positiv wahrgenommen werden oder unbemerkt bleiben. Problematisch sind nur nicht funktionierende Automatisierungen. Ich glaube auch nicht, dass irgendwer das Gefühl hat, überwacht zu werden. Das wird sich in ein pasr Jahren vielleicht ändern, wenn ich den Jungs nachweisen kann, wann sie nachts nach Hause gekommen sind ;-)
Kurz, weil mobil
Zitat von: KernSani am 22 März 2019, 06:50:24
Für die Familie ist das kein Problem, da die Automatisierungen i.d..R. positiv wahrgenommen werden oder unbemerkt bleiben.
Nuj, ich habe die DDR noch in voller Pracht erlebt. Und von daher bin ich sowie selbst Nachgeborene höchst sensibel gegen jede Art von Überwachung. Gute Erziehung halt.
Der ganze Homematic-Zauber fällt für Türüberwachung aus, das trägt zu sehr auf. Das habe ich an der Haustür, an der Terrassentür und an den Fenstern, die typischerweise geöffnet werden. Aber wenn ich die nun noch an andere Türen klebe, werde ich mir anschließend ein Hotelzimmer suchen müssen.
Der Kern ist im Grunde Dein Halbsatz
Zitatoder unbemerkt bleiben
Und selbst das ist ein heikler Balanceakt.
Zitat von: curt am 22 März 2019, 07:02:45
Nuj, ich habe die DDR noch in voller Pracht erlebt. Und von daher bin ich sowie selbst Nachgeborene höchst sensibel gegen jede Art von Überwachung. Gute Erziehung halt.
Die "gute" Erziehung fehlt bei uns, das macht es vielleicht einfacher...
Zitat von: curt am 22 März 2019, 07:02:45
Der ganze Homematic-Zauber fällt für Türüberwachung aus, das trägt zu sehr auf. Das habe ich an der Haustür, an der Terrassentür und an den Fenstern, die typischerweise geöffnet werden. Aber wenn ich die nun noch an andere Türen klebe, werde ich mir anschließend ein Hotelzimmer suchen müssen.
Der Kern ist im Grunde Dein Halbsatz
Und selbst das ist ein heikler Balanceakt.
Ich will nicht wissen, was passiert, wenn die Familie herausfindet, dass du sie unbemerkt überwachst ;-) - Da hänge ich lieber ein Schild hin, "Dieser Raum ist FHEM überwacht" ;-)
Mit mit Wort "unbemerkt" hatte ich mich auf die Automatisierungen bezogen, nicht auf die Sensoren.
Insgesamt stimme ich dir aber zu, es ist immer ein Balanceakt, der Nutzer (d.h. im Wesentlichen die Familie) muss den Nutzen sehen und darf sich nicht bevormundet fühlen.
Zitat von: KernSani am 22 März 2019, 07:33:53
Ich will nicht wissen, was passiert, wenn die Familie herausfindet, dass du sie unbemerkt überwachst ;-)
Im Kinderzimmer des schon ganz großen Kindes (beruflich gleiche Fraktion) stand ein Temperatursensor auf dem Tisch. Das Kind kam zu Besuch und nächtigte im Kinderzimmer. Seitdem meldet *ReadingsSupervision* , dass der Sensor verschollen ist. Soweit dazu.
ZitatDer ganze Homematic-Zauber fällt für Türüberwachung aus, das trägt zu sehr auf. Das habe ich an der Haustür, an der Terrassentür und an den Fenstern, die typischerweise geöffnet werden. Aber wenn ich die nun noch an andere Türen klebe, werde ich mir anschließend ein Hotelzimmer suchen müssen.
Moin,
das sehe ich ganz genauso. Wobei ich jetzt nicht ausziehen müsste... ;)
Und daher finde ich Olis Vorschlag von #60 auch gut. Es sollte eine einfache Möglichkeit geben OHNE Türkontakte.
VG Sebastian
Zitat von: binford6000 am 22 März 2019, 07:59:05
Und daher finde ich Olis Vorschlag von #60 auch gut.
Bitte referenziere genauer: #60 ist von @KernSani - ich habe keine Ahnung wer Oli ist. Nun möchte Oli auch nicht suchen.
Zitat von: curt am 22 März 2019, 08:05:24
Bitte referenziere genauer: #60 ist von @KernSani - ich habe keine Ahnung wer Oli ist. Nun möchte Oli auch nicht suchen.
KernSani=Oli. Siehe #2 ;)
Was mir mit 0.0.8 aufgefallen ist:
Wenn ich ein set fl_zone occupied 10 mache und bereits ein Timer läuft, wird dieser mit dem manuellen Wert nur kurz überschrieben und läuft dann weiter:
2019-03-22 08:39:39 lastZone wz_zone
2019-03-22 08:39:39 occupied 50
[set fl_zone occupied 10]
2019-03-22 08:40:14 lastZone self
2019-03-22 08:40:14 occupied 10
2019-03-22 08:40:39 lastZone wz_zone
2019-03-22 08:40:39 occupied 30
Bug oder Feature?
lastZone ist jeweils das letzte meldende homezone-device?
VG Sebastian
@KernSani:
Planst du auch die Unterstützung von PERL-Code in den CMD-userattr? Ein
{fhem("set bu_szene scene anwesend");}
funktioniert momentan bei mir nicht.
Ein attr hz_device widgetOverride hz_cmd_likely:textField-long
würde dann auch Sinn machen.
VG Sebastian
Zitat von: binford6000 am 22 März 2019, 08:51:56
Was mir mit 0.0.8 aufgefallen ist:
Wenn ich ein set fl_zone occupied 10 mache und bereits ein Timer läuft, wird dieser mit dem manuellen Wert nur kurz überschrieben und läuft dann weiter:
2019-03-22 08:39:39 lastZone wz_zone
2019-03-22 08:39:39 occupied 50
[set fl_zone occupied 10]
2019-03-22 08:40:14 lastZone self
2019-03-22 08:40:14 occupied 10
2019-03-22 08:40:39 lastZone wz_zone
2019-03-22 08:40:39 occupied 30
Bug oder Feature?
lastZone ist jeweils das letzte meldende homezone-device?
VG Sebastian
Würde mal auf Bug tippen... da fehlt ein RemoveInternalTimer... schaue ich mir an. Ja, lastZone ist das letzte meldende Device, du kannst es auch manuell mitgeben:
set fl_zone occupied 10 vonMeinemDOIFgesetzt Bisher steckt da noch kein tieferer Sinn dahinter (ausser, dass das Modul unter bestimmten Umständen wissen muss, ob es timer-gesteuert aktualisiert wurde) aber da kommt sicher noch was.
Zitat von: binford6000 am 22 März 2019, 09:04:19
@KernSani:
Planst du auch die Unterstützung von PERL-Code in den CMD-userattr? Ein
{fhem("set bu_szene scene anwesend");}
funktioniert momentan bei mir nicht.
Ein attr hz_device widgetOverride hz_cmd_likely:textField-long
würde dann auch Sinn machen.
VG Sebastian
yep, beides auf dem Radar
ZitatBisher steckt da noch kein tieferer Sinn dahinter (ausser, dass das Modul unter bestimmten Umständen wissen muss, ob es timer-gesteuert aktualisiert wurde) aber da kommt sicher noch was.
Ja das dachte ich mir schon. Diente ja auch "nur" als Bug-Reporting ;)
Zitat von: binford6000 am 22 März 2019, 08:51:56
Was mir mit 0.0.8 aufgefallen ist:
Wenn ich ein set fl_zone occupied 10 mache und bereits ein Timer läuft, wird dieser mit dem manuellen Wert nur kurz überschrieben und läuft dann weiter:
2019-03-22 08:39:39 lastZone wz_zone
2019-03-22 08:39:39 occupied 50
[set fl_zone occupied 10]
2019-03-22 08:40:14 lastZone self
2019-03-22 08:40:14 occupied 10
2019-03-22 08:40:39 lastZone wz_zone
2019-03-22 08:40:39 occupied 30
Bug oder Feature?
lastZone ist jeweils das letzte meldende homezone-device?
VG Sebastian
Ich habe mir das nochmal angesehen - Kann es sein, Da überschreibt wz_zone die fl_zone - Ist wz ein Kind von fl oder adjacent? Dann wäre das Verhalten richtig...
ZitatIch habe mir das nochmal angesehen - Kann es sein, Da überschreibt wz_zone die fl_zone - Ist wz ein Kind von fl oder adjacent? Dann wäre das Verhalten richtig...
Bei wz_zone steht fl_zone als adjacent drin. Bei fl_zone ist kein adjacent gesetzt.
defmod fl_zone homezone
attr fl_zone userattr hz_cmd_absent hz_cmd_likely hz_cmd_present hz_cmd_unlikely hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_lumiThreshold_absent hz_lumiThreshold_likely hz_lumiThreshold_present hz_lumiThreshold_unlikely hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss
attr fl_zone devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
attr fl_zone hz_cmd_absent IF ([rr_Sebastian:state] eq "asleep") (set fl_szene scene abwesend)
attr fl_zone hz_cmd_likely IF ([rr_Sebastian:state] eq "asleep") (set fl_szene scene schlafen)
attr fl_zone hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr fl_zone hz_decay 300
attr fl_zone hz_occupancyEvent fl_bwm:motion
attr fl_zone hz_state 100:present 50:likely 1:unlikely 0:absent
attr fl_zone icon floordefmod wz_zone homezone
attr wz_zone userattr hz_cmd_absent hz_cmd_likely hz_cmd_present hz_cmd_unlikely hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_lumiThreshold_absent hz_lumiThreshold_likely hz_lumiThreshold_present hz_lumiThreshold_unlikely hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss
attr wz_zone devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
attr wz_zone hz_adjacent fl_zone
attr wz_zone hz_closedEvent PhilipsTV.PRE:present
attr wz_zone hz_cmd_absent IF ([rr_Sebastian:state] eq "asleep") (set wz_szene scene abwesend)
attr wz_zone hz_cmd_likely IF ([rr_Sebastian:state] eq "asleep") (set wz_szene scene schlafen)
attr wz_zone hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr wz_zone hz_decay 300
attr wz_zone hz_occupancyEvent wz_bwm:motion
attr wz_zone hz_openEvent PhilipsTV.PRE:absent
attr wz_zone hz_state 100:present 50:likely 1:unlikely 0:absent
attr wz_zone icon floorVG Sebastian
@Sebastian: Dann ist das ein Feature:
Zitat
Dadurch wird die Anwesenheitswahrscheinlichkeit der Toilette auf den Flur gespiegelt (sofern Flur > 0% und Toilette > Flur).
Neue Version (im ersten Post) erlaubt nun auch Perl in den hz_cmd.* Attributen. Um den "großen" Editor zu bekommen, müssen die userattr neu generiert werden (jeden state in hz_state einmal umbenamsen)
Moin,
beim Ausführen von PERL-Code bekomme ich Fehler im Log:
2019.03.23 10:19:44 1: [homezone - fl_zone]: Unknown command {
, try help.
Unknown command fhem("set, try help.
Unknown command }, try help. Die hz_cmd-Attribute unterstützen offenbar keine Tabs:
{
fhem("set fl_szene scene anwesend");
}
funktioniert nicht. Das hier dagegen schon:
{fhem("set fl_szene scene anwesend");}
VG Sebastian
Zitat von: binford6000 am 23 März 2019, 10:27:55
Die hz_cmd-Attribute unterstützen offenbar keine Tabs:
Danke für den Hinweis. Tatsächlich haben die cmds kein multiline perl unterstützt... Ist in 0.0.10 erledigt (s. erster Post)
Moin Oli,
ich möchte die homezone-interne Variable $name verwenden:
{
my $room = (split /_/,"$name")[0];
fhem("set ".$room."_szene scene abwesend");
}
Bekomme aber einen gängigen Fehler:
Global symbol "$name" requires explicit package name (did you forget to declare "my $name"?) at (eval 22338) line 2.
Klar könnte ich die auch deklarieren. Aber dann funktioniert der Code nicht...
Was mache ich falsch?
VG Sebastian
Nochmal ich:
Kann es sein dass mit V 0.0.11 sich der STATE nicht aktualisiert? :o
Ich setze occupied manuell auf 30 und löse den bwm aus. occupied geht dann korrekt auf 99 aber state und STATE bleiben auf unlikely....
Historie löschen
Internals:
DEF
FUUID 5c8bead4-f33f-0308-08a7-e01e244c7c0155f4
FVERSION 98_homezone.pm:v0.0.9-s18522/2019-02-07
NAME fl_zone
NR 401
NTFY_ORDER 50-fl_zone
STATE unlikely
TYPE homezone
VERSION 0.0.11
HELPER:
doors 0
READINGS:
2019-03-24 09:23:36 condition open
2019-03-24 10:08:57 lastDayTime day
2019-03-24 10:08:57 lastLumi 140
2019-03-24 10:08:57 lastZone self
2019-03-24 10:08:57 occupied 99
2019-03-24 10:04:12 state unlikely
helper:
TIMER 1553418567
Attributes:
devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 300
hz_decay_evening 601
hz_luminanceReading Wohnung:luminance
hz_occupancyEvent fl_bwm:motion
hz_state 100:present 50:likely 1:unlikely 0:absent
icon floor
userattr ...
Mit V 0.0.10 ist das in Ordnung.
Dort habe ich bemerkt dass die interne Version bei 0.0.9 bleibt obwohl das Modul bereits V 0.0.10 ausweist (Multiline Perl funzt...).
VG Sebastian
Hi Sebastian,
Den Fehler mit dem STATE hatte ich auch, dachte aber ich hätte ihn vor dem Hochladen behoben :-[ Ich checke das später mal (und schau mir $name an... da muss ich vermutlich irgendwie was mit übergeben)
Kurz, weil mobil
Zitat von: binford6000 am 24 März 2019, 10:16:31
Nochmal ich:
Kann es sein dass mit V 0.0.11 sich der STATE nicht aktualisiert? :o
Ich setze occupied manuell auf 30 und löse den bwm aus. occupied geht dann korrekt auf 99 aber state und STATE bleiben auf unlikely....
Kann ich bestätigen, habe mit der 0.0.11 (24.03.2019) auch keine Aktualisierungen mehr im STATE/state.
Sorry, das überraschend erfreuliche #NEDGER hat mir gestern die Zeit geraubt. Bei der bei mir laufenden Version funktioniert das Update des STATE wieder, dafür sind die CMDs buggy- das bekomme ich heute aber gefixt und dann gibt's eine neue Version.
Kurz, weil mobil
Da habe ich gleich noch eine Idee/Wunsch.
Ich habe mir ein homezone-Master-Gerät angelegt, welches den Gesamtstatus monitored. Funktioniert wunderbar, aber die Kirsche auf der Torte wäre noch ein Reading mit der homezone, die am wahrscheinlichsten ,,occupied" ist, sprich das homezone-Device mit der höchsten Prozentzahl.
Zitat von: ComputerZOO am 25 März 2019, 20:31:21
Da habe ich gleich noch eine Idee/Wunsch.
Ich habe mir ein homezone-Master-Gerät angelegt, welches den Gesamtstatus monitored. Funktioniert wunderbar, aber die Kirsche auf der Torte wäre noch ein Reading mit der homezone, die am wahrscheinlichsten ,,occupied" ist, sprich das homezone-Device mit der höchsten Prozentzahl.
Wie sieht das homezone-Master-Gerät denn aus?
VG Sebastian
Wenn der homezone-master alle anderen homezones als "Kind" hat, sollte im lastZone reading immer das mit dem höhsten Wert stehen... Wenn das ganze mehrstufig aufgebaut ist, wird's schwieriger... Ich denke mal nach, wie das elegant zu lösen wäre.
Zitat von: binford6000 am 25 März 2019, 21:03:18
Wie sieht das homezone-Master-Gerät denn aus?
VG Sebastian
Genauso, wie KernSani es beschrieben hat. in hz_children stehen alle anderen homezone-Devices drin.
Zitat von: KernSani am 25 März 2019, 21:24:11
Wenn der homezone-master alle anderen homezones als "Kind" hat, sollte im lastZone reading immer das mit dem höhsten Wert stehen... Wenn das ganze mehrstufig aufgebaut ist, wird's schwieriger... Ich denke mal nach, wie das elegant zu lösen wäre.
Stimmt, lastZone sollte wohl die Funktion haben, die ich gesucht habe.
Zitat von: ComputerZOO am 25 März 2019, 22:01:42
Stimmt, lastZone sollte wohl die Funktion haben, die ich gesucht habe.
Tja... zu spät - Es gibt ein neues Reading lastChild, das auch über mehrere Hierarchie-Ebenen funktioniert (bei mir hz_home hat hz_eg und hz_og, darunter hängen die eigentlichen hzs, hz_home seigt dann z.B. hz_eg_kueche an)
Zitat von: binford6000 am 24 März 2019, 09:52:51
ich möchte die homezone-interne Variable $name verwenden:
geht jetzt auch
und der bug mit dem STATE ist auch behoben (und Attribut hz_disableOnlyCmds funktioniert ordentlich)
Hallo,
nach zwei Tagen Test habe ich keine besonderen Vorkommnisse gehabt.
Dafür aber einen Feature-Request: Könnte man dem set inactive einen Parameter für die Zeit mitgeben?
set .*_zone inactive 300
Der Anwendungsfall besteht darin dass ich zB. während gotosleep/awoken keine Bewegungssteuerung haben möchte.
Ja es gibt das Attribut hz_disableOnlyCmds. Aber das ist dann imm er mit save verbunden und damit "unschön".
Nur so eine Idee. Ich könnte mir auch anders helfen ;)
VG Sebastian
Hi Sebastian,
könnte ich theoretisch einbauen, aber wäre es nicht geschickter das über Events zu lösen (also bei "gotosleep" auf inactive zu setzen und bei "asleep" wieder auf active)?
Grüße,
Oli
Zitatkönnte ich theoretisch einbauen, aber wäre es nicht geschickter das über Events zu lösen (also bei "gotosleep" auf inactive zu setzen und bei "asleep" wieder auf active)?
Wie gesagt, ich kann mir auch anders helfen. War nur ein Vorschlag...
VG Sebastian
Zitat von: binford6000 am 28 März 2019, 22:36:40
Wie gesagt, ich kann mir auch anders helfen. War nur ein Vorschlag...
VG Sebastian
ok, tut nicht weh :) Vorschlag angenommen (neue Version im ersten Post)
Moin Oli,
danke fürs Einbauen :)
Ich habe im Log seltsame Fehler:
2019.03.29 07:58:12 5: [homezone - fl_zone]: 60
2019.03.29 07:58:41 5: [homezone - fl_zone]: Luminance: 1521 Threshold: 0-9999999999
2019.03.29 07:58:41 5: [homezone - fl_zone]: Luminance: 1521 Threshold: 0-9999999999
2019.03.29 07:58:41 1: [homezone - fl_zone]: Command execution failed:
2019.03.29 07:58:41 1: [homezone - fl_zone]: Perl execution failed:
2019.03.29 07:58:41 5: [homezone - fl_zone]: 52019.03.29 07:59:12 5: [homezone - fl_zone]: Luminance: 1521 Threshold: 0-9999999999
2019.03.29 07:59:12 1: [homezone - wz_zone]: Command execution failed:
2019.03.29 07:59:12 1: [homezone - wz_zone]: Perl execution failed:
2019.03.29 07:59:12 1: [homezone - ku_zone]: Command execution failed:
2019.03.29 07:59:12 1: [homezone - ku_zone]: Perl execution failed:
2019.03.29 07:59:12 5: [homezone - fl_zone]: Luminance: 1521 Threshold: 0-9999999999
2019.03.29 07:59:12 5: [homezone - fl_zone]: Luminance: 1521 Threshold: 0-9999999999
2019.03.29 07:59:12 1: [homezone - fl_zone]: Command execution failed:
2019.03.29 07:59:12 5: [homezone - fl_zone]: 0
Der Perlcode wird immer korrekt ausgeführt, allerdings mit den Fehlermeldungen. Luminance-Threshold nutze ich nicht.
Hier mal ein device als Beispiel:
Historie löschen
Internals:
FUUID 5c8bead4-f33f-0308-08a7-e01e244c7c0155f4
FVERSION 98_homezone.pm:v0.0.13-s18522/2019-02-07
NAME fl_zone
NR 398
NTFY_ORDER 50-fl_zone
STATE absent
TYPE homezone
VERSION 0.0.13
HELPER:
doors 0
READINGS:
2019-03-24 09:23:36 condition open
2019-03-29 07:59:12 lastDayTime morning
2019-03-29 07:59:12 lastLumi 1521
2019-03-29 07:59:12 lastZone timer
2019-03-29 07:59:12 occupied 0
2019-03-29 07:59:12 state absent
helper:
TIMER 1553842751
Attributes:
devStateIcon inactive:ios-NACK present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
hz_cmd_absent {
my $room = (split /_/,"$name")[0];
fhem("set ".$room."_szene scene abwesend") if (Value($room."_AutoLight") eq "on");
}
hz_cmd_likely {
my $room = (split /_/,"$name")[0];
my $tv = ReadingsVal('PhilipsTV.PRE','presence','present');
my $mode = ReadingsVal('Wohnung','mode','');
my $luminance = ReadingsNum('Wohnung','luminance','100');
my $light = ReadingsNum('Daemmerung','light','6');
my $tw = ReadingsNum('Daemmerung','twilight_weather','100');
my $tgtlum = ReadingsNum('helligkeit.DUM','target_luminance','40');
my $tgttwi = ReadingsNum('helligkeit.DUM','target_twilight','5');
my $tgttwiw = ReadingsNum('helligkeit.DUM','target_twilight_weather','80');
my $fully = Value('fully');
my $fullybri = ReadingsVal('fully','brightness','255');
my $aeah = ReadingsVal('Wohnung','anyoneElseAtHome','0');
if ($mode !~ /sleep/ && $aeah eq "off" && $fully ne "on") {
fhem("set fully on");
fhem("sleep 2; set fully brightness 255") if ($tw >= 71 && $fullybri != 255);
fhem("sleep 2; set fully brightness 20") if ($tw <= 70 && $fullybri != 20);
fhem("defmod atTmp_Bewegungsmelder_Tablet_aus_$name at +00:03:00 set fully off");
}
if (($light <= $tgttwi || $tw <= $tgttwiw || $luminance <= $tgtlum) && Value($room."_AutoLight") eq "on") {
my $scene;
my $actscene = Value($room.'_szene');
if ("$mode" =~ /asleep|gotosleep/) {
$scene = "schlafen";
}
elsif ("$mode" !~ /asleep/ && $room eq "wz") {
$scene = "anwesend_alle" if ($tv eq "present");
$scene = "anwesend" if ($tv eq "absent");
}
elsif ("$mode" !~ /asleep/ && $room eq "sz") {
$scene = "anwesend" if (isInTime('09:00-16:59'));
$scene = "schlafen" if (isInTime('17:00-24:00 00:00-08:59'));
}
elsif ("$mode" !~ /asleep/ && $room =~ /fl|ka|ku|bu|bz|wc/) {
$scene = "anwesend";
}
fhem("set ".$room."_szene scene $scene") if ($actscene ne "$scene");
}
}
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 300
hz_decay_evening 600
hz_decay_night 100
hz_luminanceReading Wohnung:luminance
hz_occupancyEvent fl_bwm:motion
hz_state 100:present 50:likely 1:unlikely 0:absent
icon floor
userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss :textField-long :textField-long :textField-long :textField-long hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent
verbose 5
VG Sebastian
Hi Sebastian,
luminance wird immer ausgewertet, auch wenn das Attribut nicht gesetzt ist (also nichts was stören sollte). Die Meldung bez. Command execution bzw perl execution kannst du ebenfalls ignorieren, diese wird dummerweise auch bei "leerem" Fehler ausgegeben (komisch, dass mir das nicht vorher aufgefallen ist). Werde ich in der nächsten Version fixen.
Grüße,
Oli
Moin Oli,
Frage, wann geht der Status auf "closed"? Ich nutze nur Bewegungsmelder für "hz_occupancyEvent", sonst nichts. Trotzdem stehen die Zonen immer mal wieder auf "closed" und ich muss einmal "set open" stellen, damit wieder occupied runtergezählt wird. Kann das bei einem Neustart passieren? Ich habe noch nicht verstanden wann das gesetzt wird und vor allem, wie ich das verhindern kann.
Gruss
Enno
Zitat von: enno am 29 März 2019, 10:31:18
Moin Oli,
Frage, wann geht der Status auf "closed"? Ich nutze nur Bewegungsmelder für "hz_occupancyEvent", sonst nichts. Trotzdem stehen die Zonen immer mal wieder auf "closed" und ich muss einmal "set open" stellen, damit wieder occupied runtergezählt wird. Kann das bei einem Neustart passieren? Ich habe noch nicht verstanden wann das gesetzt wird und vor allem, wie ich das verhindern kann.
Gruss
Enno
Hi Enno,
eigentlich darf eine homezone nur auf "closed" gehen, wenn das closedEvent ausgelöst wird oder wenn manuell auf "closed" gesetzt wird. In einer früheren Version hatte ich beim "boxMode" auch auf closed gesetzt, das ist aber mittlerweile nicht mehr der Fall... Beim Neustart sollte da nichts passieren (habe ich auch noch nicht beobachtet. Falls du irgendeinen Anhaltspunkt findest nach dem ich suchen kann...
Grüße,
Oli
Zitat von: KernSani am 29 März 2019, 10:17:07
Hi Sebastian,
luminance wird immer ausgewertet, auch wenn das Attribut nicht gesetzt ist (also nichts was stören sollte). Die Meldung bez. Command execution bzw perl execution kannst du ebenfalls ignorieren, diese wird dummerweise auch bei "leerem" Fehler ausgegeben (komisch, dass mir das nicht vorher aufgefallen ist). Werde ich in der nächsten Version fixen.
Grüße,
Oli
Hi Oli,
nur kurz aber der Vollständigkeit halber: bei den Logeinträgen von
set .*_zone inactive 2400 fehlen die device-Namen. Und sie könnten m.M.n. auch nur mit V3 geloggt werden:
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400
2019.04.04 06:01:27 1: Timer: 2400Sonst läuft alles bestens. Ich habe meine Bewegungsmelder-Lichtautomatik jetzt komplett auf homezone umgezogen 8)
Nochmal ein fettes
DANKESCHÖN für deine Arbeit! :)
VG Sebastian
Holla,
puuuuhhh manchmal lohnt es sich die kompletten 7 Seiten durchzulesen und jedes noch so kleine Detail zu verfolgen. Damit lassen sich viele Kleinigkeiten schon im Vorfeld klären.
Alles was ich bisher hier gelesen habe, scheint so ziemlich meinen Wünschen zu entsprechen, die ich demnächst gerne umsetzen möchte .... Ob es wirklich klappt, hängt in erster Linie an der Umsetzung der Hardwareanbindung. Aber auch in Mangel an Testumgebung schon mal bis dahin.
Zitat von: binford6000 am 04 April 2019, 13:27:08
Nochmal ein fettes DANKESCHÖN für deine Arbeit! :)
VG Sebastian
natürlich in erster Linie KernSani (Olli) und auch an alle anderen Testern, aber vor allem auch Dir
Sebastian.
Ich glaube (ohne wirklich zu wissen, wer sich sonst noch wie gemeldet hat) warst Du da für Olli wohl der Haupttester bis hierhin. Ich hoffe auch irgendwie noch n bissl was zur Entwicklung beitragen zu können, aber das wird noch ein wenig dauern, bis die entsprechende Hardware da und einsatzfähig ist.
Viele Grüße und nochmals Danke für Eure bisherige Arbeit :)
Andreas
Hallo,
nach kanpp zwei Monaten im Produktiveinsatz läuft alles soweit gut. Ein Anmerkung/Frage habe ich noch:
Ich musste mir für zwei Zonen jeweils ein notify bauen, welches ein hz_cmd_present immer dann ausführt,
wenn auch das entsprechende hz_closedEvent ausgelöst wird. Und nicht nur einmalig.
Habe ich da was übersehen oder ist das Verhalten so gewollt?
VG Sebastian
Hallo zusammen,
habe die Zonen zusammen mit Xiaomi Sensoren schon seit einiger Zeit erfolgreich im Einsatz, und habe jetzt versucht eine per ESP_Easy aufgebaute Anwesenheitserkennung für ein Bett umzusetzen.
Per ESP_Easy wird ein Ultraschall Abstandssensor ausgelesen, per mqtt kommt entweder 1 wenn der Abstand Boden <> Lattenrost kleiner 18 cm, ansonsten 0
Damit lässt sich ziemlich zuverlässig erkennen ob gerade jemand im Bett liegt oder nicht.
der Sensor ist als presence_bett_patrick in fhem eingebunden und zeigt dort entweder true oder false
Die Tür zum Schlafzimmer hat einen Xiaomi Türkontakt (tk_schlafzimmer) welcher entweder close oder open meldet.
Für Testzwecke sendet presence_bett_patrick momentan jede Sekunde einmal den Status.
Jetzt wollte ich das ganze mit homezone vernünftig verpacken, aber leider komme ich hier nicht weiter.
Hier mal ein list wie ich das ganze angelegt habe:
Internals:
CFGFN
FUUID 5cfe37ce-f33f-3d24-f0a1-a8b5a68ada38036c
NAME bett_patrick
NR 19220
NTFY_ORDER 50-bett_patrick
STATE present
TYPE homezone
VERSION 0.0.12
HELPER:
doors 1
READINGS:
2019-06-10 13:37:38 condition closed
2019-06-10 13:48:34 lastDayTime day
2019-06-10 13:48:34 lastZone self
2019-06-10 13:48:34 occupied 100
2019-06-10 13:48:34 state present
helper:
TIMER 1560166653
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_absenceEvent presence_bett_patrick:presence:.*false
hz_closedEvent tk_schlafzimmer:contact:.*close
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 10
hz_occupancyEvent presence_bett_patrick:presence:.*true
hz_openEvent tk_schlafzimmer:contact:.*open
hz_state 100:present 50:likely 1:unlikely 0:absent
room Schlafzimmer
userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
Das Problem ist jetzt, das sobald ich die Tür schließe die Zone sofort auf Present springt, egal ob presence_bett_patrick true oder false ist
Hallo zusammen,
hat zufällig jemand von Euch mal die Verbindung von ein paar Räumen, sonsoren etc. grafisch dargestellt?
Ich würde mir gern erst mal ein "Design" überlegen wollen, wie ich die Räume und Sensoren strukturieren, bevor ich alles einhacke.
Momentan ist mir das noch etwas Theoretisch.
Wir das Modul eigentlich bald offiziell eingechecked?
Sebastian
Zitat von: slor am 14 Juni 2019, 23:38:47
Hallo zusammen,
hat zufällig jemand von Euch mal die Verbindung von ein paar Räumen, sonsoren etc. grafisch dargestellt?
Ich würde mir gern erst mal ein "Design" überlegen wollen, wie ich die Räume und Sensoren strukturieren, bevor ich alles einhacke.
Momentan ist mir das noch etwas Theoretisch.
Wir das Modul eigentlich bald offiziell eingechecked?
Sebastian
Hallo Sebastian,
das bringt m.M.n. nicht so viel... Leg dir lieber 1-3 Räume als homezone-Device an und schau was passiert. ;)
Als Hierarchie kann sowas dienen: Wohnung -> Etagen -> Räume
Ansonsten ist die Beschreibung im ersten Post von Oli ganz gut. Ich lese dort auch immer nochmal was nach. 8)
VG Sebastian
Hallo,
habe seit 3 Tagen Probleme
2019.09.02 12:42:59.981 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1892.
2019.09.02 12:42:59.982 1: PERL WARNING: Deep recursion on subroutine "main::homezone_setOcc" at ./FHEM/98_homezone.pm line 427.
2019.09.02 12:42:59.982 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_homezone.pm line 330.
2019.09.02 12:42:59.982 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1091.
2019.09.02 12:42:59.982 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at fhem.pl line 1238.
2019.09.02 12:42:59.982 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1924.
2019.09.02 12:42:59.982 1: PERL WARNING: Deep recursion on subroutine "main::homezone_Set" at fhem.pl line 3747.
danach stürzt Fhem ab und ich muss neu starten.
Ich vermute es liegt an einem hz_occupancyEvent weil ich da einige verändert hatte, konnte aber noch nicht identifizieren welche Zone es ist. Oder habe ich einen Bug gefunden?
Jemand einen Tip?
Gruß
Eisix
Hallo Zusammen,
ich finde die Idee hinter dem Modul gut und habe sie bei mir auch eingebunden.
Ich habe verschiedene Zonen definiert und auch einen
hz_occupancyEvent Beweg_WZ:state:motion"
dazu.
Wenn der Bewegungsmelder auslöst müsste sich da nicht der State der Zone ändern habe habe ich die Funktion des Moduls falsch verstanden?
Hier die Def. der Zone:
Internals:
FUUID 5d6d758f-f33f-45a3-0a2b-9522db28c51d2a45
NAME HZ_WZ
NR 1437
NTFY_ORDER 50-HZ_WZ
STATE absent
TYPE homezone
VERSION 0.0.13
HELPER:
doors 0
READINGS:
2019-09-02 22:57:28 condition open
2019-09-02 23:13:32 lastDayTime night
2019-09-02 23:13:32 lastZone self
2019-09-02 23:13:32 state absent
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
group HZ_Räume
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 120
hz_occupancyEvent Beweg_WZ:state:motion
hz_state 100:present 50:likely 1:unlikely 0:absent
room System
userattr hz_cmd_present:textField-long hz_lumiThreshold_present :textField-long :textField-long :textField-long hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent
Grüße Dorian
Hallo Dorian,
das Event entnimmst du am besten aus dem Eventmonitor. Meine HUE-bwms reagieren auf
hz_occupancyEvent fl_bwm:motion
Hier mal eine Zone von mir.
Internals:
FUUID 5c8bead4-f33f-0308-08a7-e01e244c7c0155f4
FVERSION 98_homezone.pm:v0.0.13-s18522/2019-02-07
NAME fl_zone
NR 279
NTFY_ORDER 50-fl_zone
STATE absent
TYPE homezone
VERSION 0.0.13
HELPER:
doors 0
READINGS:
2019-03-24 09:23:36 condition open
2019-09-06 19:45:33 lastDayTime evening
2019-09-06 19:45:33 lastLumi 16
2019-09-06 19:45:33 lastZone timer
2019-09-06 19:45:33 lux 16
2019-09-06 19:45:33 occupied 0
2019-09-06 19:45:33 state absent
2019-08-20 10:58:22 targetlux 40
helper:
TIMER 1567791933
Attributes:
cmdIcon occupied0:radio_checked@red
devStateIcon inactive:ios-NACK present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
eventMap /occupied 0:occupied0/
group Homezone
hz_absenceEvent Wohnung:presence:.absent
hz_cmd_absent set fl_szene:FILTER=scene!=abwesend scene abwesend;
set fully:FILTER=STATE!=off off;
hz_cmd_likely IF ([Wohnung] eq "asleep" && [fl_zone:lux] <= [fl_zone:targetlux]) (set fl_szene:FILTER=scene!=schlafen scene schlafen);
IF ([Wohnung] ne "asleep" && [fl_zone:lux] <= [fl_zone:targetlux]) (set fl_szene:FILTER=scene!=anwesend scene anwesend);
IF ([Wohnung] ne "asleep") (set fully:FILTER=STATE!=on on-for-timer 180);
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 300
hz_decay_evening 600
hz_decay_night 120
hz_luminanceReading fl_huesens_light:lux
hz_occupancyEvent fl_bwm:motion
hz_state 100:present 50:likely 1:unlikely 0:absent
icon floor
room 50_Zonen
userReadings lux {ReadingsNum('fl_huesens_light','lux',50);;},
targetlux
userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss :textField-long :textField-long :textField-long :textField-long hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent
webCmd occupied0
VG Sebastian
Guten Morgen,
@Eisix besteht dein Problem immer?
Ich habe seit ca. 1,5 Wochen das selbe Problem. Der Absturz von FHEM folgt dann aus einer OOM Aktion. Ich habe das in meinem System soweit debugt, das das Szenario sich aufbaut bis das System aufgibt. Heißt bis zum Absturz können Sekunden oder aber mehrere Minuten vergehen.
Trotz der aktuellen Möglichkeiten apptime / fhemdebug, könnte ich noch nicht eingrenzen, ob Homezone direkt oder das Zusammenspiel mit Konf oder anderen Modulen der Auslöser ist.
Ich werde Homezone leider deaktivieren müssen, da mein aktueller Mem Watchdog mit restart, keine akzeptable Lösung ist.
Wenn jemand noch Anregungen hat, gern
Danke Sebastian
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1892.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::apptime_getTiming" at ./FHEM/98_apptime.pm line 138.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_setOcc" at ./FHEM/98_homezone.pm line 427.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_homezone.pm line 330.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1091.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at fhem.pl line 1238.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1924.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_Set" at ./FHEM/98_apptime.pm line 178.
Out of memory!
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1892.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::apptime_getTiming" at ./FHEM/98_apptime.pm line 138.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_setOcc" at ./FHEM/98_homezone.pm line 427.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_homezone.pm line 330.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1091.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at fhem.pl line 1238.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1924.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_Set" at ./FHEM/98_apptime.pm line 178.Hmm das deutet doch auf eine Schleife hin... :o
ZitatIch vermute es liegt an einem hz_occupancyEvent weil ich da einige verändert hatte, konnte aber noch nicht identifizieren welche Zone es ist. Oder habe ich einen Bug gefunden?
Du kannst doch mal alle Zonen auf inactive setzen und dann eine nach der anderen wieder aktivieren und schauen wann der Fehler auftritt.
Dann hast du zumindest schon mal die Zone und kannst dann weiter debuggen (hz_occupancyEvent...) ;)
VG Sebastian
Danke, Probier ich nachher ;) mal aus.
Hallo,
Es liegt bei mir am hz_occupancyEvent. Ich hatte vorher zwei Zonen verändert. Nachdem ich beide wieder entfernt habe ist alles wieder stabil. Zu weiteren Nachforschungen kam ich noch nicht.
Gruß
Eisix
Hallo, ich hatte zwei Zonen mal gegenseitig mit dem Attribut hz_children ausgestattet. Danach hatte ich auch Fhem Absturz und Einträge im Log wie "Deep recursion on subroutine "main::homezone_Set". Nach dem Entfernen des Attributs in einer der Zonen läuft das wieder stabil!
Danke für die zusätzlichen Erfahrungen. Ich teste gerade Zone für Zone. Fakt ist leider das 48h ohne aktive Zone keinen Absturz provoziert haben, so dass ich die Fehlersuche auf diesen Bereich einschränken kann. Aber die von euch beschriebenen DeadLocks leuchten mir ein.
Hallo,
ich habe meine Suche jetzt auf meine beiden Flure eingrenzen können. Wahrscheinlich hängt es mit der Art und Weise wie ich adjacent einsetze zusammen. Abhilfe scheint boxMode zu bringen. Da ich nichts weiterführendes finde und die .pm Aalyse nicht final Aufschluss gegeben hat, kann mir bitte jemand noch mal die beiden Attribut Multidoor und boxMode erläutern.
Ich muss intensiv mit den closed Evens arbeiten, da meine Aqara Sensoren mit Conbee nur alle 60min auf Erfassung schalten. Das muss ich kompensieren. Denn ohne closed löst die Zone sofort bei nomotion aus und ich tanze leider nicht permanent vor den Teilen .. also Nachlaufzeit (der Timer schluckt das in einer einfachen Konf leider nicht).
Danke euch
Moin,
ich habe leider keine Türsensoren - kann dir leider nicht direkt helfen. ABER:
- Die ZigBee Sensoren generieren doch EVENTS - unabhängig vom Aktualisierungsintervall...
- Schau dir die Events im Eventmonitor an und trage sie im jeweiligen Attribut ein.
Damit sollten die jeweiligen CMDs via Attribut auch greifen. Ich habe closed/open Events im Wohnzimmer von der Anwesenheit des TVs eingestellt.
Mit dem passenden Event läuft das alles wie gewünscht.
Adjacent und Boxmode habe ich nicht im Betrieb. Da kann ich dir leider gar nichts zu sagen...
VG Sebastian
Zitat von: KernSani am 15 März 2019, 19:06:04
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.
Im ersten Beitrag schreibst du das die DayTimes aus dem HOMEMODE-Device übernommen werden falls eins angelegt ist. Bei mir ist das nicht der Fall.
Daytimes aus Homemode
00:00|Mitternacht 03:00|Nacht 06:00|Morgen 08:00|Vormittag 13:00|Mittagsruhe 15:00|Nachmittag 18:30|Abend 23:00|SpätabendDayTimes in homezone
05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|nightWoran kann das liegen?
Ich finde das Konzept super. Vielen Dank für das Modul.
Ich verstehe aber noch nicht wie ich es verwenden muss. Ich wollte es gestern mit meinem Gästeklo versuchen.
Internals:
CFGFN
FUUID 5dfa876d-f33f-7452-4442-7fa8cdf93d7e3870
NAME KLO_Zone
NR 32172
NTFY_ORDER 50-KLO_Zone
STATE present
TYPE homezone
VERSION 0.0.13
HELPER:
doors 1
READINGS:
2019-12-18 21:22:35 condition closed
2019-12-18 21:23:34 lastDayTime evening
2019-12-18 21:23:34 lastZone self
2019-12-18 21:23:34 occupied 100
2019-12-18 21:23:34 state present
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_closedEvent KLO_Tuer:closed
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_occupancyEvent KLO.Motion:motion
hz_openEvent KLO_Tuer:open
hz_state 100:present 50:likely 1:unlikely 0:absent
room Gästeklo
userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
Wenn nun jemand kurz die Tür aufmacht passiert im Eventmonitor folgendes (nicht beteiligte Devices habe ich entfernt):
2019-12-18 21:22:30 CUL_HM KLO_Tuer battery: ok
2019-12-18 21:22:30 CUL_HM KLO_Tuer contact: open (to VCCU)
2019-12-18 21:22:30 CUL_HM KLO_Tuer open
2019-12-18 21:22:30 CUL_HM KLO_Tuer trigger_cnt: 111
2019-12-18 21:22:32 homezone KLO_Zone occupied: 99
2019-12-18 21:22:32 homezone KLO_Zone likely
2019-12-18 21:22:32 homezone KLO_Zone lastZone: self
2019-12-18 21:22:32 homezone KLO_Zone occupied: 99
2019-12-18 21:22:32 homezone KLO_Zone likely
2019-12-18 21:22:32 homezone KLO_Zone lastZone: self
2019-12-18 21:22:32 homezone KLO_Zone occupied: 99
2019-12-18 21:22:32 homezone KLO_Zone likely
2019-12-18 21:22:32 homezone KLO_Zone lastZone: self
2019-12-18 21:22:32 CUL_HM KLO.Motion battery: ok
2019-12-18 21:22:32 CUL_HM KLO.Motion brightness: 33
2019-12-18 21:22:32 CUL_HM KLO.Motion motion: on (to VCCU)
2019-12-18 21:22:32 CUL_HM KLO.Motion motionCount: 35_next:60s
2019-12-18 21:22:32 CUL_HM KLO.Motion motion
2019-12-18 21:22:32 CUL_HM KLO.Motion trigger_cnt: 35
2019-12-18 21:22:35 homezone KLO_Zone condition: closed
2019-12-18 21:22:35 homezone KLO_Zone condition: closed
2019-12-18 21:22:35 CUL_HM KLO_Tuer battery: ok
2019-12-18 21:22:35 CUL_HM KLO_Tuer contact: closed (to VCCU)
2019-12-18 21:22:35 CUL_HM KLO_Tuer closed
2019-12-18 21:22:35 CUL_HM KLO_Tuer trigger_cnt: 112
2019-12-18 21:23:34 homezone KLO_Zone occupied: 100
2019-12-18 21:23:34 homezone KLO_Zone present
2019-12-18 21:23:34 homezone KLO_Zone lastZone: self
2019-12-18 21:23:34 homezone KLO_Zone occupied: 100
2019-12-18 21:23:34 homezone KLO_Zone present
2019-12-18 21:23:34 homezone KLO_Zone lastZone: self
2019-12-18 21:23:34 CUL_HM KLO.Motion motion: off
2019-12-18 21:23:34 CUL_HM KLO.Motion motionDuration: 62
2019-12-18 21:23:34 CUL_HM KLO.Motion noMotion
Somit ist die Wahrscheinlichkeit auf 100 und bleibt auch da obwohl niemand im Raum ist.
Muss ich die Regex beim hz_occupancyEvent anpassen? Hat das Modul jetzt motion:off verwendet?
Hallo,
da fehlt noch was:
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)
Gruß
Eisix
Ok Danke. Teste ich.
Ich dachte es würde einen default Wert geben. Außerdem habe ich das Attribut nicht verstanden. Für mich wäre das die Zeit die vergehen soll bis die Anwesenheits-Wahrscheinlichkeit auf null runter fällt.
Kannst du mir das Attribut genauer erklären?
Allerdings sehe ich das Problem in meinem Fall eher darin, dass homezone in einem verschlossenen Raum ohne eine Bewegung von 99 auf 100 springt. Das sollte so wie ich die Beschreibung verstanden habe nur passieren wenn eine Bewegung im verschlossenen Raum erkannt wird.
Vielen Dank
Hallo,
mein Verständnis von dem Attribut ist identisch mit deinem.
Hier mal ein list unserer Küche.
NAME zKueche
NR 484
NTFY_ORDER 50-zKueche
STATE absent
TYPE homezone
VERSION 0.0.13
HELPER:
doors 0
READINGS:
2019-12-19 16:58:28 lastDayTime afternoon
2019-12-19 16:58:28 lastZone timer
2019-12-19 16:58:28 occupied 0
2019-12-19 16:58:28 state absent
helper:
TIMER 1576771108
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_adjacent zFlur_EG,zWZ
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 120
hz_occupancyEvent Sensor_KUECHE:motion:.open
hz_state 100:present 50:likely 1:unlikely 0:absent
room HOMEMODE
userattr hz_cmd_present hz_lumiThreshold_present hz_cmd_likely hz_lumiThreshold_likely hz_cmd_unlikely hz_lumiThreshold_unlikely hz_cmd_absent hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
Warum der Wert bei dir von 99 auf 100 springt kann ich auch nicht erklären.
Gruß
Eisix
Hallo,
ich hatte das gleiche Problem und habe es so gelöst:
hz_occupancyEvent deCONZ_BM_AQ_05:[^no]motion
Probier doch mal aus, ob ein "nomotion-Event" deine Zone in Abwesenheit triggert.
Gruß
Reinschki
Danke Reinschki,
im Eventmonitor Auszug oben habe ich um 21:23:34 zwei Events die das Wort motion enthalten. Eigentlich können nur dieser das springen auf 100 auslösen. Sonst ist ja nichts los.
Das Komische ist das das homezone im evenmonitor auf 100 springt bevor das "motion"event auftaucht.
Kann es dein sein dass homezone den Event verarbeitet bevor er im Eventmonitor auftaucht?
Hi Willib,
man kann sich nicht unbedingt auf die Reihenfolge im Event-Monitor verlassen. Tatsächlich springt HZ vermutlich auf 100, weil es auf sas "motion" event anspringt. Versuche doch mal "motion:.on" als occupancy event (oder wie heißt das echte Event, bei Bewegung?)
Grüße,
Oli
Vielen Dank. Ich habe es mit einem Event on Update reading state am Bewegungsmelder gelöst. Hätte nie gedacht dass die Reihenfolge im Eventmonitor nicht stimmt.
Ich kann im webfrontend am Device occupied auf beliebige Werte setzen. Was ich eintrage ist aber egal. Das Device springt immer auf 100. Ich denke das ist ein Bug.
Kannst du mal ein list des devices machen? Sollte eigentlich nicht so sein (und ist bei mir auch nicht so)
Kurz, weil mobil
Internals:
CFGFN
FUUID 5dfa876d-f33f-7452-4442-7fa8cdf93d7e3870
NAME KLO_Zone
NR 32172
NTFY_ORDER 50-KLO_Zone
STATE absent
TYPE homezone
VERSION 0.0.13
HELPER:
doors 1
READINGS:
2020-01-01 20:03:29 condition closed
2020-01-01 20:08:26 lastDayTime evening
2020-01-01 20:08:26 lastZone timer
2020-01-01 20:08:26 occupied 0
2020-01-01 20:08:26 state absent
helper:
TIMER 1577905706
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_closedEvent KLO_Tuer:closed
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 300
hz_occupancyEvent KLO.Motion:motion,KLO_Tuer:open
hz_openEvent KLO_Tuer:open
hz_state 100:present 50:likely 1:unlikely 0:absent
room Gästeklo
userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
Dankeschön
Ich habe nochmal geschaut, occupied springt immer auf 100 wenn die Zone geschlossen ist und ich versuche den Wert manuell zu ändern. Wenn die Zone offen ist kann ich beliebige werte setzen.
Zitat von: willib am 03 Januar 2020, 10:51:10
Ich habe nochmal geschaut, occupied springt immer auf 100 wenn die Zone geschlossen ist und ich versuche den Wert manuell zu ändern. Wenn die Zone offen ist kann ich beliebige werte setzen.
Gutes Neues und sorry, dass ich mich nicht gemeldet habe, mein neues Projekt (Nintendo Switch in FHEM) hat mich etwas beschäftigt ;-) Im Grunde ist das ein erwartetes Verhalten (wenn auch nicht unbedingt ein gewolltes). Grundsätzlich ist es ja so, dass in einem geschlossenem Raum die Anwesenheit auf 100% geht, wenn dort "occupancy" festgestellt wird und implizit bedeutet eine Anwesenheit von 30 ja "occupancy", also springt er auf 100. Hast du denn einen konkreten Anwendungsfall, wo du manuell etwas in einer geschlossenen Zone setzen willst, dann kann ich da mal noch etwas dazu basteln...
Danke für das Angebot.
Ich habe aktuell keinen konkreten Anwendungsfall. War mir nur beim testen aufgefallen. Wenn ich Probleme damit haben sollte melde ich mich wieder.
Cooles Modul! Auf sowas war ich schon lange auf der Suche.
Ich habe jetzt als Test-Raum unser Badezimmer mit einem Bewegungsmelder, einem Türkontakt und einem Fensterkontakt eingebunden.
Grundsätzlich funktioniert es, wie es soll; allerdings gibt es ein Szenario das aktuell einen falschen Status erzeugt: Man geht ins Bad und öffnet das Fenster, geht dann ohne zu warten wieder raus und schliesst hinter sich die Tür. Der Raum ist dann "closed" und state auf "present". Das Licht bleibt also so lange an, bis man die Türe mal öffnet :)
Hat von euch einer eine Idee, wie man das lösen könnte?
Kannst du mal ein list des devices posten? Eigentlich darf er den Raum ja nicht auf 100% setzen, solange die Tür offen ist...
Gesendet von iPhone mit Tapatalk
Hi,
defmod zn_1OG_Bad homezone
attr zn_1OG_Bad userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
attr zn_1OG_Bad devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
attr zn_1OG_Bad hz_cmd_absent set 1OG_Bad_Deckenlicht off
attr zn_1OG_Bad hz_cmd_likely set 1OG_Bad_Deckenlicht on
attr zn_1OG_Bad hz_cmd_present set 1OG_Bad_Deckenlicht on
attr zn_1OG_Bad hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr zn_1OG_Bad hz_decay 120
attr zn_1OG_Bad hz_lumiThreshold 0:170
attr zn_1OG_Bad hz_lumiThreshold_absent 0:
attr zn_1OG_Bad hz_luminanceReading EG_PIR_Einfahrt:brightness
attr zn_1OG_Bad hz_occupancyEvent 1OG_Bad_Bewegungsmelder:state:.motion,1OG_TF_Bad:state:(.open)|(.closed)
attr zn_1OG_Bad hz_state 100:present 50:likely 1:unlikely 0:absent
attr zn_1OG_Bad hz_closedEvent 1OG_TF_Bad_Tuer:state:.closed
attr zn_1OG_Bad hz_openEvent 1OG_TF_Bad_Tuer:state:.open
Bewegungsmelder ist ein IKEA Tradfri, der nicht wirklich oft eine erkannte Bewegung als Event auslöst.
Der Ablauf ist schon richtig, das Modul verhält sich so wie er konfiguriert wurde, imho:
- Tür auf -> Raum offen
- man geht rein; PIR löst aus -> Status auf 99%
- man geht wieder raus und macht hinter sich die Tür zu -> Raum closed, 100%
Ich sehe aber dann keine Möglichkeit, das sinnvoller zu realisieren, ausser mit einem Bewegungsmelder im Flur. Das klappt aber auch nur bei einem 1-Personen-Haushalt.
Also doch nen Sensor an die Klobrille :P
Zitat von: shaddi am 14 April 2020, 14:47:15
- man geht wieder raus und macht hinter sich die Tür zu -> Raum closed, 100%
Eigentlich sollte der Ablauf ja sein:
- Tür zu -> Bewegung erkannt -> 100% --> Tür auf --> 99%
Ich stelle das heute Abend mal nach...
Huj, jetzt warst du fix. Hatte noch zwei Attrs in meinem listing vergessen, weil ohne diese mal probiert hatte. Post editiert...
Aber ja, das System weiss ja nicht, ob ich bei zu machen der Tür drin bin, oder nicht. Da innen der Bewegungsmelder ausgelöst hat, bin ich eher "drin"
Wird das Modul noch weiterentwickelt?
Ich will mich gerne reinstürzen, habe aber noch ein paar Probleme damit.
Irgendwie scheint der Gerätestatus gelegentlich einzufrieren. Nur Neustarts (oder war es sogar die Neuanlage) hatte es behoben.
Hast du noch eine neue Version bei dir rumliegen? 😄
Hi,
tatsächlich habe ich mir kürzlich überlegt, ob ich das Modul mal SVN-ready machen und einchecken soll. Mit anderen Worten: Wenn es Bedarf gibt wird es weiter entwickelt. Kannst du ein bisschen genauer erläutern, was bei dir nicht funktioniert, dann schaue ich mir das mal an...
Kurz, weil mobil....
Ich fange mal ganz vorne an, weil ich scheinbar noch ein Verständnisproblem habe.
Mein Anliegen ist es mit homezone:
- Lampe an, wenn dunkel und anwesend
- Lampe an, wenn dunkel und abwesend und Bewegung erkannt
- Lampe anbleiben, wenn Taster gedrückt wurde
Ich habe aktuell folgende Versuchszeilen:
defmod homezone_diele homezone
attr homezone_diele userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
attr homezone_diele cmdIcon closed:radio_checked@blue occupied100:rc_dot@blue open:radio_checked@lightgreen occupied0:rc_dot@red
attr homezone_diele devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
attr homezone_diele hz_absenceEvent rgr_Residents:presence:.absent
attr homezone_diele hz_cmd_absent set diele_lampe off
attr homezone_diele hz_cmd_likely set diele_lampe on
attr homezone_diele hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr homezone_diele hz_decay 300
attr homezone_diele hz_lumiThreshold_likely 0:30000
attr homezone_diele hz_luminanceReading lightsensor:lightlevel
attr homezone_diele hz_occupancyEvent rgr_Residents:presence:.present,pir_diele:motion:.on
attr homezone_diele hz_state 100:present 50:likely 1:unlikely 0:absent
Ich vermute aber mal, dass ich rgr_Residents nicht für absence/occupance nutzen darf, sondern eher als Close-Argument, oder?
Kann man mit eine Einschaltung über einen Taster das Ganze irgendwie übersteuern?
Danke.
Sorry, komme erst jetzt dazu zu antworten.
Grundsätzlich ist das Ziel von Homezone NICHT das Schalten von Lampen (dass das geht ist quasi ein Abfallprodukt). Das eigentliche Ziel von Homezone ist es Anwesenheit in einem Raum (oder allgemeiner einer Zone) zu erkennen. Sowas wie "Lampe anbleiben, wenn Taster gedrückt wurde" ist also in Homezone generell nicht vorgesehen. Auch PRESENCE eignet sich nicht unbedingt als Trigger (höchstens in einem 1-Personen-Haushalt), da PRESENCE ja in der Regel die An-/Abwesenheit eines bestimmten Gerätes in einem Haushalt beschreibt.
Die von dir beschriebenen Fälle wirken mir alle nicht so, als würden sie in das o.g. Schema passen (ausser vielleicht der Teil "Bewegung erkannt").
Zitat von: KernSani am 13 Mai 2020, 07:12:32
Hi,
tatsächlich habe ich mir kürzlich überlegt, ob ich das Modul mal SVN-ready machen und einchecken soll.
Würde ich gut finden, dann bekommt man es leichter auf sein system ohne hin und her zu kopieren. oder via Github und "update add"
So, ich hab das mal manuell eingebunden...
Ich habe einen Raum, bei dem ich beim Betreten via Bewegungsmelder das Licht einschalte und nach Abwesenheit wieder aus. Das funktioniert soweit auch zuverlässig.
Mir ist aufgefallen, dass das DoIf, das ich vorher dafür genutzt hatte wesentlich schneller war. Gefühlt habe ich jetzt 500ms Verzögerung. Das ist schon auffällig. Kann man an der Performance des Moduls noch etwas drehen? Oder ist Doif komplett anders aufgebaut und daher schneller?
Eigentlich dürfte performancemäßig kein spürbarer Unterschied zu einem DOIF bestehen. Kannst du andere Effekte (Bewegungsmelder anders positioniert o.ä.) ausschließen?
Kurz, weil mobil....
Der hm Präsenz Melder ist fest verbaut.
Ich habe nur das doif deaktiviert.
Dafür die Homezone eingerichtet.
Ich habe heute noch mal ein wenig geforscht, Fhem Update gemacht und Fhhm neu gestartet.
Das Delay ist nun geringer und kaum noch wahrnehmbar.
Keine Ahnung wo es dran lag. Der Weg ist: Melder - CCU - Fhem - Conbee - Lampe (Conbee steckt im Fhem Rechner)
Ich beobachte das mal weiter.
Hallo Oli,
ich teste gerade mit dem Box-Mode, da ich keine Türkontakte für die present-Erkennung habe.
Mir ist da was merkwürdiges aufgefallen:
Gegeben ist der Flur mit BWM und das Gästeklo mit BWM (beide HUE Motion). Die Gästeklo-Zone ist im Boxmode, die Flur-Zone nicht.
Gästeklo-Zone mit hz_adjacent fl_zone.
Jetzt gehe ich ins Gästeklo:
- Die Gästeklo-Zone geht sofort auf present. OK.
- Aber dann geht die Gästeklo-Zone auf likely, wenn der Flur-BWM auf nomotion wechselt!
- Geht der Gästeklo-BWM auf nomotion, geht die Gästeklo-Zone brav wieder in present.
Warum wird denn auf nomotion in der angrenzenden Zone getriggert und damit die box-Zone wieder auf likely geschaltet?
In Summe funktioniert das zwar auch, aber es wird unschön (und mMn. unnötig) zwischen present und likely gewechselt.
Ist das so gewollt? Mir erschließt sich der Grund jedenfalls nicht...
Bei mir aüßert sich das konkret darin dass wenn ich das Licht im Gästeklo manuell ausschalte, wird es durch das unnötige
erneute wechseln in present wieder eingeschaltet.
Falls du noch weitere Infos brauchst melde dich! Hier mal die beiden Zonen:
Flur:
defmod fl_zone homezone
attr fl_zone userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss :textField-long :textField-long :textField-long :textField-long hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent
attr fl_zone hz_absenceEvent Wohnung:presence:.absent
attr fl_zone hz_cmd_absent setscene fl.hgr abwesend;;\
set fully:FILTER=STATE!=off off;;
attr fl_zone hz_cmd_likely IF ([Wohnung] eq "asleep") (setscene fl.hgr schlafen);;\
IF ([Wohnung] ne "asleep" && [fl_zone:lux] <= [fl_zone:targetlux] && [Daemmerung:light] <= 5) (setscene fl.hgr abend);;\
IF ([Wohnung] ne "asleep" && [fl_zone:lux] <= [fl_zone:targetlux] && [Daemmerung:light] > 5) (setscene fl.hgr tag);;\
IF ([Wohnung] ne "asleep") (set fully:FILTER=STATE!=on on-for-timer 180);;
attr fl_zone hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr fl_zone hz_decay 300
attr fl_zone hz_decay_evening 600
attr fl_zone hz_decay_night 90
attr fl_zone hz_luminanceReading fl_huesens_light:lux
attr fl_zone hz_occupancyEvent fl_bwm:motion
attr fl_zone hz_state 100:present 50:likely 1:unlikely 0:absent
attr fl_zone userReadings lux {ReadingsNum('fl_huesens_light','lux',50);;;;},\
targetlux
Gästeklo:
defmod wc_zone homezone
attr wc_zone userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss :textField-long :textField-long :textField-long :textField-long hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent
attr wc_zone hz_absenceEvent Wohnung:presence:.absent
attr wc_zone hz_adjacent fl_zone
attr wc_zone hz_boxMode 1
attr wc_zone hz_cmd_absent setscene wc.hgr abwesend
attr wc_zone hz_cmd_present IF ([Wohnung] =~ /sleep/) (setscene wc.hgr schlafen)\
ELSE (setscene wc.hgr anwesend)
attr wc_zone hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr wc_zone hz_decay 180
attr wc_zone hz_lumiThreshold_present 0:300
attr wc_zone hz_luminanceReading wc_huesens_light:lux
attr wc_zone hz_occupancyEvent wc_bwm:motion
attr wc_zone hz_state 100:present 50:likely 1:unlikely 0:absent
attr wc_zone userReadings lux {ReadingsNum('wc_huesens_light','lux',50);;;;},\
targetlux
VG Sebastian
Ich finde die bisherige Entwicklung interessant und hänge mich jetzt mal ein. Erstes Anliegen: Ich würde die ganze Heuristik gerne aus der FHEM-Hauptinstallation auslagern, und dieser nur die Aufgabe geben, bei Auftreten bestimmter Events eine andere FHEM-Installation zu benachrichtigen. So à la: "In Raum X manueller Event detektiert" (z.B. Schalter gedrückt), oder "In Raum Y Bewegung festgestellt".
Das ganze Modul ist ein guter Einstieg in Ambience Assisted Living, um z.B. aus der Entfernung den Gesundheitszustand von pflegebedürftigen Personen zu überwachen.
LG
pah
Zitat von: binford6000 am 05 Juni 2020, 11:16:33
Hallo Oli,
ich teste gerade mit dem Box-Mode, da ich keine Türkontakte für die present-Erkennung habe.
Mir ist da was merkwürdiges aufgefallen:
Gegeben ist der Flur mit BWM und das Gästeklo mit BWM (beide HUE Motion). Die Gästeklo-Zone ist im Boxmode, die Flur-Zone nicht.
Gästeklo-Zone mit hz_adjacent fl_zone.
Jetzt gehe ich ins Gästeklo:
- Die Gästeklo-Zone geht sofort auf present. OK.
- Aber dann geht die Gästeklo-Zone auf likely, wenn der Flur-BWM auf nomotion wechselt!
- Geht der Gästeklo-BWM auf nomotion, geht die Gästeklo-Zone brav wieder in present.
Warum wird denn auf nomotion in der angrenzenden Zone getriggert und damit die box-Zone wieder auf likely geschaltet?
In Summe funktioniert das zwar auch, aber es wird unschön (und mMn. unnötig) zwischen present und likely gewechselt.
Ist das so gewollt? Mir erschließt sich der Grund jedenfalls nicht...
Bei mir aüßert sich das konkret darin dass wenn ich das Licht im Gästeklo manuell ausschalte, wird es durch das unnötige
erneute wechseln in present wieder eingeschaltet.
VG Sebastian
Hallo Oli,
ich habe die Lösung für mein Problem mit Box-Mode gefunden:
Anstatt
attr wc_zone hz_occupancyEvent wc_bwm:motionhabe ich - wie in deiner Beschreibung - folgendes eingefügt:
attr wc_zone hz_occupancyEvent wc_bwm:state:.motion Damit klappt es dann wie gewünscht ohne hin- und herschalten. 8)
VG Sebastian
Hallo,
ich hab mir das Module auch mal angesehen und überlegt, ob ich damit folgendes "Problem" lösen kann.
Aktuell nutze ich Fibaro BWM, diese melden per Event, dass eine Bewegung stattgefunden hat und wenn nach x Sekunden keine Bewegung mehr da ist, kommt auch ein Event.
Nun sitze ich im Keller, bewege mich nicht und das Licht geht aus. Doof :/
Jetzt hab ich mal dein Module ausprobiert und zwei Zonen angelegt, in denen ich meine BWM habe.
Die Zone Keller und eine zweite Zone "Ankleide". Die Räumen liegen nebeneinander. Aber wenn ich jetzt vom Keller zur Ankleide gehe, gehen beide Zonen auf likely und gehen irgendwann "aus".
Edit: Im Keller bleibt der BWM 60 sekunden auf "open" wenn keine Bewegung mehr erkannt wird. Das sollte vermutlich deutlich unter der Decay Zeit liegen oder?
Internals:
CFGFN
FUUID 5f1e83f5-f33f-2251-d9cd-e0a58aa83db42d14
NAME zone.keller
NR 259462
NTFY_ORDER 50-zone.keller
STATE absent
TYPE homezone
VERSION 0.0.13
HELPER:
doors 0
READINGS:
2020-07-27 09:48:45 lastDayTime morning
2020-07-27 10:23:37 lastZone timer
2020-07-27 10:23:37 occupied 0
2020-07-27 10:23:37 state absent
helper:
TIMER 1595838217
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_adjacent zone.ankleide
hz_boxMode 1
hz_decay 180
hz_occupancyEvent ke.motion.1:HomeSecurity: Motion Detection
hz_state 100:present 50:likely 1:unlikely 0:absent
userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
Internals:
CFGFN
FUUID 5f1e83fb-f33f-2251-78d3-f04a481ca885f0e8
NAME zone.ankleide
NR 259464
NTFY_ORDER 50-zone.ankleide
STATE absent
TYPE homezone
VERSION 0.0.13
HELPER:
doors 0
READINGS:
2020-07-27 09:49:35 lastDayTime morning
2020-07-27 10:25:37 lastZone timer
2020-07-27 10:25:37 occupied 0
2020-07-27 10:25:37 state absent
helper:
TIMER 1595838337
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_adjacent zone.keller
hz_boxMode 1
hz_decay 300
hz_occupancyEvent ak.motion.1:HomeSecurity: Motion Detection
hz_state 100:present 50:likely 1:unlikely 0:absent
userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
Moin zusammen,
ich versuche folgendes Problem zu lösen:
Ich gehe aus dem Zimmer und schließe die Tür. Tür Kontact meldet Tür zu = Zone closed.
Der Zähler bleibt bei 100 stehen und das Licht geht nie aus.
Gib es die Möglichkeit den Zähler loslaufen zu lassen wenn Tür zu und danach keine Bewegung in der Zone erkannt wurde?
Also Zone closed und keine Bewegung innerhalb von 10 sec, dann timer los laufen lassen.
Boxed Mode macht ja was anderes, wenn ich das richtig verstanden habe?
Hallo KernSani,
klasse Modul! Wird von mir intensiv genutzt und ich möchte es nicht mehr missen.
Daher unterstreiche ich hiermit auch noch mal den Wunsch dieses Modul offiziell anzubieten und über updates zu verteilen.
Eine Idee/einen Wunsch habe ich noch zum Modul.
Ein Reading mit der aktuellen Tageszeit wäre hilfreich (curDayTime).
Damit wäre es sehr einfach in Abhängigkeit der in der Zone eingestellten Tageszeit zu steuern.
Aktuell bastele ich mir da immer noch etwas separat, was dann aber entfallen könnte.
Was hälst du davon?
Viele Grüße
Reiner
Hallo KernSani,
ich nutz es auch intensiv und würde ein einchecken auch sehr begrüßen..
Zudem habe ich ab und an auch das Problem wie slor, das ich die Tür von aussen zu mache und er auf 100 geht. Wenn ich dann natürlich die Wohnung verlasse nutzt das hz_absenceEvent und schaltet aus. Aber WC / Bad macht man nun in der kalten Jahreszeit öfter mal von Aussen zu und dann wäre das abschalten , wenn keiner drin ist toll :D
Dafür habe ich eine Flur Zone, die das Triggern könnte mit BWM. Oder gibt es eine Andere Idee ?
Ronny
Hi,
ich wollte dieses Modul mal testen und habe gemerkt, dass es wohl mit meiner Konstellation von Bewegungsmeldern nicht funktioniert.
Ich bekomme nur ein Event bei einer Bewegung und bei keiner Bewegung vom Bewegungsmelder. Wenn einmal eine Bewegung erkannt wurde werden keine weiteren Events mehr generiert solange es eine Bewegung gibt.
Lässt sich es sich so einstellen, dass man noch ein Attribut für "hz_NOToccupancyEvent" hinzufüget wenn also der Bewegundmelder keine Bewegung mehr meldet dass dann erst der Timer runterläuft.
Was meint ihr?
VG Sebastian
Was für Bewegungsmelder hast du!?
Evtl. kann man dort was einstellen...
Hast du event-on-change-reading o.ä. gesetzt!?
Gruß, Joachim
@obi: Das ist eine Speziallösung, die sollte vielleicht jeder selbst realisieren. Geht problemlos mit sequence oder DOIF.
LG
pah
Hallo,
ich habe KNX Bewegungsmelder, dort könnte ich einstellen, dass alle x Sekunden der Status gesendet wird. Dies erzeugt mir aber zu viel unnötige Bus Last.
Ich werde wie empfohlen doch wohl einfacher DOIF verwenden. Das hatte ich mir auch schon gedacht.
VG
Wäre das Bewegungsevent nicht einfach als "close" im Sinne dieses Moduls zu verstehen?
Und wenn dann "nicht Bewegung" kommt, dann ist es ein "open"?
Ich denke auch, dass das erweitert werden muss. Ich habe jetzt mein Treppenhaus mit Bewegungsmeldern ausgestattet und kann aus der Reihenfolge der Auslösung sagen, wann eine Person z.B. vom Dachgeschoss bis ins Erdgeschoss wechselt - oder umgekehrt.
Ins Modul müsste also ein set-Befehl, der die Anzahl der Personen pro Zone um 1 erhöht oder erniedrigt. Die Occupancy wäre dann also eine Gleitkommazahl, die auch größer als 1 (oder 100%) sein kann.
LG
pah
Hallo zusammen,
ich versuche gerade 2 Zonen zum "zusammen Spiel" zu bewegen, aber irgendwie bekomme ich das nicht hin.
Die Situation ist folgende:
Küche und Wohnzimmer jeweils mit Bewegunsmelder und als Zone angelegt.
Die Küche hat eine Tür mit Türkontakt, das Wohnzimmer hat keine Tür, ist jedoch nur durch die Küche erreichbar.
Im Wohnzimmer steht ein TV, welches ich über presence in fhem abbilde.
Jetzt soll die Zone Küche present sein, sobald die Tür aufgeht, oder der Bewegungsmelder in der Küche anschlägt, und den Countdown starte, wenn die Tür wieder geöffent wird, oder der Bewegunsmelder im Wohnzimmer auslöst.
Das Wohnzimmer soll present sein, wenn der Bewegungsmelder im Wohnzimmer anschlägt und den Countdown starten, sobald der Bewegungsmelder in der Küche Bewegung meldet, jedoch NICHT wenn gerade das TV an ist.
Bisher hatte ich das so gelöst, das der TV sowohl als Tür als auch als occupancy event im Wohnzimmer eingestellt war, und der Zustand present/absent der Zone Wohnzimmer als Tür in der Zone Küche.
Das hat soweit auch gut funktioniert, war abends der TV an, und kam jemand durch die Tür rein und hat dann die Küche wieder verlassen, hat zwar der Countdown angefangen, da das TV jedoch alle 60 Sek ein event present auslöst, wurde die Zone Wohnzimmer vor ablauf des Countdowns wieder auf close und present gesetzt, und das Licht bleibt an.
Steht jemand im Wohnzimmer auf, um sich aus der Küche etwas zu trinken zu holen, geht in der Küche das Licht an, da aber die Zone Wohnzimmer noch auf present steht geht nach verlassen der Küche der Timer los, und das Licht in der Küche geht wieder aus.
Das Problem ist nun allerdings, wenn z.B. im Wohnzimmer Personen anwesend sind, und jemand anderes in der Küche z.B. Kocht. Dadurch schlägt der Bewegungsmelder in der Küche nicht rebelmässig an, weil man ja selten vor dem Herd herumtanzt, sondern eher ruhig dasteht. und nach ablauf des Countdowns steht man in der Küche im dunkeln.
Ich habe jetzt versucht das mit hz_adjacent und boxmode zu lösen, allerdings blicke ich besonders bei boxmode nicht wirklich durch.
Ich habe die Zonen jeweils als adjacent in der anderen Zone eingestellt, und boxmode in beiden Zonen auf 1.
Leider geht jetzt keine der Zonen mehr auf absent.
Bewege ich mich z.B. in der Küche, geht zwar der Countdown im Wohnzimmer los, wird jedoch bei 90 von dem Zustand in der Küche überschrieben, und wieder auf 99 gesetzt.
Die Küche wiederum lässt sich durch Bewegungen im Wohnzimmer nicht beeindrucken, vermutlich, da die Tür ja geschlossen ist und dadurch die Zone auf closed steht.
Ich hoffe jemand liest diesen Text bis hierher, und kann mir einen Hinweis geben, wie ich dieses Problem lösen kann.
Zitat von: patlabor am 23 Oktober 2020, 21:05:04
Hallo zusammen,
ich versuche gerade 2 Zonen zum "zusammen Spiel" zu bewegen, aber irgendwie bekomme ich das nicht hin.
Die Situation ist folgende:
Küche und Wohnzimmer jeweils mit Bewegunsmelder und als Zone angelegt.
Die Küche hat eine Tür mit Türkontakt, das Wohnzimmer hat keine Tür, ist jedoch nur durch die Küche erreichbar.
Im Wohnzimmer steht ein TV, welches ich über presence in fhem abbilde.
Jetzt soll die Zone Küche present sein, sobald die Tür aufgeht, oder der Bewegungsmelder in der Küche anschlägt, und den Countdown starte, wenn die Tür wieder geöffent wird, oder der Bewegunsmelder im Wohnzimmer auslöst.
Das Wohnzimmer soll present sein, wenn der Bewegungsmelder im Wohnzimmer anschlägt und den Countdown starten, sobald der Bewegungsmelder in der Küche Bewegung meldet, jedoch NICHT wenn gerade das TV an ist.
Bisher hatte ich das so gelöst, das der TV sowohl als Tür als auch als occupancy event im Wohnzimmer eingestellt war, und der Zustand present/absent der Zone Wohnzimmer als Tür in der Zone Küche.
Das hat soweit auch gut funktioniert, war abends der TV an, und kam jemand durch die Tür rein und hat dann die Küche wieder verlassen, hat zwar der Countdown angefangen, da das TV jedoch alle 60 Sek ein event present auslöst, wurde die Zone Wohnzimmer vor ablauf des Countdowns wieder auf close und present gesetzt, und das Licht bleibt an.
Steht jemand im Wohnzimmer auf, um sich aus der Küche etwas zu trinken zu holen, geht in der Küche das Licht an, da aber die Zone Wohnzimmer noch auf present steht geht nach verlassen der Küche der Timer los, und das Licht in der Küche geht wieder aus.
Das Problem ist nun allerdings, wenn z.B. im Wohnzimmer Personen anwesend sind, und jemand anderes in der Küche z.B. Kocht. Dadurch schlägt der Bewegungsmelder in der Küche nicht rebelmässig an, weil man ja selten vor dem Herd herumtanzt, sondern eher ruhig dasteht. und nach ablauf des Countdowns steht man in der Küche im dunkeln.
Ich habe jetzt versucht das mit hz_adjacent und boxmode zu lösen, allerdings blicke ich besonders bei boxmode nicht wirklich durch.
Ich habe die Zonen jeweils als adjacent in der anderen Zone eingestellt, und boxmode in beiden Zonen auf 1.
Leider geht jetzt keine der Zonen mehr auf absent.
Bewege ich mich z.B. in der Küche, geht zwar der Countdown im Wohnzimmer los, wird jedoch bei 90 von dem Zustand in der Küche überschrieben, und wieder auf 99 gesetzt.
Die Küche wiederum lässt sich durch Bewegungen im Wohnzimmer nicht beeindrucken, vermutlich, da die Tür ja geschlossen ist und dadurch die Zone auf closed steht.
Ich hoffe jemand liest diesen Text bis hierher, und kann mir einen Hinweis geben, wie ich dieses Problem lösen kann.
Mal gucken ob ich das richtig verstanden habe:
Nur Kochen => Küche zu, Küche "belegt", Licht bleibt an.
Kochen + TV/Wohnzimmer => TV/Wohnzimmer öffnet die Küche, Countdown läuft => Licht geht dort irgendwann aus.
Das Problem wird doch sein, wie wird "rein-kochen-stillstehen" und "rein-Bierzapfen-rausgehen" unterschieden.
Technisch ist das doch gleich: Rahmenbedingungen (TV an/aus x Tür auf/zu) x Bewegungsevents
Du willst bei beiden Situation, welche sich erstmal technisch gleich darstellen, unterschiedliche Reaktionen.
D.h. wenn du nur umkonfigurierst, wird doch zwangsläufig eine Situation falsch abgebildet.
Des Weiteren ist das Ableiten von Anwesenheiten durch BWM mMn immer problematisch, sobald mehrere Personen im Spiel sind. Denk an die Donnerkuppel!
Zwei gehen rein, einer kommt raus. Der andere spielt regungslos auf seinem Handy, braucht dazu aber schon ein wenig Licht.
Ich glaube, man braucht weitere Parameter:
Man könnte die Küche "besser" auf Belegung Prüfen: Längerer Countdown bei kürzerem BWM-Cooldown (wenn man das einstellen kann). Mehr/empfindlichere Bewegungsmelder. Weitere Kochgeräte z.B. Herd überwachen (wobei man mein köcheln lassen und währenddessen TV gucken in der Küche kein Licht braucht).
Hallo zusammen, wird das Modul noch weiter entwickelt?
Habe neue Bewegungsmelder und würde gerne alle Räume im Haus als Homezone definieren.
Habe aber noch ein Problem, das ich nicht lösen könnte:
In einem Raum mit Türkontakt und Bewegungsmelder läuft der Timer nicht los, wenn keiner im Raum ist und für zu.
Ich müsste also nach Schließen der Tür noch mal prüfen ob es Bergung im Raum gibt. Wenn nicht, dann Timer los, sonst Zone locked und keine Aktion.
Das scheint das Modul aktuell nicht zu unterstützen.
Ich habe weitergebaut... mir ist noch etwas aufgefallen.
Szenario:
Zone mit Kontakt an der Tür der open oder closed setzt
Bewegungsmelder, der occupancy meldet
Lichtschalter, der bei off eine absenceEvent setzt
Wenn ich nun die Tür öffne und durch den Lichtschalter ein Absence Event auslöse geht die Zone auf open und abwesend.
Schließe ich die Tür von außen geht die Zone wieder auf Closed und Presence auf 100%.
Der Bewegungsmelder hat mich dabei nicht erfasst.
Soll das so? Oder habe ich einen Fehler in meiner Logik?
Gude,
ich habe das mal schnell getestet und ein Absenceevent eingebaut.
Das geht schon in Deine Richtung, heute abend mach ich da vielleicht mal genauer weiter:
Bewegung setzt occupied auf 99% und dann läuft der decay, egal ob open oder closed.
=> erwartet
Zone steht "closed" und danach Beweugng: occupied 100%, kein decay
=> erwartet
Zone auf "open" und AbsenceEvent: occupied auf 0%
=> erwartet
Zone "closed" und AbsenceEvent: occupied auf 100%, kein decay
=> kein decay ist erwartet, aber 100% occupied nicht.
Wobei bei Dir das ja ein bisschen anders ist: Du schließt die Tür nach dem absenceEvent, bei mir ist die Tür geschlossen und danach schicke ich das AbsenceEvent.
Edit: Verbose 5 aus dem log:
2021.03.23 07:35:24 5: [homezone - hz_Bad]: set absence in condition closed
2021.03.23 07:35:24 5: [homezone - hz_Bad]: Luminance: 0 Threshold: 0-9999999999
2021.03.23 07:35:24 5: [homezone - hz_Bad]: Luminance: 0 Threshold: 0-9999999999
2021.03.23 07:35:24 5: [homezone - hz_Bad]: 100
Die Situation wird also richtig erkannt: absence in condition closed, aber die falschen Konsequenzen daraus gezogen.
Edit 2: Ich tippe nun auf Bug:
Ab Zeile 252:
foreach my $o (@abs) {
my ( $absDev, $absEv ) = split( ":", $o, 2 );
if ( $dev =~ /$absDev/ && $event =~ /$absEv/ ) {
Log3 $name, 5, "[homezone - $name]: set absence in condition " . ReadingsVal( $name, "condition", "" );
homezone_setOcc( $hash, 0 );
last;
}
}
@abs enthält alle absenceEvents
und dann
ab Zeile 267:
sub homezone_setOcc($$;$) {
my ( $hash, $occ, $lastChild ) = @_;
my $name = $hash->{NAME};
$lastChild = "self" unless $lastChild;
if ( ReadingsVal( $name, "condition", "" ) eq "closed" && $lastChild ne "timer" ) {
$occ = 100;
}
Aus meiner bescheidenen Perl-Kenntnis heraus:
$lastChild wird nicht übergeben, ist daher "undef"; wird zu "self" und ist damit ungleich "timer".
D.h. wenn closed ist, dann wird immer occ auf 100 gesetzt und die übergebenen 0 damit überschrieben.
Was danach in der sub folgt spielt auch keine Rolle mehr, die 100 ist gesetzt.
Cool, danke für die Analyse!
Jetzt die Frage, wird das Modul noch aktiv von KernSani weiter entwickelt?
Guten Abend zusammen,
ich habe gerade das Nachtlicht bei uns im Flur durch eine Homezone optimieren wollen...
Aktuell geht es 24h am Tag für 2 min an, wenn Bewegung erkannt wird.
Nun dachte ich, es langt ja, wenn es angeht, wenn es dunkel ist. Leider sind die Helligkeitswerte des Bewegungsmelders bogus...
Eine Idee wäre über das sunrise_el dynamisch die Zeiten für Evening und Morning anzupassen, damit das mit den Jahrenszeiten zusammenpasst. Oder ich setze einen Schwellwert auf Helligkeit und schreibe über sunrise_el die Helligkeit in einen Dummy, den ich auswerte.
Sonst noch Ideen, wie ich das dynamisch anpassen könnte?
Gude,
du kannst ja bei den cmds die bei einem bestimmten State ausgeführt werden auch Perlcode aufrufen.
Dann kannste ja da eine if-Schleife als Einzeiler oder als ausgelagerte Sub bauen.
Zitat von: slor am 23 März 2021, 12:28:18
Cool, danke für die Analyse!
Jetzt die Frage, wird das Modul noch aktiv von KernSani weiter entwickelt?
Bin wieder da und schaue mir das die nächsten Tage mal an :-)
Hallo zusammen, ich hätte noch einen...
Mir ist aufgefallen, dass ich unterschiedliche dim Level je nach Tageszeit bräuchte. Ich sehe aber nur unterschiedliche decay Einstellungen für die Tageszeiten, aber keine cmd. diese habe ich nur für die Anwesenheitslevel.
Vermute, dass ist aktuell im Modul nicht so abgebildet?
ich bräuchte sowas in der Art: hz_cmd_likely_evening
Oder lässt sich das anders umsetzen? Also bei Bewegung nachts 20% dimmen, morgens und abends 60% dimmen.
Hallo,
ich nutze auch über längeren Zeitraum dieses Modul. Dabei ist mir aufgefallen, das mir manchmal die Dauer fehlt. Hier wäre es toll, wenn man die Dauer für Nichtanwesenheit/Anwesenheit in Sekunden als Reading hätte (ähnlich wie in Residents Modul) -> da hier einer bei 0% der andere bei 30 oder 50% als Abwesend zählt, kam mir dabei folgende Idee:
Ein Attribute mit dem namen duration_range oder so ähnlich, dabei kann man zum Beispiel 0:1:50:100 oder nur 0:1:100 eingeben. Dann würde man eine Zeit zwischen erster und zweiter sowie zweiter und dritter Zahl usw... bestimmen.
Hier könnte man überlegen, ob man ein Rading oder jeweils ein eigenes Reading generieren würde (als 0_duration; 1_50_duration; 51_100 duration) was wiederum für einige DOIF's vielelicht etwas leichter wäre, weil man dann sagen kann, wenn 0 > 300 sek und Anwesenheit registriert --> dann wenig licht und wenn 0>300 sek und Anwesenheit registriert dann viel Licht/Laden der letzten Scene (man war ja nur kurz [5 min] drauen)...
Und insgesammt könnte man per doif darauf reagieren, das zum Beispiel seit über 5 Minuten jemand im Raum ist, und die Heizung hochdrehen, oder länger als 15 Minuten niemand mehr im Raum war, und die Heizung ausschalten usw... ebenso könnte man die Lichter dann (nachts zum Beispiel) in den ersten 3 Minuten (kurz rein und wieder aus dem Raum raus) nur 1 Lampe gedimmt einschalten, wenn man sich aber länger aufhält, kann man mehr Lampen hinzuschalten. usw.. da kam mir einige Ideen dazu.
Wäre das möglich???
Das wäre wirklich cool! Hab ich noch garnicht dran gedacht.
@KernSani, hat du sowas wie eine Wunschliste / Backlog für das Modul?
@slor, kotaro: Prinzipiell liese sich das gewünschte Szenario (soweit ich es verstanden habe) relativ leicht mit einem DOIF mit wait-Attribut umsetzen.
Ein Reading vergleichbar mit Residents zu erzeugen, in dem die An- bzw. Abwesenheitszeit z.B. jede Minute hochgezählt wird missfällt mir etwas, da das bei vielen Zonen eine ganze Menge Events erzeugt und wahrscheinlich will dann jemand nach 10 Sekunden Anwesenheit etwas triggern ;-) Ich denke nochmal drüber nach... Was spricht gegen DOIF mit wait?
@slor: Den Vorschlag "hz_cmd_likely_evening" nehme ich mal in mein persönliches Backlog mit auf. Damit werden die Userattribute zwar vielleicht etwas unübersichtlich, aber vielleicht mache ich das über ein weiteres Attribut steuerbar...
@slor/laberlaib: Die Analyse bez. des absence-Events ist m.E. vollkommen richtig. Das lustige ist, dass ich es bei mir nicht nachvollziehen kann. Da muss ich vielleicht nochmal mit einem Test-Bewegungsmelder ran, um das Ganze zu isolieren.
@pah: Die Anzahl der Personen in einer Zone zuverlässig zu bestimmen ist mein Traum... Aber bei mir ziemlich unrealistisch, wobei ich das mit den Stockwerken tatsächlich ausprobieren könnte. Nun zu einer möglichen Erweiterung des Modules: Das einzig sinnvolle Szenario, das ich mir aktuell vorstellen kann ist nur, dass mit Sicherheit weißt, wie viele Personen anwesend sind und entsprechend unterschiedlich reagierst (Sowas, wie: Alle Bewohner sind im OG, also mache ich das Licht im EG aus). Alle anderen Szenarien, Im Sinne von "Eine Person ist mit 77% Wahrscheinlichkeit im OG und mit 32% Wahrscheinlichkeit ist eine weitere Person anwesend , daher zählen wir jetzt von 109% nach unten" machen m.E. wenig Sinn. Ich lasse mich da aber gerne eines Besseren belehren...
Hallo Oli, Danke!
ein Doif reicht dafür denke ich auch aus.
Bist du weiter gekommen bei der Analyse der Absence Events? (Tür zu von außen, Zone springt auf locked und 100% occupied)
Könntest du noch einen Check einbauen, der regelmäßig (konfigurierbar) prüft ob nach einen Close event wirklich jemand im Raum ist? Das würde ggf. evtl. das Problem weiter oben lösen.
Noch ein Wunsch, könntest du einbauen, dass bei jeder Veränderung von Occupied nach oben der cmd Befehl neu getriggert wird? Nicht nur beim initialen Occupied. Hintergrund: Zone hat ein decay von 10 min. Nach 2 Minuten macht jemand das Licht am Schalter aus. Dann bleibt die Zone trotz Bewegung 8 Minuten Dunkel, bevor das wieder angeht. Das Setting gerne konfigurierbar :-)
Könntest du deinen ersten Post um das Backlog erweitern? Dann kann man checken ob ein Feature schon angefragt / in Arbeit / implementiert ist :-)
Falls du nen Bewegungsmelder brauchst, ich könnte dir einen schicken.
Zitat von: slor am 13 April 2021, 16:12:04
Noch ein Wunsch, könntest du einbauen, dass bei jeder Veränderung von Occupied nach oben der cmd Befehl neu getriggert wird? Nicht nur beim initialen Occupied. Hintergrund: Zone hat ein decay von 10 min. Nach 2 Minuten macht jemand das Licht am Schalter aus. Dann bleibt die Zone trotz Bewegung 8 Minuten Dunkel, bevor das wieder angeht. Das Setting gerne konfigurierbar :-)
Edit: Kann ich vermutlich mit hz_absenceEvent: lösen.
Auf der Anderen Seite könnte ja noch jemand im Raum sein... der würde dann wieder occupied triggern. Falls nicht vorher der Lumisensor bei dem hellen Licht das nicht blockt :-)
Zitat von: slor am 13 April 2021, 16:15:04
Edit: Kann ich vermutlich mit hz_absenceEvent: lösen.
Auf der Anderen Seite könnte ja noch jemand im Raum sein... der würde dann wieder occupied triggern. Falls nicht vorher der Lumisensor bei dem hellen Licht das nicht blockt :-)
"Licht aus" als absenceEvent ist ungeschickt, jedenfalls wenn man "Licht aus" auch als cmd_absent hat ;-) Gibt einen schönen Loop...
Ich schreibe heute Abend mal meine Ideen und eure Anregungen als Backlog in den ersten Post.
Danke für das Angebot mit dem Bewegungssensor, aber ich habe in jedem Raum einen dieser netten kleinen Aquara Dinger rumstehen ;-)
Wie gut, dass ich das noch nicht implementiert habe :-)
Dann setzt das bitte ins Backlog. - Danke!
so, habe im ersten Post mal das Backlog mit angefügt.
@slor, es hängt eine neue Version am ersten Post, die möglicherweise dein Problem mit dem Absence Event bei geschlossener Tür löst. Wenn das Problem weiterhin besteht hätte ich gerne mal ein "list" der betroffenen Zone, damit ich das besser nachstellen kann.
Danke! Problem ist gelöst. Die Zone springt nicht mehr auf Likely nach dem Schließen der Tür, sonder zählt brav runter auf 0
Habe aber ein komisches Phänomen:
Ich habe den Lichtschalter, welcher auch gleichzeitig ein Aktor für das Licht ist als absent event (off) definiert.
Schalte ich nun das Licht ein, geht es sofort wieder aus.
Was ich etwas komisch finde, da der Aktor ja auf on und nicht off geht.
List vom Device:
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_absenceEvent DG_AZ_WS:state:.off
hz_closedEvent DG_AZ_TK:state:.closed
hz_cmd_absent set HUEDevice21 off; set DG_AZ_WS off
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 300
hz_luminanceReading DG_AZ_PM:1.CURRENT_ILLUMINATION
hz_occupancyEvent DG_AZ_PM:hmstate:.yes
hz_openEvent DG_AZ_TK:state:.open
hz_state 100:present 50:likely 1:unlikely 0:absent
room 1_test
sortby 10
stateFormat state
| Timer: occupied
userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
@slor: Habe das gerade mal versucht nachzuvollziehen, bzw. nachzubauen... Ohne Erfolg... Wenn du das absenceEvent raus nimmst funktioniert wieder alles? Oder funkt da noch irgendein andere notify/DOIF mit rein?
Habs rausgenommen, geht.
Ich habe aber gesehen, dass der Schalter selbst beim "ON" drücken erst mal seinen alten Status übermittelt, nämlich off. Da geht die Zone natürlich auf Absence.
Zitat von: slor am 14 April 2021, 23:46:12
Habs rausgenommen, geht.
Ich habe aber gesehen, dass der Schalter selbst beim "ON" drücken erst mal seinen alten Status übermittelt, nämlich off. Da geht die Zone natürlich auf Absence.
Lässt sich das mit einer cleveren Regex ausschliessen? Wie sieht denn das Eventlog bei "ON" aus?
Neue Version mit Implementierung eines "doAlways" Attributes ist am ersten Post angehängt. Doku des Attributes ist ebenfalls im ersten Post.
So siehts aus, wenn ich Einschalte:
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS hmstate: off
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 4.STATE: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS control: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 3.STATE: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 5.STATE: off
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS hmstate: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 6.STATE: off
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS hmstate: on
So beim Ausschalten:
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS hmstate: on
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 4.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS control: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 3.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 5.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS hmstate: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 6.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS hmstate: off
Zitat von: KernSani am 14 April 2021, 23:48:55
Neue Version mit Implementierung eines "doAlways" Attributes ist am ersten Post angehängt. Doku des Attributes ist ebenfalls im ersten Post.
Cool, dass es so schnell weiter geht hier!
Ich teste morgen mal.
Könntest du noch einen Zeitstempel an deine Versionsnummern machen? So kann man nach längerer Zeit sehen ob man die neuste Version hat (Ohne sein Fhem prüfen zu müssen :-))
Für den Haussegen wäre jetzt die Tageszeit abhängigen CMDs wichtig :-)
Zitat von: slor am 15 April 2021, 00:00:18
Cool, dass es so schnell weiter geht hier!
Finde ich auch!
Was mir noch aufgefallen ist: ein
reload 98_homezone.pmgenügt anscheinend nicht um die neue Version anzuzeigen. Erst ein
shutdown restart zeigt auch die korrekte Version an. Ist das nur kosmetisch im Internal oder benötigt homezone tatsächlich einen Neustart?
VG Sebastian
Zitat von: binford6000 am 15 April 2021, 09:56:48
Finde ich auch!
Was mir noch aufgefallen ist: ein
reload 98_homezone.pm
genügt anscheinend nicht um die neue Version anzuzeigen. Erst ein shutdown restart zeigt auch die korrekte Version an. Ist das nur kosmetisch im Internal oder benötigt homezone tatsächlich einen Neustart?
VG Sebastian
Nee, Neustart ist nicht notwendig. Ich setze die Versionsnummer allerdings im DEFINE, daher wird die bei einem reload nicht aktualisiert (wenn du wert darauf legst, sollte ein DEFMOD aber ausreichen).
Ich bin gerade noch dran, die commandref fertig zu machen und dann würde ich das Ding auch endlich mal ins SVN einchecken, dann wird das mit der Versionierung auch wieder einfacher/weniger relvant...
ZitatNee, Neustart ist nicht notwendig. Ich setze die Versionsnummer allerdings im DEFINE, daher wird die bei einem reload nicht aktualisiert (wenn du wert darauf legst, sollte ein DEFMOD aber ausreichen).
Ah OK. Wie gesagt ist mir nur aufgefallen.
ZitatIch bin gerade noch dran, die commandref fertig zu machen und dann würde ich das Ding auch endlich mal ins SVN einchecken, dann wird das mit der Versionierung auch wieder einfacher/weniger relvant...
Das wird auch wirklich mal Zeit ;D ;D
VG Sebastian
Zitat von: slor am 14 April 2021, 23:57:18
So siehts aus, wenn ich Einschalte:
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS hmstate: off
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 4.STATE: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS control: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 3.STATE: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 5.STATE: off
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS hmstate: on
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS 6.STATE: off
2021-04-14 23:51:55 HMCCUDEV DG_AZ_WS hmstate: on
So beim Ausschalten:
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS hmstate: on
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 4.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS control: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 3.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 5.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS hmstate: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS 6.STATE: off
2021-04-14 23:54:50 HMCCUDEV DG_AZ_WS hmstate: off
Das ist ja total wirr... Da kann ja eigentlich kein notify/doif vernünftig funktionieren. Was ist denn das für ein Gerät?
Es handet sich um einen HmIP-BSM and einer HMCCU.
Ich hab mal event-on-change-reading gesetzt.
Damit sieht ein und ausschalten viel besser aus.
2021-04-16 16:06:51 HMCCUDEV DG_AZ_WS on
2021-04-16 16:06:51 HMCCUDEV DG_AZ_WS 4.STATE: on
2021-04-16 16:06:51 HMCCUDEV DG_AZ_WS control: on
2021-04-16 16:06:51 HMCCUDEV DG_AZ_WS on
2021-04-16 16:06:51 HMCCUDEV DG_AZ_WS hmstate: on
2021-04-16 16:06:52 HMCCUDEV DG_AZ_WS 3.STATE: on
2021-04-16 16:06:55 HMCCUDEV DG_AZ_WS off
2021-04-16 16:06:56 HMCCUDEV DG_AZ_WS 4.STATE: off
2021-04-16 16:06:56 HMCCUDEV DG_AZ_WS control: off
2021-04-16 16:06:56 HMCCUDEV DG_AZ_WS off
2021-04-16 16:06:56 HMCCUDEV DG_AZ_WS hmstate: off
2021-04-16 16:06:57 HMCCUDEV DG_AZ_WS 3.STATE: off
Damit klappt das jetzt mit der Zone auch. Licht aus = Absence. Licht an = Licht an und sonst nix :-)
DoAlways klappt übrigens auch!
und schon ist das Backlog (so gut wie) abgearbeitet. Am ersten Post hängt eine neue Version, die
* eine Doku hat
perl /opt/fhem/contrib/commandref_join.pl /opt/fhem/FHEM/98_homezone.pm ausführen, nach dem Upload
* es erlaubt tageszeitanhängige Befehle zu definieren, und zwar so:
attr hz_test hz_cmd_absent set hz_light off\
night:set hz_light 100
also: im jeweilgen Command-Attribut durch Zeilenumbruch getrennt und die jeweilige Tageszeit (mit ":") vor das Kommando gestellt. Die Zeile ohne Tageszeit wird ausgeführt, wenn keine passende tageszeit gefunden wird.
Bitte mal intensiv testen. Das ist der Release-Kandidat für ein Einchecken ins SVN (heißt, die offizielle FHEM Distribution)
Moin
habe die Version von heute eingebaut. Klappt bisher alles ohne Fehler :) Vielen Dank!!
Eine Wunsch rein optischer Natur. Kannst du den Attribut Felder die Option "textField-long" mitgeben?
Ich habe das zur Zeit bei mir mit: widgetOverride hz_openEvent:textField-long
Frage: was bedeutet die Meldung im Log: "2021.04.17 09:11:22 1: [homezone - HAUS]: Commands extracted"
Gruss
Enno
Moin Enno,
Danke für's testen. Textfield-long werde ich einbauen, wo es noch nicht der Fall ist.
Die Meldung kannst du ignorieren, da habe ich wohl vergessen eine Debug-Meldung auszubauen.
Schönes WE,
Oli
Kleinigkeiten, die Enno festgestellt hat erledigt (1. Post)
Zitat von: KernSani am 18 April 2021, 00:40:25
Kleinigkeiten, die Enno festgestellt hat erledigt (1. Post)
Moin Oli,
mit der letzten Version:
defmod master_zone homezonekommt
Global symbol "$empty" requires explicit package name (did you forget to declare "my $empty"?) at ./FHEM/98_homezone.pm line 425.Das Internal version ist auch tatsächlich ganz empty:
Internals:
DEF
FUUID 5ee85396-f33f-0308-77d7-0def9be885317600
FVERSION 98_homezone.pm:v0.0.17-s18522/2019-02-07
NAME master_zone
NR 234
NTFY_ORDER 50-master_zone
STATE inactive
TYPE homezone
VERSION
READINGS:
2021-04-17 12:41:50 associatedWith
2021-03-27 19:24:05 condition closed
2021-03-27 23:16:22 lastChild bu_zone
2021-03-27 23:16:22 lastDayTime evening
2021-03-27 23:16:22 lastLumi 6
2021-03-27 23:16:22 lastZone bu_zone
2021-03-27 23:16:22 occupied 100
2021-03-27 23:40:15 state inactiveVG Sebastian
Moin Oli,
wenn ich in Zeile 424
if ( $leafChild eq $empty
in if ( $leafChild eq $EMPTY
änder, läuft es mit der Version von heute Morgen.
Gruss
Enno
Hi Oli,
wollte gerade die neue Version testen, bekomme aber folgende Fehlermeldung:
ERROR:
Global symbol "$empty" requires explicit package name (did you forget to declare "my $empty"?) at ./FHEM/98_homezone.pm line 425.
Gruß Hartmut
Zitat von: enno am 18 April 2021, 09:20:54
Moin Oli,
wenn ich in Zeile 424
if ( $leafChild eq $empty
in if ( $leafChild eq $EMPTY
änder, läuft es mit der Version von heute Morgen.
Gruss
Enno
Jepp, hier auch. Allerdings bleibt VERSION leer bis shutdown/restart.
Danach siehts aber dann gut aus!
VG Sebastian
Danke
hatte Tomaten auf den Augen :)
bekomme zwar keine Fehlemeldung mehr, aber habe auch keine homezone mehr.
Es ist mir ein Rätsel... Diesen $empty Bug hatte ich bei mir bereits behoben. Wie das wieder in das hochgeladenen File kam, ist mir echt schleierhaft. Sorry dafür. Ist im 1. Post korrigiert.
Zitat von: rippi46 am 18 April 2021, 18:20:53
bekomme zwar keine Fehlemeldung mehr, aber habe auch keine homezone mehr.
Hast du deine Zones wieder gefunden? so leicht gehen die eigentlich nicht verloren, außer du hast dein FHEM neu gestartet, das homezone_modul konnte nicht geladen werden wegen $empty und du hast danach noch den Save Button gedrückt... da hilft nur aus dem Backup holen...
Habs aus dem Backup geholt
Danke funktioniert wieder
Gruß Hartmut
Zitathz_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.
- Das Attribut heißt im Modul hz_dayTime
- Ich habe ein HOMEMODE Device aber die dayTimes werden aber nicht übernommen - auch nicht mit einem defmod
- Wenn nicht gesetzt - werden dann AUTOMATISCH die Zeiten aus HOMEMODE übernommen?
- Format in HOMEMODE: 05:00|morning Würde das konvertiert zu 5:morning?
- Und wie wäre es dann mit mit 4:30|morning?
- Ausprobiert mit der 0.0.20 (2. Datei im ersten Post)
VG Sebastian
Hier mal eine Zone und die Logauszüge:
Zone:
Internals:
DEF
FUUID 602cb3cf-f33f-0308-a685-b759196885f9c70e
FVERSION 98_homezone.pm:v0.0.19-s18522/2019-02-07
NAME wc_zone
NR 292
NTFY_ORDER 50-wc_zone
STATE absent
TYPE homezone
VERSION 0.0.20
HELPER:
doors 1
READINGS:
2021-04-19 15:00:34 associatedWith device device
2021-04-19 15:04:24 condition closed
2021-04-18 09:25:04 lastDayTime morning
2021-04-19 15:06:35 lastLumi 90
2021-04-19 15:06:35 lastZone timer
2021-04-19 15:06:35 occupied 0
2021-04-19 15:06:35 state absent
helper:
TIMER 1618837595
Attributes:
group Homezone
hz_absenceEvent Wohnung:presence:.absent
hz_closedEvent wc_huesens_door:state:.closed
hz_cmd_absent set wc_lampecol_licht:FILTER=STATE=on off; {sonosbwm('absent','play1_wc')}; night:set wc_lampecol_licht:FILTER=STATE=on off
hz_cmd_likely set wc_lampecol_licht:FILTER=STATE=off on; {sonosbwm('likely','play1_wc')}; night:set wc_lampecol_licht:FILTER=STATE=off on
hz_cmd_present set wc_lampecol_licht:FILTER=STATE=off on
hz_dayTime 05:morning 10:day 14:afternoon 18:evening 23:night
hz_decay 150
hz_decay_night 90
hz_luminanceReading wc_huesens_light:lux
hz_occupancyEvent wc_bwm:state:.motion
hz_openEvent wc_huesens_door:state:.open
hz_state 100:present 50:likely 1:unlikely 0:absent
userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss :textField-long :textField-long :textField-long :textField-long hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent
Log:
2021.04.19 14:58:21 1: [homezone - wc_zone]: Command execution failed: Unknown command night:set, try help.
2021.04.19 14:58:21 1: [homezone - wc_zone]: Perl execution failed: Unknown command night:set, try help.
2021.04.19 15:00:51 1: [homezone - wc_zone]: Command execution failed: Unknown command night:set, try help.
2021.04.19 15:00:51 1: [homezone - wc_zone]: Perl execution failed: Unknown command night:set, try help.
2021.04.19 15:03:40 3: wc_zone: unknown attribute hz_dayTimes. Type 'attr wc_zone ?' for a detailed list.
2021.04.19 15:04:05 1: [homezone - wc_zone]: Command execution failed: Unknown command night:set, try help.
2021.04.19 15:04:05 1: [homezone - wc_zone]: Perl execution failed: Unknown command night:set, try help.
VG Sebastian
Nur kurz vom Handy, Format für die dayTimes sollte so aussehen:
05:00|morning
Zitat von: KernSani am 19 April 2021, 15:26:13
Nur kurz vom Handy, Format für die dayTimes sollte so aussehen:
05:00|morning
So würden sie ja auch aus HOMEMODE kommen. Die dort hinterlegten werden aber
a) nicht übernommen und
b) mit 23:00|night und
set wc_lampecol_licht:FILTER=STATE=on off; {sonosbwm('absent','play1_wc')}; night:set wc_lampecol_licht:FILTER=STATE=on offkommt
2021.04.19 21:00:08 1: [homezone - wc_zone]: Command execution failed: Unknown command night:set, try help.
2021.04.19 21:00:08 1: [homezone - wc_zone]: Perl execution failed: Unknown command night:set, try help.Immerhin der erste Teil wird korrekt ausgeführt.
VG Sebastian
Hi Sebastian,
ich glaube ich muss weiter an der Doku arbeiten ;-) Die einzelnen Befehle (also default und je Tageszeit) werden durch Zeilenumbruch getrennt, also wirlich so, wie in meinem obigen Beispiel angegeben.
Ich nutze selbst kein Homemode, daher ist mir nicht aufgefallen, dass das nicht (mehr?) übernommen wird... Ich passe das an. Bei der Gelegenheit fällt mir auf, dass tatsächlich die Tageszeiten aus homemode nur beim Define übernommen werden. Würde wahrscheinlich Sinn machen, die Tageszeiten ebenfalls zu übernehmen, wenn man das Attribut leer macht... Ich bastle da mal noch was...
Grüße,
Oli
Aktualisierte Version im ersten Post. Bugs mit daytimes/homemode gefixt und Doku verbessert...
Zitat von: KernSani am 19 April 2021, 23:56:51
Aktualisierte Version im ersten Post. Bugs mit daytimes/homemode gefixt und Doku verbessert...
Hi,ich habe mal diverse Varianten mit der 0.0.21 durchgespielt und folgende Fehler erhalten:
{fhem("set wc_lampecol_licht:FILTER=STATE=off on"); sonosbwm('likely','play1_wc')};\
night:set wc_lampecol_licht:FILTER=STATE=off on;[homezone - wc_zone]: Perl execution failed: Unknown command {fhem("set, try help.
Unknown command sonosbwm('likely','play1_wc')}, try help.
Unknown command \
night:set, try help.{fhem("set wc_lampecol_licht:FILTER=STATE=on off"); sonosbwm('absent','play1_wc')};
night:set wc_lampecol_licht:FILTER=STATE=on off;2021.04.20 08:40:54 1: [homezone - wc_zone]: Command execution failed: Unknown command {fhem("set, try help.
Unknown command sonosbwm('absent','play1_wc')}, try help.
Unknown command night:set, try help.
2021.04.20 08:40:54 1: [homezone - wc_zone]: Perl execution failed: Unknown command {fhem("set, try help.
Unknown command sonosbwm('absent','play1_wc')}, try help.
Unknown command night:set, try help.{fhem("set wc_lampecol_licht:FILTER=STATE=off on"); sonosbwm('likely','play1_wc')}\
night:set wc_lampecol_licht:FILTER=STATE=off on2021.04.20 08:45:36 1: [homezone - wc_zone]: Command execution failed: Unknown command {fhem("set, try help.
Unknown command sonosbwm('likely','play1_wc')}\
night:set, try help.
2021.04.20 08:45:36 1: [homezone - wc_zone]: Perl execution failed: Unknown command {fhem("set, try help.
Unknown command sonosbwm('likely','play1_wc')}\
night:set, try help.set wc_lampecol_licht:FILTER=STATE=off on, {sonosbwm('likely','play1_wc')}\
night:set wc_lampecol_licht:FILTER=STATE=off on2021.04.20 08:48:06 1: [homezone - wc_zone]: Command execution failed: Unknown argument off,, choose one of off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 rgb:colorpicker,RGB color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 hue:colorpicker,HUE,0,1,65535 sat:slider,0,1,254 xy dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg hueUp:noArg hueDown:noArg satUp:noArg satDown:noArg alert:none,select,lselect,breathe,okay,channelchange,finish,stop effect:none,colorloop rename off-for-timer blink off-till-overnight on-for-timer off-till on-till-overnight on-till intervals attrTemplate:?,speech_recognition_general_naming_master_template,speechcontrol_general_naming_master_template,C_01_Eurotronic_SPZB0001_Spirit_ZigBee,D_01_Xiaomi_Aqara_MCCGQ11LM_Window_Door_Sensor,E_01a_Xiaomi_Aqara_WSDCGQ11LM_Temperature_Sensor,E_01b_Xiaomi_Aqara_WSDCGQ11LM_Pressure_Sensor,E_01c_Xiaomi_Aqara_WSDCGQ11LM_Humidity_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Lightlevel_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Motion_Sensor,G_01_Xiaomi_Aqara_WXKG02LM_Double_Switch
2021.04.20 08:48:06 1: [homezone - wc_zone]: Perl execution failed: Unknown argument off,, choose one of off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 rgb:colorpicker,RGB color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 hue:colorpicker,HUE,0,1,65535 sat:slider,0,1,254 xy dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg hueUp:noArg hueDown:noArg satUp:noArg satDown:noArg alert:none,select,lselect,breathe,okay,channelchange,finish,stop effect:none,colorloop rename off-for-timer blink off-till-overnight on-for-timer off-till on-till-overnight on-till intervals attrTemplate:?,speech_recognition_general_naming_master_template,speechcontrol_general_naming_master_template,C_01_Eurotronic_SPZB0001_Spirit_ZigBee,D_01_Xiaomi_Aqara_MCCGQ11LM_Window_Door_Sensor,E_01a_Xiaomi_Aqara_WSDCGQ11LM_Temperature_Sensor,E_01b_Xiaomi_Aqara_WSDCGQ11LM_Pressure_Sensor,E_01c_Xiaomi_Aqara_WSDCGQ11LM_Humidity_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Lightlevel_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Motion_Sensor,G_01_Xiaomi_Aqara_WXKG02LM_Double_SwitchLicht wird teilweise geschaltet, aber die Funktion nie ausgeführt.
VG Sebastian
Hi Sebastian,
Mist... hatte ich vergessen in die Doku zu schreiben. Perl funktioniert bei Tageszeit-abhängiger Steuerung (noch) nicht. Das Modul kann im cmd nur alles Perl oder alles FHEM. Auch unabhängig von der Tageszeit-abhängigen Steuereung würde sowas wie
set meineLampe on; {fhem("tuwas")}
nicht funktionieren (glaube ich). Dürfte aber kein Hexenwerk sein, das auch noch umzusetzen...
Grüße,
Oli
Ok, dann kann ich mir ja einen Ast testen... :D :D
Dann warte ich bis das auch noch kommt bzw. wird in der Funktion eh geprüft ob
es Nacht ist bzw. alle ROOMMATES asleep sind.
VG Sebastian
ZitatAuch unabhängig von der Tageszeit-abhängigen Steuereung würde sowas wie
Code: [Auswählen]
set meineLampe on; {fhem("tuwas")}
nicht funktionieren (glaube ich).
Doch! Sowas geht:
set wc_lampecol_licht:FILTER=STATE=on off; {sonosbwm('absent','play1_wc')}
VG Sebastian
PS: Der Import aus HOMEMODE funktioniert auch wieder!
Hi Sebastian,
mir ist zwar unklar, warum, aber deine Perl-Zeile scheint auch in der FHEM-Kommandozeile nicht zu funktionieren. Ansonsten habe ich noch ein bisschen herumexperimentiert und eigentlich funktionieren überraschenderweise die Kombinationen aus Perl und FHEM.
Am Ende der Zeile sollte kein ";" sein, und auch kein "\" (der kommt nur im Raw-Editor)
Dafür ist mir aufgefallen, dass associatedWith Duplikate erzeugt...
Grüße,
Oli
Ich habe im ersten Post nochmal ein kleines Update gepostet. Das ist jetzt Release Candidate 2 :-)
Also irgendwie werde ich mit der hc_cmd Syntax nicht warm... :-\
Getestet mit der 0.0.22 von heute...
Erster Versuch:
set wc_lampecol_licht:FILTER=STATE=off on; set play1_wc:FILTER=transportState=STOPPED play
night:set wc_lampecol_licht:FILTER=STATE=off on
Lampe geht an, Sonos spielt nicht
Im Log:
2021.04.22 22:22:23 1: [homezone - wc_zone]: Command execution failed: Unknown argument play
night:set, choose one of fadeIn:noArg fadeOut:noArg input:Queue joinGroup:Bad,Buero,Wohnzimmer leaveGroup:noArg mute:true,false next:noArg notify:textField pause:noArg play:noArg playFav:1.FM.-.Chillout.Lounge.Radio,ABSOLUTE.CHILLOUT,ANTENNE.BAYERN.Chillout,BLUE.MARLIN.IBIZA.RADIO,Chillout.Zone,Costa.Del.Mar.-.Chillout,El.Metro.Salsero,FFH.Lounge,FFH.Soundtrack.(Filmmusik),Ibiza.Unique,Northcoast.Radio,RADIO.BOB!.BOBs.Best.of.Rock,RADIO.BOB!.BOBs.Grunge,RADIO.BOB!.BOBs.Hardrock,RADIO.BOB!.BOBs.Kuschelrock,RADIO.BOB!.BOBs.Metal,SWR3.Elchradio.99.6.(Adult.Contemporary),bigFM.Sunset.Lounge,hr-iNFO,hr3.89.3.(Hot.AC) playUri:textField previous:noArg sayText:textField setAVTUri:textField sleep:selectnumbers,0,15,120,0,lin speak:textField stop:noArg toggle:noArg volume:slider,0,1,100 volumeDown:noArg volumeUp:noArg x_raw_payload:textField attrTemplate:?,General_Info,MQTT2_CLIENT_general_bridge,MQTT2_IO_ignoreRegexp_basic,MQTT2_IO_ignoreRegexp_tasmota,MQTT2_IO_ignoreRegexp_shelly,MQTT2_IO_ignoreRegexp_homeassistant,tasmota_basic,tasmota_basic_state_power1,tasmota_3channel_input_shelly_i3,shelly1,ESPurna_single_relay,eBus_daemon_splitter,ems-esp_heater_device,ems-esp_heater_device_outdated,ems-esp_boiler,ems-esp_boiler_outdated,ems-esp_thermostat_read-only,ems-esp_thermostat_RC35_type,ems-esp_thermostat_simple,ems-esp_thermostat_read-only_outdated,ems-esp_thermostat_simple_outdated,ems-esp_thermostat_RC35_type_outdated,zigbee2mqtt_bridge,sonos2mqtt_bridge,sonos2mqtt_speaker,sonos2mqtt_bridge_comfort,InstarCam,wled_controller,go_eCharger,8channel_ethernet_board_split,8channel_ethernet_board_unified,6channel_ethernet_board_6input_split,6channel_ethernet_board_6input_unified,esp_milight_hub_bridge,OpenMQTTGateway_MCU,worx_landroid,wallpanel_app,weewx_weather_station,McLighting,roon
2021.04.22 22:22:23 1: [homezone - wc_zone]: Perl execution failed: Unknown argument play
night:set, choose one of fadeIn:noArg fadeOut:noArg input:Queue joinGroup:Bad,Buero,Wohnzimmer leaveGroup:noArg mute:true,false next:noArg notify:textField pause:noArg play:noArg playFav:1.FM.-.Chillout.Lounge.Radio,ABSOLUTE.CHILLOUT,ANTENNE.BAYERN.Chillout,BLUE.MARLIN.IBIZA.RADIO,Chillout.Zone,Costa.Del.Mar.-.Chillout,El.Metro.Salsero,FFH.Lounge,FFH.Soundtrack.(Filmmusik),Ibiza.Unique,Northcoast.Radio,RADIO.BOB!.BOBs.Best.of.Rock,RADIO.BOB!.BOBs.Grunge,RADIO.BOB!.BOBs.Hardrock,RADIO.BOB!.BOBs.Kuschelrock,RADIO.BOB!.BOBs.Metal,SWR3.Elchradio.99.6.(Adult.Contemporary),bigFM.Sunset.Lounge,hr-iNFO,hr3.89.3.(Hot.AC) playUri:textField previous:noArg sayText:textField setAVTUri:textField sleep:selectnumbers,0,15,120,0,lin speak:textField stop:noArg toggle:noArg volume:slider,0,1,100 volumeDown:noArg volumeUp:noArg x_raw_payload:textField attrTemplate:?,General_Info,MQTT2_CLIENT_general_bridge,MQTT2_IO_ignoreRegexp_basic,MQTT2_IO_ignoreRegexp_tasmota,MQTT2_IO_ignoreRegexp_shelly,MQTT2_IO_ignoreRegexp_homeassistant,tasmota_basic,tasmota_basic_state_power1,tasmota_3channel_input_shelly_i3,shelly1,ESPurna_single_relay,eBus_daemon_splitter,ems-esp_heater_device,ems-esp_heater_device_outdated,ems-esp_boiler,ems-esp_boiler_outdated,ems-esp_thermostat_read-only,ems-esp_thermostat_RC35_type,ems-esp_thermostat_simple,ems-esp_thermostat_read-only_outdated,ems-esp_thermostat_simple_outdated,ems-esp_thermostat_RC35_type_outdated,zigbee2mqtt_bridge,sonos2mqtt_bridge,sonos2mqtt_speaker,sonos2mqtt_bridge_comfort,InstarCam,wled_controller,go_eCharger,8channel_ethernet_board_split,8channel_ethernet_board_unified,6channel_ethernet_board_6input_split,6channel_ethernet_board_6input_unified,esp_milight_hub_bridge,OpenMQTTGateway_MCU,worx_landroid,wallpanel_app,weewx_weather_station,McLighting,roon
2. Versuch:
set wc_lampecol_licht:FILTER=STATE=on off; set play1_wc:FILTER=transportState=PLAYING pause;
night:set wc_lampecol_licht:FILTER=STATE=on off;
Lampe aus, Sonos pause
Im Log:
2021.04.22 22:24:53 1: [homezone - wc_zone]: Command execution failed: Unknown command night:set, try help.
2021.04.22 22:24:53 1: [homezone - wc_zone]: Perl execution failed: Unknown command night:set, try help.
3. Versuch:
set wc_lampecol_licht:FILTER=STATE=off on; set play1_wc:FILTER=transportState=STOPPED play;
night:set wc_lampecol_licht:FILTER=STATE=off on
Lampe an, Sonos spielt
Im Log:
2021.04.22 22:26:53 1: [homezone - wc_zone]: Command execution failed: Unknown command night:set, try help.
2021.04.22 22:26:53 1: [homezone - wc_zone]: Perl execution failed: Unknown command night:set, try help.
Steh ich denn so aufm Schlauch?
VG Sebastian
PS:Bei 1 von 3 aktiven Zonen sind immer noch associated with doppelt, bei einer Zone wird es korrekt angezeigt und bei
der dritten Zone werden gar keine angezeigt.
Hi Sebastian,
ist mir irgendwie auch ein Rätsel... kannst du mal die Raw Definition der Zone posten? Dann baue ich mir einen Lampen- und einen Sonos-Dummy und stelle das nach...
Danke,
Oli
EDIT: Die associatedWith werden aktualisiert, wenn die relevanten Attribute (cmds und events) bearbeitet werden.
Zitat von: KernSani am 22 April 2021, 23:05:54
Hi Sebastian,
ist mir irgendwie auch ein Rätsel... kannst du mal die Raw Definition der Zone posten? Dann baue ich mir einen Lampen- und einen Sonos-Dummy und stelle das nach...
Danke,
Oli
EDIT: Die associatedWith werden aktualisiert, wenn die relevanten Attribute (cmds und events) bearbeitet werden.
Moin Oli,
hier die Zone:
defmod wc_zone homezone
attr wc_zone userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss :textField-long :textField-long :textField-long :textField-long hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
attr wc_zone hz_absenceEvent Wohnung:presence:.absent
attr wc_zone hz_closedEvent wc_huesens_door:state:.closed
attr wc_zone hz_cmd_absent set wc_lampecol_licht:FILTER=STATE=on off;; set play1_wc:FILTER=transportState=PLAYING pause;;\
night:set wc_lampecol_licht:FILTER=STATE=on off
attr wc_zone hz_cmd_likely set wc_lampecol_licht:FILTER=STATE=off on;; set play1_wc:FILTER=transportState=STOPPED play;;\
night:set wc_lampecol_licht:FILTER=STATE=off on
attr wc_zone hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr wc_zone hz_decay 150
attr wc_zone hz_decay_night 90
attr wc_zone hz_luminanceReading wc_huesens_light:lux
attr wc_zone hz_occupancyEvent wc_bwm:state:.motion
attr wc_zone hz_openEvent wc_huesens_door:state:.open
attr wc_zone hz_state 100:present 50:likely 1:unlikely 0:absent
Ich habe ja hier die cmds exzessiv geändert - aber associated with bleibt leer!
VG Sebastian
Bin jetzt in o.g. Zone wieder zurück ohne Tageszeit-cmd:
set wc_lampecol_licht:FILTER=onoff=0 on; {sonosbwm('likely','play1_wc')}
Das wird korrekt ausgeführt und associatedWith wird korrekt gefüllt.
Tippe mal es gibt Probleme das cmd mit Zeilenumbruch korrekt auszuwerten.
Alternativ wären halt einzelen user-attr für die Zeiten. Ja ich weiß, es sind schon viele und unter
umständen würden noch mehr dazu kommen... ::)
Da ich tatsächlich eher eine Prüfung auf asleep benötigen würde, mache ich das dann auch weiter in der Funktion und ohne Tageszeit-cmd.
VG Sebastian
Mir kommt da noch ein Gedanke... Zeilenumbrüche - Windows? Aber dein FHEM läuft sicher nicht unter Windows, oder?
Zitat von: KernSani am 23 April 2021, 17:45:49
Mir kommt da noch ein Gedanke... Zeilenumbrüche - Windows? Aber dein FHEM läuft sicher nicht unter Windows, oder?
Nein, Ubuntu
Also bei mir läuft die aktuelle Variante seit Tagen ohne Probleme.
Nutze die Tageszeit abhängigen cmds noch nicht.
Ich habe ein kleines Verständnisproblem und zwar schalten bei mir die Zonen
nicht auf present sondern lediglich auf likely
Meine beiden angelegten zonen
defmod flur_zone homezone
attr flur_zone userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
attr flur_zone DbLogExclude .*
attr flur_zone DbLogInclude present,absent
attr flur_zone devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
attr flur_zone hz_absenceEvent HausBewohner:presence:absent
attr flur_zone hz_adjacent obenflur_zone
attr flur_zone hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr flur_zone hz_decay 200
attr flur_zone hz_luminanceReading innen_bewegung:brightness
attr flur_zone hz_occupancyEvent flur_bewegung:state:.motion
attr flur_zone hz_state 100:present 50:likely 1:unlikely 0:absent
attr flur_zone icon floor
attr flur_zone room Status
defmod wohnz_zone homezone
attr wohnz_zone userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
attr wohnz_zone DbLogExclude .*
attr wohnz_zone devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
attr wohnz_zone hz_absenceEvent HausBewohner:presence:.absent
attr wohnz_zone hz_adjacent flur_zone,garten_zone
attr wohnz_zone hz_cmd_present set rr_andre location wohnzimmer
attr wohnz_zone hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr wohnz_zone hz_decay 300
attr wohnz_zone hz_luminanceReading innen_bewegung:brightness
attr wohnz_zone hz_occupancyEvent innen_bewegung:state:.motion
attr wohnz_zone hz_openEvent lgtv:state:present
attr wohnz_zone hz_state 100:present 50:likely 1:unlikely 0:absent
attr wohnz_zone icon floor
attr wohnz_zone room Status
Andre
Das habe ich auch meist, dass nicht auf 100% geschalten wird sondern auf 99% und dann auf likely
Daher wird mein command auch auf likely ausgeführt.
Vielleicht kannst Du auch einfach die Grenzwerte verschieben und 99 noch auf present setzen.
Aus der ersten Beitrag:
Zitathz_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)
Hast du ein Beispiel wie das bei dir konfiguriert ist.
Wann ist denn eine 100 % Anwesenheit gegeben was ist
im Device einzustellen....
Andre
Zitat von: andre07 am 27 Mai 2021, 23:34:03
Hast du ein Beispiel wie das bei dir konfiguriert ist.
Wann ist denn eine 100 % Anwesenheit gegeben was ist
im Device einzustellen....
Andre
Kurz gesagt ist die Idee, dass eine sichere Anwesenheit (100%) nur gegeben ist, wenn in einem geschlossenen Raum Bewegung erkannt wird. Solange der Raum dann nicht geöffnet wird, bleibt die Anwesenheit auf 100%. Wenn ein Raum offen ist, gibt es eine gewisse (sehr kleine, oder - je nach abgelaufener Zeit seit der letzten Bewegung - größere) Unsicherheit ob noch jemand anwesend ist, die durch den "Countdown" dargestellt wird.
Bewegung wird ja erkannt und zone springt nun auf likely. Um eine 100% Anwesenheit zu erreichen bräuchte ich dann noch einen
Türkontakt der geschlossen sein muss.Kann man das auch irgendwie anders lösen manchmal steht ja auch die Tür offen und ich
sitze im Wohnzimmer und schaue TV.
also du musst die Zone schließen und dann muss es Bewegung geben.
Das Geschlossen-Event kann aber alles ein.
D.h. z.B. Messstecker an deinen TV:
wenn
Verbrauch > 5 Watt (also TV an)
dann
Zone schließen, Anwesenheit auf 100% setzen
und dann halt Zone wieder auf, wenn Verbrauch < 5 Watt.
Mach ich genau so, da wir ein offenen TV/Leben Bereich haben.
Es gibt eine Zone "Leben", welche sich aus den Zonen "Küche", "Esstisch" und "TV" zusammensetzt.
Kannst dann halt keine Warnung aussprechen, dass die Glotze läuft und keiner zusieht.
Ich habe einfach meine Harmony genutzt.
Hierfür nutze ich einen Dummy der in geht, wenn die Harmony nicht aus ist..
Und dann nutze ich ob des Dummys als closed und den Off als opened. Somit ist meine Fernsehecke (als eine Homezone die die Zone Wohnzimmer steuert) dann closed, wenn mein Fernseher an ist. Sehr praktisch
Hallo
Habe das seit einiger Zeit das hier im log stehen
PERL WARNING: Deep recursion on subroutine "main::homezone_setOcc" at ./FHEM/98_homezone.pm line 527.
2021.06.12 09:52:37.485 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_homezone.pm line 428.
2021.06.12 09:52:37.485 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1117.
2021.06.12 09:52:37.485 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at fhem.pl line 1266.
2021.06.12 09:52:37.485 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1971.
2021.06.12 09:52:37.485 1: PERL WARNING: Deep recursion on subroutine "main::homezone_Set" at fhem.pl line 3888.
Die Syntax ist doch schon richtig "set licht off"
Außerdem ist mir aufgefallen das die Device die ich in der Zone definiert habe einfach
in "PROBABLY ASSOCIATED WITH" verschwinden erst nachdem ich sie wieder neu definiert habe erscheinen
sie dort wieder
Andre
Hi,
erstmal: tolles Modul und ich versuche mich da grade reinzufuchsen. Eine Frage habe ich aber. Ich habe an jeder Treppe auf der ersten und letzten Stufe einen Bewegungsmelder, der das Treppenlicht einschaltet, egal ob man von unten nach oben oder umgekehrt geht. Da man anhand der Auslöserreihenfolge erkennen kann, ob jemand von unten nach oben oder von oben nach unten geht, frage ich mich, ob ich das mit deinem Modul auch irgendwie darstellen kann.
Eine Idee?
Hallo,
ich habe ein Problem bei der Installation. Beim "reload 98_homezone" kommt der Fehler:Can't locate List/MoreUtils.pm in @INC (you may need to install the List::MoreUtils module) (@INC contains: ./FHEM/lib ./lib ./FHEM . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 /usr/lib/x86_64-linux-gnu/perl-base) at ./FHEM/98_homezone.pm line 80.
BEGIN failed--compilation aborted at ./FHEM/98_homezone.pm line 80.
Muss ich "List" und/oder "MoreUtils" erst installieren?
Und wenn ja, wie?
Vielen Dank
Zitat von: erdnar am 17 Juli 2021, 17:05:32
Muss ich "List" und/oder "MoreUtils" erst installieren?
Ja, du musst List::MoreUtils noch installieren. Wenn du Debian/Raspbian/Ubuntu/o.ä. verwendest, reicht es wahrscheinlich folgendes (über SSH) auszuführen:
sudo apt-get update && sudo apt-get install liblist-moreutils-perl
Zitat von: passibe am 18 Juli 2021, 22:53:19
Ja, du musst List::MoreUtils noch installieren. Wenn du Debian/Raspbian/Ubuntu/o.ä. verwendest, reicht es wahrscheinlich folgendes (über SSH) auszuführen:
sudo apt-get update && sudo apt-get install liblist-moreutils-perl
Danke,
probiere ich heute gleich aus.
Hallo zusammen,
ich habe seit Neustem das folgende im Log zu einer HomeZone:
2021.11.05 15:54:14 1: [homezone - hz_EG_FL]: Command execution failed: Unknown command evening:set, try help.
2021.11.05 15:54:14 1: [homezone - hz_EG_FL]: Perl execution failed: Unknown command evening:set, try help.
List der Zone:
STATE absent
| Timer: 0
TYPE homezone
VERSION 0.0.21
HELPER:
doors 0
READINGS:
2021-11-05 15:30:18 associatedWith HUEDevice7 HUEDevice7 HUEDevice7
2021-11-05 16:40:37 lastDayTime afternoon
2021-11-05 16:40:37 lastLumi 0
2021-11-05 16:40:37 lastZone timer
2021-11-05 16:40:37 occupied 0
2021-11-05 16:40:37 state absent
helper:
TIMER 1636126837
Attributes:
devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
hz_cmd_absent set HUEDevice7 off
hz_cmd_likely evening:set HUEDevice7 pct 30
morning:set HUEDevice7 pct 80
hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
hz_decay 120
hz_doAlways 1
hz_lumiThreshold_likely :3
hz_luminanceReading EG_FL_MS_LL:lux
hz_occupancyEvent EG_FL_MS:state:.motion,OG_TH_MS:state:.motion
hz_state 100:present 50:likely 1:unlikely 0:absent
room 1_test
stateFormat state
| Timer: occupied
userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
Wollte das noch mal nach oben bringen... habe noch immer diese Meldungen...
2022.01.07 17:07:43 1 : [homezone - hz_EG_FL]: Command execution failed: Unknown command evening:set, try help.
2022.01.07 17:07:43 1 : [homezone - hz_EG_FL]: Perl execution failed: Unknown command evening:set, try help.
2022.01.07 17:07:49 1 : [homezone - hz_EG_FL]: Command execution failed: Unknown command evening:set, try help.
2022.01.07 17:07:49 1 : [homezone - hz_EG_FL]: Perl execution failed: Unknown command evening:set, try help.
Hallo zusammen,
gibt es noch Entwicklung bei der HomeZone? Ich habe die für jeden Raum bei mir in Nutzung und bin bis auf ein Thema sehr zufrieden.
Ich möchte, dass ein Raum, den ich verlasse, aber die Tür hinter mir schließe der Countdown läuft. Ich möchte das die Zone auf closed geht und occupied wenn nach schließen der Tür Bewegung erkannt wird.
Geht das irgendwie? Oder wäre das ein neues Feature?
Sebastian
Hi Sebastian,
an Homezone habe ich schon sehr lange nichts mehr gemacht... Versuche gerade nachzudenken, wie das alles zusammenpasst...
Du bist in einem Raum - occupied ist bei < 100 - du verlässt den Raum und schliesst die Tür. Damit sollte der Countdown eigentlich weiter laufen. Wenn jetzt in dem geschlossenen Raum Bewegung erkannt wird, geht er auf 100 und bleibt da, bis die Tür wieder aufgeht - so sollte es zumindest sein, wenn ich darüber nachdenke. Also entweder habe ich deine Frage nicht verstanden, oder ich habe einen Denkfehler. Kannst du mir auf die Sprünge helfen?
Grüße,
Oli
Hi Oli,
dann wirds ja mal wieder Zeit ;-)
Ich habe foglendes szenario.
Ein Zimmer mit Bewegungsmelder und Tür Kontakt.
Ich verlasse den Raum und schließe die Tür.
Die Zone zeigt kurz Likely 99
Dann nach ca. 10 Sekunden wechselt wie auf Closed 100
Ich bin mir nicht sicher, ob der Bewegungsmelder das versursacht, wenn er auf Nomotion geht. Darauf trigger ich nicht in der Zone.
define hz_DG_AZ homezone
attr hz_DG_AZ userattr hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night
attr hz_DG_AZ devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
attr hz_DG_AZ hz_absenceEvent DG_AZ_WS:.off
attr hz_DG_AZ hz_closedEvent DG_AZ_TK:state:.closed
attr hz_DG_AZ hz_cmd_absent set ST_DG_AZ_Licht,HUEGroup26 off
attr hz_DG_AZ hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr hz_DG_AZ hz_decay 300
attr hz_DG_AZ hz_luminanceReading DG_AZ_PM:1.CURRENT_ILLUMINATION
attr hz_DG_AZ hz_occupancyEvent DG_AZ_PM:hmstate:.yes
attr hz_DG_AZ hz_openEvent DG_AZ_TK:state:.open
attr hz_DG_AZ hz_state 100:present 50:likely 1:unlikely 0:absent
attr hz_DG_AZ room 1_test
attr hz_DG_AZ sortby 10
attr hz_DG_AZ stateFormat state \
| Timer: occupied | condition
# FUUID 5ecece28-f33f-0992-10ff-499f62f545976403
# NAME hz_DG_AZ
# NR 142
# NTFY_ORDER 50-hz_DG_AZ
# STATE present
#| Timer: 100 | closed
# TYPE homezone
# VERSION 0.0.21
# eventCount 6382
# HELPER:
# doors 1
# READINGS:
# 2023-02-16 00:38:22 associatedWith DG_AZ_TK DG_AZ_WS
# 2023-02-17 13:23:13 condition closed
# 2023-02-16 00:37:21 door1 closed
# 2023-02-16 00:37:06 door2 open
# 2023-02-17 13:25:08 lastDayTime day
# 2023-02-17 13:25:08 lastLumi 42.6
# 2023-02-17 13:25:08 lastZone self
# 2023-02-17 13:25:08 occupied 100
# 2023-02-17 13:25:08 state present
# helper:
# TIMER 1676636617
# hmccu:
#
setstate hz_DG_AZ present \
| Timer: 100 | closed
setstate hz_DG_AZ 2023-02-16 00:38:22 associatedWith DG_AZ_TK DG_AZ_WS
setstate hz_DG_AZ 2023-02-17 13:23:13 condition closed
setstate hz_DG_AZ 2023-02-16 00:37:21 door1 closed
setstate hz_DG_AZ 2023-02-16 00:37:06 door2 open
setstate hz_DG_AZ 2023-02-17 13:25:08 lastDayTime day
setstate hz_DG_AZ 2023-02-17 13:25:08 lastLumi 42.6
setstate hz_DG_AZ 2023-02-17 13:25:08 lastZone self
setstate hz_DG_AZ 2023-02-17 13:25:08 occupied 100
setstate hz_DG_AZ 2023-02-17 13:25:08 state present
ZitatIch habe foglendes szenario.
Ein Zimmer mit Bewegungsmelder und Tür Kontakt.
Hallo Sebastian,
das gleiche Szenario habe ich im Bad und im Gäste-WC. Ich habe im Event-Monitor mal mitgeschnitten und mit Kommentaren versehen:
# Tür auf
2023-02-17 13:38:44.524 homezone wc_zone condition: open
# BWM löst aus
2023-02-17 13:38:46.470 homezone wc_zone occupied: 99
2023-02-17 13:38:46.470 homezone wc_zone likely
2023-02-17 13:38:46.470 homezone wc_zone lastZone: self
# Tür zu
2023-02-17 13:38:48.456 homezone wc_zone condition: closed
2023-02-17 13:38:58.021 homezone wc_zone occupied: 90
2023-02-17 13:38:58.021 homezone wc_zone lastLumi: 79
2023-02-17 13:38:58.021 homezone wc_zone lastZone: timer
2023-02-17 13:39:10.018 homezone wc_zone occupied: 80
2023-02-17 13:39:22.020 homezone wc_zone occupied: 70
2023-02-17 13:39:34.025 homezone wc_zone occupied: 60
2023-02-17 13:39:46.016 homezone wc_zone occupied: 50
# BWM löst erneut aus
2023-02-17 13:39:57.478 homezone wc_zone occupied: 100
2023-02-17 13:39:57.478 homezone wc_zone present
2023-02-17 13:39:57.478 homezone wc_zone lastZone: self
# Tür auf
2023-02-17 13:40:07.197 homezone wc_zone condition: open
2023-02-17 13:40:07.223 homezone wc_zone occupied: 99
2023-02-17 13:40:07.223 homezone wc_zone likely
2023-02-17 13:40:11.241 homezone wc_zone condition: closed
2023-02-17 13:40:19.018 homezone wc_zone occupied: 90
2023-02-17 13:40:19.018 homezone wc_zone lastZone: timer
2023-02-17 13:40:31.016 homezone wc_zone occupied: 80
2023-02-17 13:40:43.017 homezone wc_zone occupied: 70
2023-02-17 13:40:55.019 homezone wc_zone occupied: 60
2023-02-17 13:41:07.018 homezone wc_zone occupied: 50
2023-02-17 13:41:19.019 homezone wc_zone occupied: 40
2023-02-17 13:41:19.019 homezone wc_zone unlikely
2023-02-17 13:41:31.019 homezone wc_zone occupied: 30
2023-02-17 13:41:43.024 homezone wc_zone occupied: 20
2023-02-17 13:41:55.019 homezone wc_zone occupied: 10
2023-02-17 13:42:07.035 homezone wc_zone occupied: 0
2023-02-17 13:42:07.035 homezone wc_zone absentDas ist genau das von Oli beschriebene Verhalten.
Hier noch die Zone:
defmod wc_zone homezone
attr wc_zone userattr hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss :textField-long :textField-long :textField-long :textField-long hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night hz_decay_backup
attr wc_zone hz_absenceEvent Wohnung:presence:.absent
attr wc_zone hz_closedEvent wc_huesens_door:state:.closed
attr wc_zone hz_cmd_absent zonecmd $name absent;; bwmmusic $name absent;;
attr wc_zone hz_cmd_likely zonecmd $name likely;; bwmmusic $name likely;;
attr wc_zone hz_cmd_present zonecmd $name present;;
attr wc_zone hz_decay 120
attr wc_zone hz_luminanceReading wc_sens_light:lux
attr wc_zone hz_occupancyEvent wc_bwm:state:.motion
attr wc_zone hz_openEvent wc_huesens_door:state:.open
attr wc_zone hz_state 100:present 50:likely 1:unlikely 0:absent
VG Sebastian
Hallo KernSani,
Klasse Modul!! Habe es auch schon lange erfolgreich im Einsatz.
Es müsste erfunden werden, wenn es das Modul noch nicht gäbe...
Für mich gehört das Modul in das offizielle Repository!
Viele Grüße
Reiner
Hab gerade mal geguckt, in meinem WC und Badezimmer funktioniert es auch wie gewünscht.
Ich schmeiß mal den Eventmonitor an und guck, was da noch so triggert.
Das ist wirlich schräg...
Im log der zone folgendes:
2023-02-17 16:03:04 homezone hz_DG_AZ condition: closed
2023-02-17 16:03:04 homezone hz_DG_AZ occupied: 100
2023-02-17 16:03:04 homezone hz_DG_AZ present
2023-02-17 16:03:04 homezone hz_DG_AZ lastZone: self
2023-02-17 16:03:04 homezone hz_DG_AZ occupied: 100
2023-02-17 16:03:04 homezone hz_DG_AZ present
2023-02-17 16:03:04 homezone hz_DG_AZ lastZone: self
# ich mache die Tür auf und gehe aus dem Raum
2023-02-17 16:03:05 homezone hz_DG_AZ condition: open
2023-02-17 16:03:05 homezone hz_DG_AZ occupied: 99
2023-02-17 16:03:05 homezone hz_DG_AZ likely
2023-02-17 16:03:05 homezone hz_DG_AZ lastZone: self
2023-02-17 16:03:05 homezone hz_DG_AZ condition: open
2023-02-17 16:03:06 homezone hz_DG_AZ condition: open
2023-02-17 16:03:08 homezone hz_DG_AZ condition: open
#Tür zu, ich draußen
2023-02-17 16:03:08 homezone hz_DG_AZ condition: closed
2023-02-17 16:03:08 homezone hz_DG_AZ condition: closed
2023-02-17 16:03:33 homezone hz_DG_AZ occupied: 100
2023-02-17 16:03:33 homezone hz_DG_AZ present
2023-02-17 16:03:33 homezone hz_DG_AZ lastZone: self
2023-02-17 16:04:09 homezone hz_DG_AZ condition: closed
# Ich mache die Tür auf und betrete den Raum
2023-02-17 16:04:10 homezone hz_DG_AZ condition: open
2023-02-17 16:04:10 homezone hz_DG_AZ occupied: 99
2023-02-17 16:04:10 homezone hz_DG_AZ likely
2023-02-17 16:04:10 homezone hz_DG_AZ lastZone: self
2023-02-17 16:04:10 homezone hz_DG_AZ condition: open
2023-02-17 16:04:12 homezone hz_DG_AZ condition: open
2023-02-17 16:04:13 homezone hz_DG_AZ condition: closed
2023-02-17 16:04:13 homezone hz_DG_AZ condition: closed
#ich bin im Raum und werde vom Bewegungmelder erfasst
2023-02-17 16:04:15 homezone hz_DG_AZ occupied: 100
2023-02-17 16:04:15 homezone hz_DG_AZ present
2023-02-17 16:04:15 homezone hz_DG_AZ lastZone: self
2023-02-17 16:04:30 homezone hz_DG_AZ occupied: 100
2023-02-17 16:04:30 homezone hz_DG_AZ present
2023-02-17 16:04:30 homezone hz_DG_AZ lastZone: self
2023-02-17 16:04:30 homezone hz_DG_AZ occupied: 100
2023-02-17 16:04:30 homezone hz_DG_AZ present
2023-02-17 16:04:30 homezone hz_DG_AZ lastZone: self
Zum gleichen Zeitraum loggt der Bewegungsmelder:
023-02-17 16:03:04 HMCCUDEV DG_AZ_PM devstate: ok
2023-02-17 16:03:04 HMCCUDEV DG_AZ_PM hmstate: yes
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM activity: alive
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM voltage: 2.4
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM sabotage: false
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM rssidevice: -65
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM battery: ok
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM devstate: ok
[b]2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM hmstate: yes[/b]
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM no
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM 1.PRESENCE_DETECTION_STATE: no
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM presence: no
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM 1.ILLUMINATION_STATUS: NORMAL
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM 1.ILLUMINATION: 153.3
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM brightness: 153.3
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM control: on
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM 1.PRESENCE_DETECTION_ACTIVE: on
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM detection: on
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM devstate: ok
2023-02-17 16:03:33 HMCCUDEV DG_AZ_PM hmstate: no
ich guck mal ob ich mit Timestamp-on-change-reading was erreiche.
Das hat geholfen...
attr DG_AZ_PM event-on-change-reading .*
attr DG_AZ_PM timestamp-on-change-reading hmstate
in den anderen Beiden Räumen sind es keine HM Melder, sondern von Aqara
Hallo zusammen again :-)
ich würde gerne bei ein paar Zonen einen "manuellen" Modus einbauen, bzw. die aktivität kurz aussetzen.
Ich möchte einen Button drücken und die Zone führt keine Aktivitäten wie "Licht an" oder "Licht aus" aus.
Z.B. im Flur geht das Licht öfters mal aus, wenn man dort steht und sich unterhält. Wenn man sich kaum bewegt, bekommt der Bewegungsmelder das nicht mit. Ergo licht geht nach 5 min aus.
Ich möcht nun einen Button und/oder Sprachbefehl absetzen der die Zone in einem manuellen Modus versetzt.
Soll ich die Zone einfach auf inactive setzen oder gibts da bessere Möglichkeiten?
Ich würde mir einfach einen Dummy bauen, als Schalter definieren, damit ich ihn via Alexa schalten kann. Ein doif greift den Status ab und setzt die Zone.
Schön wäre noch eine dauer, die ich mit übergeben könnte. Aka "Alexa schalte Flur auf manuell für 20 minute"
Im Notfall würde ich eine Routine in Alexa bauen, die nach 20 min einfach wieder auf Auto stellt. Schön ist das nicht.
Ideen?
Ich denke "inactive" setzen wäre der einfachste Weg. Viel schlaueres fällt mir jetzt auch nicht ein...
ZitatSoll ich die Zone einfach auf inactive setzen oder gibts da bessere Möglichkeiten?
Das hätte den Vorteil das beim erneuten Aktivieren der Zone diese automatisch auf 'absent' gesetzt wird.
ZitatIch würde mir einfach einen Dummy bauen...
So hab ich das bei mir auch realisiert und damit nebenbei die gesamte Licht- u. Zonensteuerung parametrisiert.
Der dummy wird off gesetzt wenn ich einen Lichtschalter in einer BWM-Zone einschalte und auf off
wenn ich das Licht wieder ausschalte. Damit geht die Zone wieder auf active und absent.
Damit könnte man auch zB. die Zone temporär deaktivieren (off-for-timer).
Hier ein RAW-Bsp:
defmod wc_autolicht.d dummy
attr wc_autolicht.d alias WC
attr wc_autolicht.d devStateIcon on:ios-on-blue:off off:ios-off:on
attr wc_autolicht.d icon light_light_dim_100
attr wc_autolicht.d readingList decay mode target_lux target_twi
attr wc_autolicht.d setList target_twi:slider,0,1,6 target_lux:slider,0,5,100 mode:bwm,auto,off decay:short,medium,long on off
attr wc_autolicht.d stateFormat state
attr wc_autolicht.d useSetExtensions 1
attr wc_autolicht.d webCmd target_lux:target_twi:mode:decayVG Sebastian
Zitat von: slor am 02 März 2023, 14:18:56Hallo zusammen again :-)
...
Ideen?
Statt auszuschalten dimme ich die Lampen auf 0.
Damit hat jeder die Gelegenheit sich beim BWM "bemerkbar" zu machen, ohne plötzlich im Dunkeln zu stehen und ohne vorher wissen zu müssen dass der Besuch die Verabschiedung im Flur doch wieder endlos ausdehnt :-\ .
Grüße
ErdnaR
ZitatStatt auszuschalten dimme ich die Lampen auf 0.
Das bedingt aber auch immer dass das Leuchtmittel das sauber unterstützt.
Leider ist das aber nicht immer der Fall... ;)
Ansonsten gebe ich dir vollkommen recht! 👍🏻