philips hue modul

[justme1968]

du kannst mit FILTER alles rausfiltern was dir in den sinn kommt. siehe devspec in der commandref allgemein und speziell bei readingsGroup.

und: auf api ebene sind das alles getrennte sensoren. im v1 api lassen sich diese nicht automatisch zusammenfassen. wenn das v2 api mal vollständig ist sollte das aber (endlich ?) gehen.

[blackbite]

du kannst mit FILTER alles rausfiltern was dir in den sinn kommt. siehe devspec in der commandref allgemein und speziell bei readingsGroup.

und: auf api ebene sind das alles getrennte sensoren. im v1 api lassen sich diese nicht automatisch zusammenfassen. wenn das v2 api mal vollständig ist sollte das aber (endlich ?) gehen.

Danke für den Tipp. Gleich mal umgesetzt und funktioniert. Falls es jemandem hilft... mit diesem Filter-Konstrukt bekomme ich aus den 3 devices (motion, light, temperature) nur das für die Batteriestatusanzeige relevante Device für den HUE-Bewegungsmelder ausgewertet.

Code Auswählen Erweitern

Internals:
   DEF        .*:FILTER=type!=(ZLLLightLevel|ZLLTemperature).*:[Bb]atteryLevel
.*:FILTER=type!=(ZLLLightLevel|ZLLTemperature).*:[Bb]atteryPercent
   FUUID      xxxxx
   NAME       Batteriestatus
   NR         133
   NTFY_ORDER 50-Batteriestatus
   STATE      Initialized
   TYPE       readingsGroup
   changed    0
   mayBeVisible 1

[hoppel118]

die aktuellen hue module unterstützen das neue v2 api und die events die jetzt von der bridge gepustet werden. das pollen ist damit nicht mehr nötig und wird automatisch deaktiviert sobald ein event für das betreffende device gekommen ist.

Moin Andre,

habe gerade nochmal mein FHEM geupdated. Hier ist ja gerade einiges an Bewegung im Modul.

Ich sehe immer noch folgende Meldungen im Logfile:

Code Auswählen Erweitern

bridge has events api, events connected, removing interval

Hatte dich jetzt so verstanden, dass sich das System selbst bereinigt und diese Meldungen dann irgendwann gänzlich verschwinden. Insbesondere Wenn ich FHEM neu starte, sehe ich immer wieder diese Meldungen.

Muss ich da jetzt noch irgendwas bestimmtes konfigurieren?

Danke und Gruß Hoppel

[justme1968]

das intervall wird aktuell noch nicht aus der config entfernt sondern nach dem ersten empfangenen event nur aus dem laufenden system. beim neustart ist es erst mal wieder da.

wenn es noch ein paar tage keine negativen rückmeldung gibt baue ich ein das es auch aus der config verschwindet.

[hoppel118]

Achso, alles klar. Schraube momentan relativ viel an meinem FHEM herum, so dass ich öfters mal neustarte und dann immer erstmal diese Meldungen sehe. Aber ok, dann gebe ich jetzt Ruhe. Ich wollte es eigentlich auch nur verstehen.

Danke dir, Gruß Hoppel

[hauwech]

Ich möchte nochmal nachhaken: Hat jemand eine Idee, warum eventMap

Code Auswählen Erweitern

battery.[3456789]\d:ok battery.[12]\d*:low nicht zieht? ich möchte eigentlich gern meine systemweite Battery:low Benachrichtigung wieder einschalten. Die springt an, wenn "battery" von "ok" abweicht. Mit dem aktuellen Hue Modul mußte ich abschalten, weil im battery reading - abweichend von allen anderen Modulen - ein numerischer Wert drin steht, obwohl in "batteryLevel" der gleiche Wert drin steht.

Gruß Roland

[justme1968]

im hue modul steht im battery reading schon immer das was die bridge liefert. da hat sich nichts geändert.

