Neues Modul: 22_HOMEMODE.pm - grundlegende Automationen und mehr

[DeeSPe]

Hallo Dan,

danke für die Debug-Vorschläge.
Erkenntnis #1:
Es gibt tatsächlich Events, die einen abweichenden Batteriestand melden. Ob das Aufgrund meines userReadings passiert oder eine Auffälligkeit mit MAX ist, werde ich weiter ergründen.

Erkenntnis #2:
Der "BatteryNormal" Event in HomeMode scheint die gesetzte Nachricht nicht zu löschen. Hier das Output:

Code Auswählen Erweitern

2020.01.22 06:18:01 1: DEBUG: wt_Schlafzimmer - batteryPercent: 25
2020.01.22 06:18:01 5: HomeStatus: Events from monitored device wt_Schlafzimmer: battery: low --- batteryState: low --- batteryPercent: 25
2020.01.22 06:18:01 5: HomeStatus: cmdnew: {  my $msg;  $msg = "Die Batterien von %BATTERYLOW% gehen zur Neige und sollten ausgetauscht werden!" if (%BATTERYLOWCT% == 1);  $msg = "Die Batterien bei folgenden Geräten sollten ausgetauscht werden %BATTERYLOWALL%" if (%BATTERYLOWCT% > 1);  fhem( "defmod warn_battery_low at 20:30:00 msg audio $msg" ); }
2020.01.22 06:18:01 5: HomeStatus: Events from monitored device global: MODIFIED warn_battery_low
2020.01.22 06:18:01 4: HomeStatus: executed CMDs: {  my $msg;;  $msg = "Die Batterien von Temperatur Schlafzimmer gehen zur Neige und sollten ausgetauscht werden!" if (1 == 1);;  $msg = "Die Batterien bei folgenden Geräten sollten ausgetauscht werden Temperatur Schlafzimmer" if (1 > 1);;  fhem( "defmod warn_battery_low at 20:30:00 msg audio $msg" );; }
...
2020.01.22 06:21:01 1: DEBUG: wt_Schlafzimmer - batteryPercent: 100
2020.01.22 06:21:01 5: HomeStatus: Events from monitored device wt_Schlafzimmer: battery: ok --- batteryState: ok --- batteryPercent: 100


Alex

Hallo Alex,

zu Erkenntnis #1:
Ich glaube eigentlich nicht dass es an dem userReading liegt. Kannst Du bitte mal den Code davon zeigen?

zu Erkenntnis #2:
Bei mir funktioniert das einwandfrei, habe es soeben noch einmal in meiner Testumgebung durchgespielt.

2020-01-22 14:46:24.591 HOMEMODE HM batteryLow: SensorA
2020-01-22 14:46:24.591 HOMEMODE HM batteryLow_ct: 1
2020-01-22 14:46:24.591 HOMEMODE HM batteryLow_hr: Aussensensor
2020.01.22 14:46:24.594 1:  DEBUG>Die Batterien von Aussensensor gehen zur Neige und sollten ausgetauscht werden!
2020-01-22 14:46:24.595 dummy SensorA battery: low
2020-01-22 14:46:36.531 HOMEMODE HM batteryLow:
2020-01-22 14:46:36.531 HOMEMODE HM batteryLow_ct: 0
2020-01-22 14:46:36.531 HOMEMODE HM batteryLow_hr:
2020.01.22 14:46:36.532 1:  DEBUG>Anzahl niedriger Batterien 0
2020-01-22 14:46:36.533 dummy SensorA battery: ok

Ich weiß ehrlich gesagt im Moment nicht so richtig wo ich ansetzen soll, zumal Du (bisher) der Einzige bist mit diesem Problem.

Gruß
Dan

[dk3572]

Hallo Dieter,

leider habe ich noch so gar keine Idee woran es liegen könnte.
Benutzt Du evtl. mehrere fhem.cfg Dateien mit entsprechenden includes?

Verlieren die auch HomeOpenTimes und HomeOpenTimeDeviders oder nur HomeOpenTimes und HomeOpenTimeDeviders?
Habe mir gerade noch einmal den Code dazu angesehen. Es müssen entweder alle Home... Attribute vorhanden sein, oder überhaupt keines.

Gruß
Dan

Hallo Dan,

