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

[dickdickerson]

Hallo Leute,

entweder mache ich grundsätzlich etwas falsch oder irgendwas stimmt bei mir nicht. Soweit ich das beurteilen kann, findet HOMEMODE meine PRESENCE-Devices nicht.

HOMEMODE:

Code Auswählen Erweitern


Internals:
   DEF        Bewohner
   FUUID      5e104b39-f33f-c3d2-4101-7a0c3ba00846f704
   NAME       Home
   NOTIFYDEV  Bewohner,global,rg_Melanie,rr_Marco
   NR         698
   NTFY_ORDER 51-Home
   RESIDENTS  rg_Melanie,rr_Marco
   STATE      afternoon
   TYPE       HOMEMODE
   VERSION    1.5.3
   READINGS:
     2020-01-04 13:42:37   alarmState      disarm
     2020-01-04 09:22:17   anyoneElseAtHome off
     2020-01-04 14:00:03   daytime         afternoon
     2020-01-04 09:22:17   dnd             off
     2020-01-04 10:49:37   lastAbsentByResident rr_Marco
     2020-01-04 13:42:37   lastActivityByResident rr_Marco
     2020-01-04 13:52:37   lastLocationByResident rr_Marco - zuhause
     2020-01-04 13:42:37   lastPresentByResident rr_Marco
     2020-01-04 15:04:50   location        home
     2020-01-04 14:00:03   mode            afternoon
     2020-01-04 13:42:37   modeAlarm       disarm
     2020-01-04 09:22:17   panic           off
     2020-01-04 13:42:37   presence        present
     2020-01-04 13:52:37   prevActivityByResident rr_Marco
     2020-01-04 15:04:50   prevLocation    home
     2020-01-04 14:00:03   prevMode        day
     2020-01-04 13:42:37   prevModeAlarm   armaway
     2020-01-04 09:25:14   publicIP        X.X.X.X
     2020-01-04 09:22:17   season          winter
     2020-01-04 14:00:03   state           afternoon
   helper:
     enabledDevices Bewohner,global,rg_Melanie,rr_Marco
     lastChangedAttr webCmd
     lastChangedAttrValue modeAlarm
Attributes:
   HomeAdvancedDetails both
   HomeAdvancedUserAttr 1
   HomeAutoArrival 10
   HomeAutoAsleep 15
   HomeAutoAwoken 15
   HomeAutoDaytime 1
   devStateIcon absent:user_away:dnd+on
gone:user_ext_away:dnd+on
dnd:audio_volume_mute:dnd+off
gotosleep:scene_sleeping:dnd+on
asleep:scene_sleeping_alternat:dnd+on
awoken:weather_sunrise:dnd+on
home:status_available:dnd+on
morning:weather_sunrise:dnd+on
day:weather_sun:dnd+on
afternoon:weather_summer:dnd+on
evening:weather_sunset:dnd+on
night:weather_moon_phases_2:dnd+on
   genericDeviceType security
   homebridgeMapping SecuritySystemCurrentState=alarmState,values=armhome:0;armaway:1;armnight:2;disarm:3;alarm:4
SecuritySystemTargetState=modeAlarm,values=armhome:0;armaway:1;armnight:2;disarm:3,cmds=0:modeAlarm+armhome;1:modeAlarm+armaway;2:modeAlarm+armnight;3:modeAlarm+disarm,delay=1
SecuritySystemAlarmType=alarmTriggered_ct,values=0:0;/.*/:1
OccupancyDetected=presence,values=present:1;absent:0
Mute=dnd,valueOn=on,cmdOn=dnd+on,cmdOff=dnd+off
On=anyoneElseAtHome,valueOn=on,cmdOn=anyoneElseAtHome+on,cmdOff=anyoneElseAtHome+off
   icon       floor
   room       HOMEMODE,Presence
   userattr   HomeCMDdaytime-afternoon:textField-long HomeCMDdaytime-day:textField-long HomeCMDdaytime-evening:textField-long HomeCMDdaytime-morning:textField-long HomeCMDdaytime-night:textField-long HomeCMDmode-absent-rg_Melanie:textField-long HomeCMDmode-absent-rr_Marco:textField-long HomeCMDmode-afternoon:textField-long HomeCMDmode-asleep-rg_Melanie:textField-long HomeCMDmode-asleep-rr_Marco:textField-long HomeCMDmode-awoken-rg_Melanie:textField-long HomeCMDmode-awoken-rr_Marco:textField-long HomeCMDmode-day:textField-long HomeCMDmode-evening:textField-long HomeCMDmode-gone-rr_Marco:textField-long HomeCMDmode-gotosleep-rg_Melanie:textField-long HomeCMDmode-gotosleep-rr_Marco:textField-long HomeCMDmode-home-rg_Melanie:textField-long HomeCMDmode-home-rr_Marco:textField-long HomeCMDmode-morning:textField-long HomeCMDmode-night:textField-long HomeCMDpresence-absent-rg_Melanie:textField-long HomeCMDpresence-absent-rr_Marco:textField-long HomeCMDpresence-present-rg_Melanie:textField-long HomeCMDpresence-present-rr_Marco:textField-long HomeCMDseason-autumn:textField-long HomeCMDseason-spring:textField-long HomeCMDseason-summer:textField-long HomeCMDseason-winter:textField-long genericDeviceType homebridgeMapping:textField-long
   webCmd     modeAlarm