da es laut den aktuellen fhem richtlinien sollte es nur die readings batteryState, batteryPercent und batteryVoltage geben sollte gibt es schon seit einiger zeit batteryPercent in modul. das es aktuell auch noch das battery reading gibt ist nur zur rückwärtskompatibilität. statt zu versuchen mit eventMap an den readings zu drehen: verwende doch die readings die vom modul dafür vorgesehen sind. das wäre in deinem fall batteryState.

[hauwech]

OK, dann sind die vielen Battery:low Warnungen nach dem fhem update gekommen, weil die Hue-Sensor Devices automatisch (autocreate?) dazu gekommen sind.
Ich schicke mal ein "list" eines solchen Sensors mit:

Code Auswählen Erweitern


Internals:
   DEF        sensor 11  IODev=HG_WZ_Hue
   FUUID      xxxxxxxxxxxxxxx
   FVERSION   31_HUEDevice.pm:0.256000/2022-01-31
   ID         S11
   INTERVAL   
   IODev      HG_WZ_Hue
   NAME       HUESensor11
   NR         1146
   STATE      ???
   TYPE       HUEDevice
   has_events 1
   manufacturername Signify Netherlands B.V.
   modelid    SML001
   name       Hue temperature sensor 1
   on         1
   productname Hue temperature sensor
   reachable  1
   swversion  6.1.1.27575
   type       ZLLTemperature
   uniqueid   xxxxxxxxxxxxxxxxxxxx
   v2_id      xxxxxxxxxxxxxxxxxxxx
   Helper:
     DBLOG:
       temperature:
         myDbLog:
           TIME       1644050476.00619
           VALUE      19.18
   READINGS:
     2022-02-01 12:26:33   IODev           HG_WZ_Hue
     2022-02-05 09:41:00   battery         76
     2022-02-05 09:41:00   batteryPercent  76
     2022-02-05 09:41:00   reachable       1
     2022-02-05 09:41:00   temperature     19.18
   helper:
     devtype    S
     state     
     update_timeout 1
     capabilities:
     configList:
     json:
       manufacturername Signify Netherlands B.V.
       modelid    SML001
       name       Hue temperature sensor 1
       productname Hue temperature sensor
       swversion  6.1.1.27575
       type       ZLLTemperature
       uniqueid   xxxxxxxxxxxxxxxxxxxx
       capabilities:
       config:
         alert      none
         battery    76
         pending:
       state:
         lastupdated 2022-02-05T08:41:00
         temperature 1918
       swupdate:
         lastinstall 2019-03-15T13:03:04
         state      noupdates
     setList:
   hmccu:
Attributes:
   IODev      HG_WZ_Hue
   alias      Hue temperature sensor 1
   group      HUEDevice
   model      SML001
   room       HUEDevice

Ein reading batteryState gibt es bei diesem device nicht. Statt dessen enthalten "battery" und "batteryPercent" den Wert 76, während bei allen meinen anderen Devices das reading "battery" den Wert "ok" oder "low" enthält. Zur Verdeutlichung ein "list .* battery":

Code Auswählen Erweitern