ich benutze nur eine fhem.cfg und sie verlieren nur HomeOpenTimes und HomeOpenTimeDeviders.

EDIT. Ich muss mich korrigieren, bei 2 Kontakten war auch HomeOpenMaxTrigger, HomeOpenTimeDividers und HomeOpenTimes verschwunden.
        HomeContactType und HomeModeAlarmActive bleiben immer bestehen.

Gruß Dieter

[DeeSPe]

Hallo Dan,

ich benutze nur eine fhem.cfg und sie verlieren nur HomeOpenTimes und HomeOpenTimeDeviders.

EDIT. Ich muss mich korrigieren, bei 2 Kontakten war auch HomeOpenMaxTrigger, HomeOpenTimeDividers und HomeOpenTimes verschwunden.
        HomeContactType und HomeModeAlarmActive bleiben immer bestehen.

Gruß Dieter

Das ist mir mehr als rätselhaft und ich glaube mittlerweile dass es kein Problem von HOMEMODE selbst ist, denn der Code für die userattr setzt entweder alle Home... userattr oder überhaupt keines.
Auch beim Entfernen der userattr werden entweder alle Home... userattr entfernt oder gar keines.

Mach mal bitte einen Test:
Bitte starte FHEM neu, aktiviere die Sensoren in HOMEMODE wieder per "updateInternalsForce", danach die fhem.cfg speichern und nun den FHEM Dienst stoppen.
Jetzt bitte mal (bei gestopptem FHEM) in der fhem.cfg die Sensoren suchen bei denen die userattr vorher fehlten und nachsehen ob die userattr nun in der Datei zu finden sind.
Wenn die useattr dann wirklich vorhanden sind scheint irgendetwas beim Start von FHEM diese Attribute zu verändern. Evtl. könntest Du das mal testen mit einem notify auf global:ATTR.

Code Auswählen Erweitern

defmod n_global_ATTR notify global:ATTR.* {Debug $EVENT}
Das erzeugt dann eine Zeile im Log die sich wiederfinden lassen sollte.
Die Zeile beginnt nach dem Zeitstempel mit "1:  DEBUG>ATTR ".

Gruß
Dan

[dk3572]

Das ist mir mehr als rätselhaft und ich glaube mittlerweile dass es kein Problem von HOMEMODE selbst ist, denn der Code für die userattr setzt entweder alle Home... userattr oder überhaupt keines.
Auch beim Entfernen der userattr werden entweder alle Home... userattr entfernt oder gar keines.

Mach mal bitte einen Test:
Bitte starte FHEM neu, aktiviere die Sensoren in HOMEMODE wieder per "updateInternalsForce", danach die fhem.cfg speichern und nun den FHEM Dienst stoppen.
Jetzt bitte mal (bei gestopptem FHEM) in der fhem.cfg die Sensoren suchen bei denen die userattr vorher fehlten und nachsehen ob die userattr nun in der Datei zu finden sind.
Wenn die useattr dann wirklich vorhanden sind scheint irgendetwas beim Start von FHEM diese Attribute zu verändern. Evtl. könntest Du das mal testen mit einem notify auf global:ATTR.

Code Auswählen Erweitern

defmod n_global_ATTR notify global:ATTR.* {Debug $EVENT}
Das erzeugt dann eine Zeile im Log die sich wiederfinden lassen sollte.
Die Zeile beginnt nach dem Zeitstempel mit "1:  DEBUG>ATTR ".

Gruß
Dan

Hallo Dan,

habe jetzt fhem 2 mal neu gestartet. Jedes mal verliert HOMEMODE die besagten Kontakte.
Attribute wurden beide male keine gelöscht. Nur das userattr wird nach dem updateInternalsForce immer länger.

EDIT. Ich vermute es liegt am Einbinden der Sensoren mittels type=
         Habe einen mal per NAME= eingebunden und siehe da, die userattr werden nicht gedoppelt.

Gruß Dieter

[DeeSPe]

Hallo Dan,

habe jetzt fhem 2 mal neu gestartet. Jedes mal verliert HOMEMODE die besagten Kontakte.
Attribute wurden beide male keine gelöscht. Nur das userattr wird nach dem updateInternalsForce immer länger.

EDIT. Ich vermute es liegt am Einbinden der Sensoren mittels type=
         Habe einen mal per NAME= eingebunden und siehe da, die userattr werden nicht gedoppelt.