RESIDENTS:

Code Auswählen Erweitern

Internals:
   CHANGED   
   DURATIONTIMER 1578153585.13763
   FUUID      5ce16e2c-f33f-c3d2-6c8d-e5668a6ce5ff9c55
   FVERSION   10_RESIDENTS.pm:0.195330/2019-06-02
   GUESTS     rg_Melanie
   NAME       Bewohner
   NOTIFYDEV  global,rr_Marco,rg_Melanie
   NR         549
   NTFY_ORDER 50-Bewohner
   READY      1
   ROOMMATES  rr_Marco
   STATE      home
   TYPE       RESIDENTS
   READINGS:
     2020-01-04 13:42:37   durTimerAbsence 00:00:00
     2020-01-04 13:42:37   durTimerAbsence_cr 0
     2020-01-04 16:58:45   durTimerPresence 03:16:08
     2020-01-04 16:58:45   durTimerPresence_cr 196
     2020-01-04 08:50:51   durTimerSleep   00:00:00
     2020-01-04 08:50:51   durTimerSleep_cr 0
     2019-12-30 13:45:33   homealoneSubtype -
     2019-12-30 13:45:33   homealoneType   -
     2020-01-04 13:42:37   lastXXXX        XXXX
     2020-01-04 13:42:37   presence        present
     2020-01-04 13:42:37   residentsAbsent 0
     2020-01-04 13:42:37   residentsAbsentDevs -
     2020-01-04 13:42:37   residentsAbsentNames -
     2020-01-04 08:50:51   residentsAsleep 0
     2020-01-04 08:50:51   residentsAsleepDevs -
     2020-01-04 08:50:51   residentsAsleepNames -
     2020-01-04 10:49:37   residentsAwoken 0
     2020-01-04 10:49:37   residentsAwokenDevs -
     2020-01-04 10:49:37   residentsAwokenNames -
     2019-12-31 02:10:13   residentsGone   0
     2019-12-31 02:10:13   residentsGoneDevs -
     2019-12-31 02:10:13   residentsGoneNames -
     2019-09-21 22:30:00   residentsGotosleep 0
     2019-09-21 22:30:00   residentsGotosleepDevs -
     2019-09-21 22:30:00   residentsGotosleepNames -
     2020-01-04 13:42:37   residentsHome   1
     2020-01-04 13:42:37   residentsHomeDevs rr_Marco
     2020-01-04 13:42:37   residentsHomeNames Marco
     2019-12-31 05:45:33   residentsTotal  1
     2020-01-04 13:42:37   residentsTotalAbsent 0
     2020-01-04 13:42:37   residentsTotalAbsentDevs -
     2020-01-04 13:42:37   residentsTotalAbsentNames -
     2019-12-31 05:45:33   residentsTotalGuests 0
     2019-12-31 05:45:33   residentsTotalGuestsAbsent 0
     2019-12-31 05:45:33   residentsTotalGuestsAbsentDevs -
     2019-12-31 05:45:33   residentsTotalGuestsAbsentNames -
     2019-12-30 13:45:33   residentsTotalGuestsPresent 0
     2019-12-30 13:45:33   residentsTotalGuestsPresentDevs -
     2019-12-30 13:45:33   residentsTotalGuestsPresentNames -
     2019-12-31 05:45:33   residentsTotalPeople 1
     2020-01-04 13:42:37   residentsTotalPeopleAbsent 0
     2020-01-04 13:42:37   residentsTotalPeopleAbsentDevs -
     2020-01-04 13:42:37   residentsTotalPeopleAbsentNames -
     2020-01-04 13:42:37   residentsTotalPeoplePresent 1
     2020-01-04 13:42:37   residentsTotalPeoplePresentDevs rr_Marco
     2020-01-04 13:42:37   residentsTotalPeoplePresentNames Marco
     2019-05-19 18:24:54   residentsTotalPets 0
     2019-05-19 18:24:54   residentsTotalPetsAbsent 0
     2019-05-19 18:24:54   residentsTotalPetsAbsentDevs -
     2019-05-19 18:24:54   residentsTotalPetsAbsentNames -
     2019-05-19 18:24:54   residentsTotalPetsPresent 0
     2019-05-19 18:24:54   residentsTotalPetsPresentDevs -
     2019-05-19 18:24:54   residentsTotalPetsPresentNames -
     2020-01-04 13:42:37   residentsTotalPresent 1
     2020-01-04 13:42:37   residentsTotalPresentDevs rr_Marco
     2020-01-04 13:42:37   residentsTotalPresentNames Marco
     2019-12-15 14:59:48   residentsTotalRoommates 1
     2020-01-04 13:42:37   residentsTotalRoommatesAbsent 0
     2020-01-04 13:42:37   residentsTotalRoommatesAbsentDevs -
     2020-01-04 13:42:37   residentsTotalRoommatesAbsentNames -
     2020-01-04 13:42:37   residentsTotalRoommatesPresent 1
     2020-01-04 13:42:37   residentsTotalRoommatesPresentDevs rr_Marco
     2020-01-04 13:42:37   residentsTotalRoommatesPresentNames Marco
     2018-05-14 21:02:38   residentsTotalWakeup 0
     2018-05-14 21:02:38   residentsTotalWakeupDevs -
     2018-05-14 21:02:38   residentsTotalWakeupNames -
     2018-05-14 21:02:38   residentsTotalWayhome 0
     2018-05-14 21:02:38   residentsTotalWayhomeDelayed 0
     2018-05-14 21:02:38   residentsTotalWayhomeDelayedDevs -
     2018-05-14 21:02:38   residentsTotalWayhomeDelayedNames -
     2018-05-14 21:02:38   residentsTotalWayhomeDevs -
     2018-05-14 21:02:38   residentsTotalWayhomeNames -
     2020-01-04 13:42:37   state           home
   TIMER:
     Bewohner_DurationTimer:
       HASH       Bewohner
       MODIFIER   DurationTimer
       NAME       Bewohner_DurationTimer