CP_BM_01             2022-02-05 09:49:24    ok
CP_WT_Licht          2022-01-03 18:15:36    ok
HG_AZ_Fenster_rechts 2022-02-05 09:21:37    ok
HG_AZ_HZ             2022-02-05 09:49:30    ok
HG_AZ_TH_01          2022-02-05 09:52:00    ok
HG_BM_1              2022-02-05 09:48:22    ok
HG_BM_Bad            2022-02-05 09:47:13    ok
HG_BM_Einfahrt       2022-02-05 09:49:34    ok
HG_BM_WK             2022-02-05 08:40:28    ok
HG_BZ_Fenster        2022-02-05 09:20:24    ok
HG_BZ_HZ             2022-02-05 09:51:06    ok
HG_BZ_HZ_WT          2022-02-05 09:49:08    low
HG_BZ_RL_Taster      2022-02-04 21:12:34    ok
HG_Display           2022-02-05 08:29:40    ok
HG_FL_Muell          2022-02-05 09:47:58    low
HG_GWC_Fenster       2022-02-05 09:41:52    ok
HG_GWC_HZ            2022-02-05 09:50:14    ok
HG_KE_Gasmelder      2018-10-20 17:58:12    ok
HG_KE_Tuer           2022-02-05 09:02:50    ok
HG_KE_TuerRiegel     2022-02-05 09:12:41    ok
HG_KE_WC_Fenster     2022-02-05 09:43:01    ok
HG_KE_Wassersensor   2022-02-05 09:50:26    ok
HG_KT_TH_01          2022-02-05 09:51:59    ok
HG_KU_Fenster        2022-02-05 09:10:41    ok
HG_KU_HZ             2022-02-05 09:50:25    ok
HG_KU_TH_01          2022-02-05 09:51:57    ok
HG_MP3_Mobil         2022-02-05 09:46:01    ok
HG_RM                2021-03-01 11:07:19    ok
HG_SS_TR             2019-12-01 17:12:59    low
HG_SZ_Fenster        2022-02-05 09:42:25    ok
HG_SZ_Fenster_alt    2022-02-04 10:39:56    ok
HG_SZ_HZ             2022-02-05 09:49:57    ok
HG_TH_BM             2022-02-05 09:33:02    ok
HG_TH_Klingel        2022-02-04 18:04:34    ok
HG_TH_TH_01          2022-02-05 09:52:00    ok
HG_TR_TH_01          2022-02-05 09:52:00    ok
HG_TR_WT             2021-12-10 16:59:30    ok
HG_WK_Fenster        2022-02-05 09:11:32    ok
HG_WK_TH_01          2022-02-05 09:51:43    ok
HG_WZ_Fenster        2022-02-05 09:32:06    ok
HG_WZ_HS_RL          2022-01-29 23:47:22    low
HG_WZ_HZ             2022-02-05 09:50:42    ok
HG_WZ_HZ_WT          2022-02-05 09:41:29    ok
HG_WZ_TTuer          2022-02-05 09:51:38    ok
HUESensor11          2022-02-05 09:50:58    76
HUESensor12          2022-02-05 09:50:59    76
HUESensor13          2022-02-05 09:48:42    76
HUESensor16          2022-02-05 09:47:22    1
HUESensor17          2022-02-05 09:48:03    1
HUESensor18          2022-02-05 09:50:47    1
HUESensor2           2022-02-05 09:41:59    40
HUESensor20          2021-09-30 09:23:00    100
HUESensor8           2022-02-05 09:39:51    25
HandsenderAlarm      2018-03-24 20:07:27    ok
NG_BZ_Fenster        2022-02-05 03:27:35    ok
NG_BZ_HZ             2022-02-05 09:51:25    ok
NG_CP_TH_01          2022-02-05 09:51:57    ok
NG_CP_TH_02          2022-02-05 09:47:54    ok
NG_CP_TH_03          2022-02-05 09:51:47    ok
NG_MK_SW_01          2021-10-25 17:55:40    ok
NG_SZ_Fenster        2022-02-05 09:15:57    ok
NG_VR_TH_01          2022-02-05 09:51:55    ok
NG_WZ_Fenster        2022-02-05 09:48:00    ok
Sirene               2022-02-01 12:28:49    ok
TempSens1            2022-02-05 09:50:21    ok
TempSens2            2022-02-05 09:49:56    ok
TempSens3            2022-02-05 09:51:07    ok
dummy_Fenster        2018-11-20 14:00:23    low

Ein anderes device hat das reading batteryState, dort steht aber abweichend "normal" statt "ok":

Code Auswählen Erweitern


