Zonen-basierte Anwesenheitserkennung und -steuerung

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

Vorheriges Thema - Nächstes Thema

binford6000

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

KernSani

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

enno

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
Einfacher FHEM Anwender auf Intel®NUC

KernSani

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

binford6000

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|night

Füge ich dort weitere Zeiten hinzu (zB. 14:30|Nachmittag) so wird ebenfalls ein weiteres userattr HomeCMDdaytime-Nachmittag
hinzugefügt.

VG Sebastian


KernSani

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

KernSani

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

KernSani

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

binford6000

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

KernSani

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

binford6000

#25
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_night


VG Sebastian

KernSani

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

binford6000

Zitatoder ohne zu ändern den "attr" Knopf drückst?

Das wars. Danke.
VG Sebastian


patlabor

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

KernSani

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