Attributes:
   devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
   event-on-change-reading state
   group      Home State
   icon       control_building_filled
   room       Presence
   webCmd     state

PRESENCE:

Code Auswählen Erweitern

Internals:
   DEF        event unifi:Handy-Marco:.disconnected unifi:Handy-Marco:.connected
   EVENT_ABSENT unifi:Handy-Marco:.disconnected
   EVENT_PRESENT unifi:Handy-Marco:.connected
   FUUID      5ce16e28-f33f-c3d2-8c52-295af025c41deadf
   MODE       event
   NAME       rr_MarcoHandy
   NOTIFYDEV  unifi,global
   NR         223
   NTFY_ORDER 50-rr_MarcoHandy
   STATE      present
   TYPE       PRESENCE
   READINGS:
     2020-01-04 16:50:27   model           event
     2020-01-04 16:41:37   presence        present
     2020-01-04 16:41:37   state           present
   helper:
     ABSENT_COUNT 0
     PRESENT_COUNT 0
Attributes:
   devStateIcon present:WLAN_Status.1 absent:WLAN_Status.0
   event-on-change-reading state
   icon       it_smartphone
   room       Presence
   userattr   room_map structexclude


Im Forum finde ich bei allen das Reading "HomeInfo" von HOMEMODE. Bei mir gibt es das zb. gar nicht.
Ich hatte auch schon unterschiedliche Namen des PRESENCE-Devices getestet, was aber keine Änderung gebracht hat. Auch habe ich mehrere PRESENCE-Devices, die auch Marco im Namen enthalten. Laut Wiki sollte dann zumindest das Attribut HomePresenceDeviceAbsentCount-rr_Marco gesetzt werden. Aber auch das passiert nicht.