Internals:
   DEF        sensor 2  IODev=HG_WZ_Hue
   FUUID      xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   FVERSION   31_HUEDevice.pm:0.256000/2022-01-31
   ID         S2
   INTERVAL   
   IODev      HG_WZ_Hue
   NAME       HUESensor2
   NR         1144
   STATE      1002
   TYPE       HUEDevice
   has_events 1
   inputs     4
   manufacturername Signify Netherlands B.V.
   modelid    RWL021
   name       Hue Dimmer Wohnzimmer
   on         1
   productname Hue dimmer switch
   reachable  1
   swversion  6.1.1.28573
   type       ZLLSwitch
   uniqueid   xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   v2_id      xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   READINGS:
     2022-02-01 12:26:33   IODev           HG_WZ_Hue
     2022-02-05 09:57:03   battery         39
     2022-02-05 09:57:03   batteryPercent  39
     2022-02-05 09:57:03   batteryState    normal
     2022-02-04 17:56:36   eventtype       short_release
     2022-02-04 17:56:36   input           1
     2022-02-04 17:56:35   reachable       1
     2022-02-04 17:56:36   state           1002
   helper:
     devtype    S
     state      1002
     update_timeout 1
     capabilities:
       inputs:
         HASH(0xefce578)
         HASH(0xeb7be68)
         HASH(0xf206888)
         HASH(0xeca7f58)
     configList:
     events:
       HASH(0xf2a1ed8)
       HASH(0xeb43f28)
       HASH(0xe7ddb50)
       HASH(0xe7d3538)
     json:
       diversityid xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
       manufacturername Signify Netherlands B.V.
       modelid    RWL021
       name       Hue Dimmer Wohnzimmer
       productname Hue dimmer switch
       swversion  6.1.1.28573
       type       ZLLSwitch
       uniqueid   xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
       capabilities:
         inputs:
           HASH(0xf26e550)
           HASH(0x10b59b50)
           HASH(0xf007558)
           HASH(0xf24a568)
       config:
         battery    39
         pending:
       state:
         buttonevent 1002
         lastupdated 2022-02-04T16:56:35
       swupdate:
         lastinstall 2019-10-20T12:40:21
         state      noupdates
     setList:
   hmccu:
Attributes:
   IODev      HG_WZ_Hue
   alias      Hue Dimmer Wohnzimmer
   group      HUEDevice
   model      RWL021
   room       HUEDevice

Meine (Jahre alte...) "Battery:low"-Benachrichtigung wird versendet, wenn ein Device nicht den Wert "ok" liefert. Jetzt könnte ich in dem alten notify eine Unterscheidung "HueSensor oder nicht HueSensor" einbauen oder versuchen das reading mit eventMap zurecht zu biegen. Beides nicht so schön, zumal die HueSensoren offenbar verschiedene readings enthalten, die man dann auch noch abfangen müßte. Besser wäre, wenn das Hue Modul analog zu den anderen Modulen "battery:ok" oder "battery:low" enthalten würde. Dann müßte allerdings die Entscheidung, ab wann battery:low ist, im Modul selbst oder vielleicht mit einem "treshold-Attribut" getroffen werden.
Wenn die Änderungen im Modul zu aufwendig wären oder angesichts der erwähnten Richtlinien keinen Sinn machen - oder wenn ich der Einzige mit dem Problem bin, kann ich mir das alte notify zurechtstricken. Vielleicht werden eines Tages alle Module den Richtlinien entsprechend angepaßt, einheitlich wäre schon schön  .

Gruß Roland

[justme1968]

wie du an den json internals im device list siehst sendet dein sensor nur battery mit einem prozent wert. das war auch noch nie anders.

deine battery benachrichtigung kann für hie devices noch nie funktioniert haben.

der knackpunkt ist vermutlich das sich die readings nie ändern solange die baterrien voll sind und du nicht nie ein event dafür bekommen hast.