Gruß Dieter

Es ist mir nach wie vor rätselhaft.
Ob per TYPE= oder NAME= sollte völlig egal sein, denn sie durchlaufen beide die selbe devspec2array Funktion und auch alle nachfolgend aufgerufenen Funktionen sind identisch.
Langsam gehen mir wirklich die Ideen aus um das weiter zu debuggen...

Gruß
Dan

[dk3572]

Es ist mir nach wie vor rätselhaft.
Ob per TYPE= oder NAME= sollte völlig egal sein, denn sie durchlaufen beide die selbe devspec2array Funktion und auch alle nachfolgend aufgerufenen Funktionen sind identisch.
Langsam gehen mir wirklich die Ideen aus um das weiter zu debuggen...

Gruß
Dan

Nicht TYPE sondern type hatte ich verwendet. (type=ZHAOpenClose)
Bei TYPE steht ja HueDevice.
Oder macht das keinen Unterschied?

Code Auswählen Erweitern

Internals:
   DEF        sensor 13 1 IODev=deCONZ
   FUUID      5d406ed9-f33f-cd72-34c8-6769bbce549741a8
   FVERSION   31_HUEDevice.pm:0.209890/2020-01-15
   ID         S13
   INTERVAL   1
   IODev      deCONZ
   NAME       Garagentuer
   NR         329
   STATE      Initialized
   TYPE       HUEDevice
   lastupdated 2020-01-16 15:05:57
   lastupdated_local 2020-01-16 16:05:57
   manufacturername LUMI
   modelid    lumi.sensor_magnet.aq2
   name       Garagentür
   on         1
   reachable  1
   swversion  20161128
   type       ZHAOpenClose
   uniqueid   00:15:8d:00:03:1b:33:a1-01-0006
   READINGS:
     2020-01-16 15:23:19   battery         91
     2020-01-16 15:23:19   reachable       1
     2020-01-16 16:05:57   state           closed
     2020-01-16 15:23:19   temperatur_real 7
     2020-01-16 15:23:19   temperature     11
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     configList:
     json:
       ep         1
       etag       58680eb2aea34ab682b19d9ae420cfdb
       manufacturername LUMI
       modelid    lumi.sensor_magnet.aq2
       name       Garagentür
       swversion  20161128
       type       ZHAOpenClose
       uniqueid   00:15:8d:00:03:1b:33:a1-01-0006
       config:
         battery    91
         temperature 1100
       state:
         lastupdated 2020-01-16T15:05:57
     setList:
Attributes:
   HomeContactType dooroutside
   HomeModeAlarmActive armaway
   HomeOpenMaxTrigger 0
   IODev      deCONZ
   alexaName  Garagentür
   alexaRoom  Garten
   alias      Garagentür
   devStateIcon open:fts_door_right_open@#e56524 closed:fts_door_right
   genericDeviceType contact
   group      Fenster-/Türkontakte
   homebridgeMapping clear ContactSensorState:state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
   icon       fts_door_right
   room       Garten,HUEDevice
   stateFormat [$name:state]
[$name:temperatur_real] °C
   userReadings temperatur_real:temperature.* {ReadingsVal("Garagentuer","temperature","")-4}

   userattr   HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes

[DeeSPe]

Ob TYPE= oder type= oder NAME= spielt keine Rolle.
Das sind alles Internals.

Ich verstehe es einfach nicht.

Gruß
Dan

[dk3572]

Ob TYPE= oder type= oder NAME= spielt keine Rolle.
Das sind alles Internals.

Ich verstehe es einfach nicht.

Gruß
Dan

Merkwürdig ist auch das die Kontakte in HOMEMODE bei BATTERY.... mittels type=ZHAOpenClose nicht mehr gefunden werden.

[adn77]

zu Erkenntnis #2:
Bei mir funktioniert das einwandfrei, habe es soeben noch einmal in meiner Testumgebung durchgespielt.
Ich weiß ehrlich gesagt im Moment nicht so richtig wo ich ansetzen soll, zumal Du (bisher) der Einzige bist mit diesem Problem.

Das Problem saß mal wieder vor dem Rechner...  Es fehlte schlicht ein

Code Auswählen Erweitern

HomeCMDbatteryNormal, welches das "at" wieder löscht.