set Home updateInternalsForce oder auch shutdown restart bewirkt auch nichts.

Habt ihr noch einen Tipp woran es liegen könnte, dass die Geräte nicht zugeordnet bzw. gefunden werden können? Zumindest dann sollte ja ein Hinweis in HomeInfo auftauchen.

Edit:
Ich habe die fehlende Einstellung gefunden. Es hat das Attribut HomeAutoPresence=1 gefehlt. Jetzt habe ich das Reading HomeInfo.

[binford6000]

Soweit ich das beurteilen kann, findet HOMEMODE meine PRESENCE-Devices nicht.

In deinem List vom HOMEMODE device fehlt das Attribut "HomePresenceDeviceType".
Darin stehen die TYPEn deiner PRESENCE devices. Details siehe Wiki...

VG Sebastian

[DeeSPe]

Hast du batteriebetriebene Zwave-Geräte?
Mich würde es interessieren, ob du so etwas auch im FileLog hast.

Hallo FunkOdyssey,

ich war ein paar Tage off, deshalb jetzt erst die Rückmeldung.

Ja, ich habe batteriebetriebene ZWave Geräte, und nein, so etwas habe ich nicht im FileLog. Ich benutze aber auch kein FileLog.

Der von Dir erwähnte Trigger-Meldung kommt nur einmalig wenn neue Geräte in die Batterieüberwachung mit aufgenommen werden und diese bei der Aufnahme auch bereits eine niedrige Batterie haben.
Was genau regt Dich daran so auf? Was machst Du genau dass diese Meldung bei Dir öfter kommt bzw. wann kommt diese Meldung bei Dir?

Nun sieht es folgendermaßen in meinem Sensoren-Log aus:

Code Auswählen Erweitern


2019-12-27_18:26:59 contact_garage battery: 100
2019-12-27_18:26:59 contact_garage battery: 100%
2019-12-27_18:26:59 contact_garage battery: 100 %
2019-12-27_18:26:59 contact_garage battery: 90 %


90% war der letzte alte Wert im FileLog. Dieser dürfte der richtige Wert sein.

Sorry, da war noch ein Fehler im Code, es hätte nur die letzte Ausgabe geben sollen.
Hier im Anhang nochmal eine überarbeitete Version zum Test.

Gruß
Dan

[gent]

Hallo,

ich habe gerade bei mir mal ein residents device und die roommates angelegt und dann ein homemode device.

Nachdem ich das Attribut HomePresenceDeviceType auf PRESENCE gesetzt habe und HomeAutoPresence auf 1 bekomme im im homemode device

Code Auswählen Erweitern

Gefunden wurden 1 übereinstimmende(s) Anwesenheits Gerät(e) vom Devspec "TYPE=PRESENCE" für Bewohner "rr_Bewohner"! Übereinstimmende Geräte: "BewohnerAnwesend"

Im PRESENCE device steht das Reading presence auf "absent", aber im ROOMMATE rr_Bewohner wird immer noch "zuhause" bzw. im presence Reading "present" angezeigt.

Was mache ich falsch?

Viele Grüße, Holger

[dk3572]

Die 2. Frage ist:
Ist es normal, dass die "userattr" meiner Homemode Devices  immer weiter "wachsen" und sich weiter duplizieren? Hier mal ein List meines Kontaktsensors meiner  Wohnungstür:

Code Auswählen Erweitern

nternals:
   DEF        sensor 24  IODev=deCONZ
   FUUID      5d8e7873-f33f-3040-7603-4593ddbb18b07148
   FVERSION   31_HUEDevice.pm:0.205260/2019-11-17
   ID         S24
   INTERVAL   
   IODev      deCONZ
   NAME       Kontakt_Eingang
   NR         396
   STATE      closed
   TYPE       HUEDevice
   lastupdated 2019-12-02 07:40:42
   lastupdated_local 2019-12-02 08:40:42
   manufacturername LUMI
   modelid    lumi.sensor_magnet.aq2
   name       D_Main
   on         1
   reachable  1
   swversion  20161128
   type       ZHAOpenClose
   uniqueid   00:15:8d:00:02:4e:42:30-01-0006
   READINGS:
     2019-12-02 08:40:42   battery         100
     2019-12-02 08:40:42   reachable       1
     2019-12-02 08:40:42   state           closed
     2019-12-02 08:40:42   temperature     26
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     configList:
     setList:
Attributes:
   HomeContactType doormain
   HomeModeAlarmActive armaway
   IODev      deCONZ
   alias      Wohnungstür
   devStateIcon open:fts_door_open@#e56524 closed:fts_door .*:fts_door_open
   genericDeviceType ContactSensor
   group      Contacts
   homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
CurrentDoorState=state,values=closed:CLOSED;open:OPEN
history:size=1024
   room       HUEDevice,Homekit,Wohnzimmer
   userattr   HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes

Ich freue mich über eine Idee

Danke und viele Grüße
wolf

Definitiv nein, bevor einem Device die userattr hinzugefügt werden, werden alle userattr beginnend mit "Home" automatisch entfernt und dann wieder neu hinzugefügt. Bisher hat sich (außer Dir) noch niemand beschwert dass das nicht richtig klappt, bzw. dass die userattr immer länger werden. Weiß auch gerade nicht so richtig wonach ich suchen soll. Hast Du evtl. noch Hinweise für mich, die mir beim Suchen helfen könnten?

Gruß
Dan

Hallo,
ich beobachte bei 3 von zig Fenster-Türkontakten gleiches Verhalten.
Die userattr waren mind. 3-fach vorhanden.

Gibt es hierzu neue Erkenntnisse?

Danke und Gruß
Dieter

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

[rrr]

Wäre es mögich einen Timer einzubauen, welcher die Location nach dem Setzen auf "wayhome" wieder zurück auf "away" setzt, sobald nicht innerhalb einer gewünschten Zeit die Location auf "home" gesetzt wird?

Zum Hintergrund:
Ich würde gerne von unterwegs die Location auf "wayhome" setzen, um bspw. die Heizung, Klimaanlage usw. einzuschalten. Schaffe ich es nun nicht innerhalb einer gewissen Zeitspanne nach Hause, so würde wieder HomeCMDlocation-absent oder HomeCMDlocation-gone ausgeführt und sämtlichen vorher eingeschalteten Geröte wären wieder aus.

[DeeSPe]

Hallo,
ich beobachte bei 3 von zig Fenster-Türkontakten gleiches Verhalten.
Die userattr waren mind. 3-fach vorhanden.

Gibt es hierzu neue Erkenntnisse?

Danke und Gruß
Dieter

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

Hallo Dieter,

das habe ich bisher nicht ergründet.
Kannst Du evtl. mehr dazu sagen? Bisher kann ich mir überhaupt nicht erklären woher das kommen soll!

Gruß
Dan

[DeeSPe]

Wäre es mögich einen Timer einzubauen, welcher die Location nach dem Setzen auf "wayhome" wieder zurück auf "away" setzt, sobald nicht innerhalb einer gewünschten Zeit die Location auf "home" gesetzt wird?

Zum Hintergrund:
Ich würde gerne von unterwegs die Location auf "wayhome" setzen, um bspw. die Heizung, Klimaanlage usw. einzuschalten. Schaffe ich es nun nicht innerhalb einer gewissen Zeitspanne nach Hause, so würde wieder HomeCMDlocation-absent oder HomeCMDlocation-gone ausgeführt und sämtlichen vorher eingeschalteten Geröte wären wieder aus.

Hallo rrr,

einbauen könnte ich so ziemlich alles. Mir stellt sich immer die Frage nach dem allgemeinen Nutzen für so etwas.
Du könntest z.B. im Attribut HomeCMDlocation-wayhome selbst ein entsprechendes at definieren.

Gruß
Dan

[adn77]

Ich habe seit ungefähr dieser Version Probleme mit der täglichen Batteriewarnung:

Habe soeben v1.5.1 eingecheckt.

Es wird ständig eine leere Batterie (genau eine) gemeldet, die nicht leer ist.

Folgende Attribute habe ich eingestellt:

Code Auswählen Erweitern