die idee hinter der oben beschrieben festlegung für batteryState, batteryPercent und batteryVoltage ist ja gerade die standardisierung voranzubringen die es aktuell eben nicht gibt.

[hauwech]

Nun, die Benachrichtigung für alle anderen devices hat bisher immer funktioniert, weil die Sensor Devices erst mit dem update  auf das neue Modul aufgetaucht sind, vorher gab es die nicht bei mir.  Alle anderen Hue devices, die ich bis dahin in fhem hatte, haben keine Batterie.

Gruß Roland

[nicor2k]

Hallo zusammen,

kann es sein, das mit den neuen Batteriewerten etwas anderes durcheinandergekommen ist? Ich frage die Tastendrücke der Hue Dimmer ab, um FHEM darauf reagieren zu lassen. Seit kurzem passiert es aber, dass die zuletzt gedrückte Taste erneut gesendet wird, und war immer zeitgleich mit der Batteriemeldung:

Code Auswählen Erweitern


2022.02.10 21:44:18 2: HueDimmerKueche: bridge has events api, events connected, removing interval
2022.02.10 21:44:18 3: HueDimmerKueche: Batteriewarnung battery: 83
2022.02.10 21:44:18 3: CUL1 IT_set: ROLLADEN_KUECHE on


[hauwech]

Noch eine Anmerkung zur Ergänzung:
Da eine Vereinheitlichung der readings wohl nicht so schnell zu erwarten ist, habe ich in meinem Batterie-Warnung notify alle HUESensor<nn> Devices von der automatischen Benachrichtigung ausgeschlossen.

Gruß Roland

[nicor2k]

Hat denn sonst niemand dieses Problem mit den Hue Dimmern?

kann es sein, das mit den neuen Batteriewerten etwas anderes durcheinandergekommen ist? Ich frage die Tastendrücke der Hue Dimmer ab, um FHEM darauf reagieren zu lassen. Seit kurzem passiert es aber, dass die zuletzt gedrückte Taste erneut gesendet wird, und war immer zeitgleich mit der Batteriemeldung:

Code Auswählen Erweitern


2022.02.10 21:44:18 2: HueDimmerKueche: bridge has events api, events connected, removing interval
2022.02.10 21:44:18 3: HueDimmerKueche: Batteriewarnung battery: 83
2022.02.10 21:44:18 3: CUL1 IT_set: ROLLADEN_KUECHE on


Ich habe das Batterie-notify auch mal deaktiviert, aber im Log habe ich dann jetzt so etwas stehen, bevor der Dimmer selbstständig das letzte Kommando wiederholt:

Code Auswählen Erweitern


2022.02.14 18:28:13 2: HueDimmer01: bridge has events api, events connected, removing interval
2022.02.14 18:28:13 3: CUL1 IT_set: ROLLADEN_01 on


[justme1968]

was sagt der event monitor?

bisher waren alle meldungen von doppelten oder wiederholten daten nur falschen bzw. zu ungenaue regex im notify oder doif.

[nicor2k]

Ich lassen den EventMonitor mal offen, das kommt nicht regel,äßig, wenn ich es richtig sehe. Anbei mein notify, aktuell mit auskommentieren actions

Bis zu einem kürzlichen Update hat das so allerdings funktioniert!

Code Auswählen Erweitern


HueDimmer01 {
my $timestamp = time();
my $huebutton = ReadingsVal("HueDimmer01","state",0);
my $lastpressed = ReadingsVal("HueDimmer01LastPressed", "state", "");
#if(($huebutton == 2002 || $huebutton == 2003) && $lastpressed < ($timestamp - 1)) { fhem("set ROLLADEN_01 on; set HueDimmerABLastPressed $timestamp"); }
#if(($huebutton == 3002 || $huebutton == 3003) && $lastpressed < ($timestamp - 1)) { fhem("set ROLLADEN_01 off; set HueDimmerABLastPressed $timestamp;"); }
}