Danke Dan!

PS: Habe gerade einem c't Autor versucht zu erklären, wie in FHEM die Automatisierung gelöst ist (im Vergleich zu openHAB und ioBroker). Dabei diente dein hervorragendes Modul als perfektes Beispiel, wenn es etwas mehr sein soll als ein paar Notifys.

[Axel Asmussen]

Hallo Gemeinde - Das Homemode-Modul steckt ja voller toller Funktionen, echt tolle Arbeit
Ich versuche gerade die mannigfaltigen Funktionen ein bisschen mehr auszureizen.
Eine Frage habe ich dazu - die "HR"-Version von einigen Ersetzungen (z.B. %ALARMHR%) führt bei mir zu etwas grammatikalisch falschen Texten.
Beispiel: "Das Fensterkontakt Bad, das Fensterkontakt Felix und die Türverschluss Balkon vorn" ist ausgelöst
Wenn ich den Code im Modul - Funktion "HOMEMODE_makeHR" richtig verstehe, werden die Texte anhand der Bezeichnungen der Devices (Name/Alias) abgeleitet - Bei Tür im Namen kommt ein "die" davor ...
Das ist m.E. nicht ganz so glücklich  - auch ein Engländer wird damit vielleicht Probleme haben;)
Ich habe z.B. einen Türkontakt Haustür = HMIP-SWDO - der das "offen" erkennt, einen Türverschluss = HmIP-SRH der offen / kipp / geschlossen erkennt. (u.U. ist die Tür zwar zu, aber der Verschluss steht auf offen - Tür kann von außen aufgedrückt werden)
Sicher kann man die Namensgebung ändern - aber lässt sich das Bilden der HR-Texte für die verschiedenen Ersetzungsvariablen vielleicht irgendwie verschönern? (z.B. mit einem optionalen Attribut am Device, was beim Bilden des ALIAS genommen wird, wenn es da ist?)
Danke & noch ein schönes restliches Wochenende
Axel

[Diggewuff]

Das attribut HomePresenceDevicePresentCount scheint in Version 1.5.3 nicht richtig zu funktionieren.
Ich habe es auf 2 gesetzt (attr Home HomePresenceDevicePresentCount-rr_Sarah 2) und würde erwarten das der resident Status erst auf Home gesetzt wird, wenn mindestens 2 von 3 Presence Devices auf present stehen. Dies war allerdings schon bei der Meldung eines einzigen Devices (einer Fehlmeldung) der Fall.
Zudem ist der Status nach Weggang dieser Fehlmeldung auch nicht wieder auf absent gegangen. (attr Home HomePresenceDeviceAbsentCount-rr_Sarah 2).
Siehe braune Linie im Plot im Anhang.
Falls ich das Attribut falsch verstehe, würde ich mich über einen Hinweis freuen.

[DeeSPe]

Hallo Gemeinde - Das Homemode-Modul steckt ja voller toller Funktionen, echt tolle Arbeit
Ich versuche gerade die mannigfaltigen Funktionen ein bisschen mehr auszureizen.
Eine Frage habe ich dazu - die "HR"-Version von einigen Ersetzungen (z.B. %ALARMHR%) führt bei mir zu etwas grammatikalisch falschen Texten.
Beispiel: "Das Fensterkontakt Bad, das Fensterkontakt Felix und die Türverschluss Balkon vorn" ist ausgelöst
Wenn ich den Code im Modul - Funktion "HOMEMODE_makeHR" richtig verstehe, werden die Texte anhand der Bezeichnungen der Devices (Name/Alias) abgeleitet - Bei Tür im Namen kommt ein "die" davor ...
Das ist m.E. nicht ganz so glücklich  - auch ein Engländer wird damit vielleicht Probleme haben;)
Ich habe z.B. einen Türkontakt Haustür = HMIP-SWDO - der das "offen" erkennt, einen Türverschluss = HmIP-SRH der offen / kipp / geschlossen erkennt. (u.U. ist die Tür zwar zu, aber der Verschluss steht auf offen - Tür kann von außen aufgedrückt werden)
Sicher kann man die Namensgebung ändern - aber lässt sich das Bilden der HR-Texte für die verschiedenen Ersetzungsvariablen vielleicht irgendwie verschönern? (z.B. mit einem optionalen Attribut am Device, was beim Bilden des ALIAS genommen wird, wenn es da ist?)
Danke & noch ein schönes restliches Wochenende
Axel