HomeSensorsBattery TYPE=MAX
HomeSensorsBatteryReading batteryPercent

Dazu habe ich auf allen MAX Geräten ein userReading "batteryPercent", welches das "ok" der Batterie in die Zahl "100" wandelt (bzw. in "25" wenn leer).

Ich habe ca. 20 MAX Geräte (alle mit vollen Batterien), trotzdem kommt jeden Abend die Warnung, eine Batterie wäe leer.
Weil das schonmal Thema war, außer einer "readingsGroup" mit allen Batterie-Leveln gibt es keine weitere Batterieüberwachung.

Habe auch schon versucht, die Readings "lastBatteryLow"/"lastBatteryNormal" zu löschen - ohne Erfolg.
Wäre für jeden Tipp dankbar!

Alex

[dk3572]

Hallo Dieter,

das habe ich bisher nicht ergründet.
Kannst Du evtl. mehr dazu sagen? Bisher kann ich mir überhaupt nicht erklären woher das kommen soll!

Gruß
Dan

Hallo Dan,
jetzt ist mir noch aufgefallen, dass nach einem Neustart alle Xiaomi Kontakte in HOMEMODE verschwunden waren. Nach einem UpdateInternalsForce waren sie wieder da, allerdings mit doppelten userattr.
In HOMEMODE eingebunden habe ich sie mit z.B. HomeSensorsContact type=ZHAOpenClose.
Es betrifft alle Sensoren die über HUEBridge eingebunden sind.
Hilft das als weiter Hinweis?
Danke und Gruß
Dieter

[DeeSPe]

Ich habe seit ungefähr dieser Version Probleme mit der täglichen Batteriewarnung:
Es wird ständig eine leere Batterie (genau eine) gemeldet, die nicht leer ist.

Folgende Attribute habe ich eingestellt:

Code Auswählen Erweitern

HomeSensorsBattery TYPE=MAX
HomeSensorsBatteryReading batteryPercent

Dazu habe ich auf allen MAX Geräten ein userReading "batteryPercent", welches das "ok" der Batterie in die Zahl "100" wandelt (bzw. in "25" wenn leer).

Ich habe ca. 20 MAX Geräte (alle mit vollen Batterien), trotzdem kommt jeden Abend die Warnung, eine Batterie wäe leer.
Weil das schonmal Thema war, außer einer "readingsGroup" mit allen Batterie-Leveln gibt es keine weitere Batterieüberwachung.

Habe auch schon versucht, die Readings "lastBatteryLow"/"lastBatteryNormal" zu löschen - ohne Erfolg.
Wäre für jeden Tipp dankbar!

Alex

Hmmm, da bin ich im Moment etwas ratlos.
Die Batterieüberwachung findet anhand von Events der jeweiligen Batteriegeräte statt. Wenn also kein Event kommt welches eine niedrige Batterie meldet, gibt es auch keine Batteriewarnung.
Komisch ist nur dass Du die Readings "lastBatteryLow"/"lastBatteryNormal" gelöscht hast und diese wieder kamen. Das bedeutet eigentlich dass es doch ein Event gegeben haben muss welches einer niedrigen Batterie entspricht.
Könntest Du testweise mal ein notify auf den Kontakt (welcher die Falschmeldung liefert) und dessen Batteriereading setzen in welchem Du Dir evtl. eine Nachricht über Änderungen schicken lässt? Es geht mir darum evtl. Fehlfunktionen des Kontakts auszuschließen.
Evtl. könnte es auch Sinn machen mal das Loglevel (verbose) vom HOMEMODE Device auf 5 zu stellen wenn Du wieder eine Falschmeldung erwartest. Bitte danach wieder zurückstellen da sonst das Log sehr schnell befüllt wird.

Gruß
Dan

[DeeSPe]

Hallo Dan,
jetzt ist mir noch aufgefallen, dass nach einem Neustart alle Xiaomi Kontakte in HOMEMODE verschwunden waren. Nach einem UpdateInternalsForce waren sie wieder da, allerdings mit doppelten userattr.
In HOMEMODE eingebunden habe ich sie mit z.B. HomeSensorsContact type=ZHAOpenClose.
Es betrifft alle Sensoren die über HUEBridge eingebunden sind.
Hilft das als weiter Hinweis?
Danke und Gruß
Dieter

Hallo Dieter,

wie sieht es nach einem weiteren Neustart von FHEM aus? Sind dann die Kontakte wieder verschwunden und müssen über updateInternalsForce wieder "aktiviert" werden?
Könntest Du auch mal testweise probieren diese Kontakte ganz aus dem HOMEMODE Device zu entfernen? Werden dann alle Home... userattr sauber mit entfernt?
Was passiert wenn Du die Kontakte danach wieder dem HOMEMODE Device hinzufügst? Sind die userattr wieder da? Sind es wieder zu viele?
Wie sieht das Internal SENSORSCONTACT aus wenn es zu viele userattr gibt? Stehen dort die Kontakte jeweils nur 1x drin oder mehrfach?
Hast Du evtl. die Kontakte noch an einer anderen Stelle im HOMEMODE Device als Sensoren konfiguriert?

Gruß
Dan

[dk3572]

Hallo Dieter,

wie sieht es nach einem weiteren Neustart von FHEM aus? Sind dann die Kontakte wieder verschwunden und müssen über updateInternalsForce wieder "aktiviert" werden?
Könntest Du auch mal testweise probieren diese Kontakte ganz aus dem HOMEMODE Device zu entfernen? Werden dann alle Home... userattr sauber mit entfernt?
Was passiert wenn Du die Kontakte danach wieder dem HOMEMODE Device hinzufügst? Sind die userattr wieder da? Sind es wieder zu viele?
Wie sieht das Internal SENSORSCONTACT aus wenn es zu viele userattr gibt? Stehen dort die Kontakte jeweils nur 1x drin oder mehrfach?
Hast Du evtl. die Kontakte noch an einer anderen Stelle im HOMEMODE Device als Sensoren konfiguriert?

Gruß
Dan

Hallo Dan,

Danke für deine Mühe.

Nach Neustart von Fhem wieder die über HUEBridge eingebundenen Kontakte verschwunden und müssen per updateInternalsForce aktiviert werden.
Nach Entfernen userattr sauber gelöscht, nach Hinzufügen usrattr einfach gesetzt.
In SENSORSCONTACT keine doppelten.
In SENSORSBATTERY sind sie noch konfiguriert.

Edit. Die Kontakte verlieren auch die HomeOpenTimes und HomeOpenTimeDeviders

Hast du bereits eine Idee?

Danke und Gruß
Dieter

[adn77]

Hmmm, da bin ich im Moment etwas ratlos.
Die Batterieüberwachung findet anhand von Events der jeweiligen Batteriegeräte statt. Wenn also kein Event kommt welches eine niedrige Batterie meldet, gibt es auch keine Batteriewarnung.
Komisch ist nur dass Du die Readings "lastBatteryLow"/"lastBatteryNormal" gelöscht hast und diese wieder kamen. Das bedeutet eigentlich dass es doch ein Event gegeben haben muss welches einer niedrigen Batterie entspricht.
Könntest Du testweise mal ein notify auf den Kontakt (welcher die Falschmeldung liefert) und dessen Batteriereading setzen in welchem Du Dir evtl. eine Nachricht über Änderungen schicken lässt? Es geht mir darum evtl. Fehlfunktionen des Kontakts auszuschließen.
Evtl. könnte es auch Sinn machen mal das Loglevel (verbose) vom HOMEMODE Device auf 5 zu stellen wenn Du wieder eine Falschmeldung erwartest. Bitte danach wieder zurückstellen da sonst das Log sehr schnell befüllt wird.

Gruß
Dan

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

[DeeSPe]

Hallo Dan,

Danke für deine Mühe.

Nach Neustart von Fhem wieder die über HUEBridge eingebundenen Kontakte verschwunden und müssen per updateInternalsForce aktiviert werden.
Nach Entfernen userattr sauber gelöscht, nach Hinzufügen usrattr einfach gesetzt.
In SENSORSCONTACT keine doppelten.
In SENSORSBATTERY sind sie noch konfiguriert.

Edit. Die Kontakte verlieren auch die HomeOpenTimes und HomeOpenTimeDeviders

Hast du bereits eine Idee?

Danke und Gruß
Dieter

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?

Edit. Die Kontakte verlieren auch die HomeOpenTimes und HomeOpenTimeDeviders

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