Hallo Axel,

ich bin bei der Programmierung davon ausgegangen dass man seine Türen und Fenster nur als z.B. "Wohnzimmerfenster" bzw. "Eingangstür" benennt und nicht "Wohnzimmerfensterkontakt" und "Eingangstürkontakt". Man könnte jetzt ran gehen und allem was auf "...kontakt" endet den Artikel "der" verpassen, evtl. kommt dann aber wieder jemand der gern was am Ende zu stehen hat was wieder einen anderen Artikel erzeugen würde. Ein Engländer/Amerikaner dürfte hier weniger Probleme haben da es dort ja nur den Artikel "the" gibt.
Deinen Vorschlag das über ein Attribut vorzugeben wäre eine Möglichkeit. Ich schaffe es aber in der kommenden Zeit nicht das umzusetzen. Evtl. wäre das was für HOMEMODE 2.0.
HOMEMODE 2.0 wird es sicherlich irgendwann geben, nur fehlt mir auch dafür momentan die Zeit.

Wie auch immer, ich habe die Funktion "HOMEMODE_name2alias" etwas umgestaltet um auch "kontakt" gerecht zu werden.
Anbei die Version 1.5.4 zum Test. Ich bitte um Rückmeldung.

Gruß
Dan

[DeeSPe]

Das attribut HomePresenceDevicePresentCount scheint in Version 1.5.3 nicht richtig zu funktionieren.
Ich habe es auf 2 gesetzt (attr Home HomePresenceDevicePresentCount-rr_Sarah 2) und würde erwarten das der resident Status erst auf Home gesetzt wird, wenn mindestens 2 von 3 Presence Devices auf present stehen. Dies war allerdings schon bei der Meldung eines einzigen Devices (einer Fehlmeldung) der Fall.
Zudem ist der Status nach Weggang dieser Fehlmeldung auch nicht wieder auf absent gegangen. (attr Home HomePresenceDeviceAbsentCount-rr_Sarah 2).
Siehe braune Linie im Plot im Anhang.
Falls ich das Attribut falsch verstehe, würde ich mich über einen Hinweis freuen.

Hallo Diggewuff,

Deine Feststellung kann ich nicht bestätigen. In v1.5.3 wurde die Funktion auch überhaupt nicht angefasst. Ich wüsste überhaupt nicht dass ich an der Funktion nach der initialen Erstellung noch einmal dran gewesen bin.
Jedenfalls habe ich das eben in meinem Testsystem nachgestellt und es funktioniert wie angedacht.
Ich habe für meinen Benutzter 3 PRESENCE Devices angelegt und HomePresenceDevicePresentCount-rr_Dan auf 2 gestellt und HomePresenceDeviceAbsentCount-rr_Dan auf 3.
Sobald 2 meiner PRESENCE Devices auf present gehen wird mein ROOMMATE auf present gesetzt. Sobald alle 3 PRESENCE Devices auf absent gehen wird auch mein ROOMMATE auf absent gestellt.

Wenn das bei Dir nicht in dieser Form funktioniert, dann benötige ich bitte "verbose 5" Mitschnitte des Event-Monitors vom HOMEMODE Device zu den Zeitpunkten der Umschaltung der PRESENCE Devices.

Gruß
Dan

[Diggewuff]

Hallo DeSPe,

Danke dass du dich der Sache angenommen hast.
Mein HomePresenceDeviceAbsentCount steht allerdings ebenfalls auf 2 (nicht auf 3) da ein presence immer erst mit sehr starker Verzögerung auf absent geht. Das Verhalten ist dann unerwartet wie beschrieben. Und im Plot dargestellt. Würdest du das eventuell noch einmal verifizieren (beide Attribute auf 2)? Falls das Verhalten dennoch nicht reproduzierbar ist, würde ich eine Log5 Auswertung anstoßen.

[DeeSPe]

Soeben verifiziert und für gut befunden.

Habe nun beide Attribute auf 2 gestellt und sobald 2 auf absent sind geht auch mein ROOMMATE auf absent. Stelle ich den einen dann wieder auf present geht auch sofort mein ROOMMATE wieder auf present.
Funktioniert also genau so wie es soll.

Gruß
Dan