HUEBridge push api unterstützung

[slupus]

version 30_HUEBridge.pm

Code Auswählen Erweitern


File            Rev   Last Change

30_HUEBridge.pm 25616 2022-02-02 17:18:07Z justme1968

doif.js                    24438 2021-05-14 18:08:18Z Ellert
fhemweb.js                 25523 2022-01-20 19:44:28Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968


Im Filesystem ist die Datei vom 6.2.

Code Auswählen Erweitern

-rw-r----- 1 6061 6061  111803 Feb  6 21:46 30_HUEBridge.pm
-rw-r----- 1 6061 6061   95127 Feb 11 20:48 31_HUEDevice.pm


[justme1968]

zeig mal bitte das log mit verbose 5 so das das event zu sehen ist.

verwendest du zufällig gerade deconz szenen wenn das passiert ?

[justme1968]

schau mal ob die meldungen mit der angehängten version weg sind.

[slupus]

zeig mal bitte das log mit verbose 5 so das das event zu sehen ist.

Code Auswählen Erweitern

022.02.13 07:47:18.445 4: using HttpUtils_NonblockingGet: PUT lights/13/state
2022.02.13 07:47:19.762 5: deCONZ: websocket data: {
  'r' => 'lights',
  'id' => '13',
  'uniqueid' => '00:17:88:01:02:9d:64:60-0b',
  'state' => {
               'sat' => 232,
               'xy' => [
                         '0.5751',
                         '0.3814'
                       ],
               'reachable' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
               'on' => $VAR1->{'state'}{'reachable'},
               'effect' => 'none',
               'bri' => 24,
               'hue' => 4806,
               'ct' => 500,
               'alert' => undef,
               'colormode' => 'hs'
             },
  't' => 'event',
  'e' => 'changed'
}

2022.02.13 07:47:19.786 5: deCONZ: websocket data: {
  'state' => {
               'all_on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
               'any_on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
             },
  'id' => '65520',
  'r' => 'groups',
  't' => 'event',
  'e' => 'changed'
}

2022.02.13 07:47:19.786 2: deCONZ: websocket: event for unknown device received: deCONZ-G65520
2022.02.13 07:47:19.787 4: deCONZ: dispatch: http://192.168.42.142/api/9F4E96F773/lights/13/state
2022.02.13 07:47:19.787 5: HUEBridge_dispatch: lights/13/state
2022.02.13 07:47:20.471 4: using HttpUtils_NonblockingGet: PUT lights/13/state
2022.02.13 07:47:20.476 4: deCONZ: dispatch: http://192.168.42.142/api/9F4E96F773/lights/13/state
2022.02.13 07:47:20.476 5: HUEBridge_dispatch: lights/13/state
2022.02.13 07:47:20.477 5: deCONZ: websocket data: {
  'r' => 'lights',
  'id' => '13',
  'uniqueid' => '00:17:88:01:02:9d:64:60-0b',
  'state' => {
               'bri' => 128,
               'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
               'effect' => 'none',
               'reachable' => $VAR1->{'state'}{'on'},
               'sat' => 232,
               'xy' => [
                         '0.5751',
                         '0.3814'
                       ],
               'colormode' => 'ct',
               'alert' => undef,
               'ct' => 370,
               'hue' => 4806
             },
  'e' => 'changed',
  't' => 'event'
}

verwendest du zufällig gerade deconz szenen wenn das passiert ?

Ich habe keine Szenen in Phoscon angelegt und steure meine Leuchten über set Befehle.

schau mal ob die meldungen mit der angehängten version weg sind.

Habe die Version eingespielt und beobachte heute.

[Brause]

Ich habe jetzt auch mal die Test-Version bei mir eingespielt.

das umlenken der 65-tausender All-Lights-Gruppe zu Group0 scheint zu funktionieren. (musste allerdings die ID in Zeile 154 anpassen)
Die Events landen in der Group0

Code Auswählen Erweitern

2022.02.13 14:45:13 5: xx.GW.deCONZ: websocket data: $VAR1 = {
          'state' => {
                       'all_on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
                       'any_on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
                     },
          'id' => '65516',
          't' => 'event',
          'e' => 'changed',
          'r' => 'groups'
        };

2022.02.13 14:45:13 5: xx.GW.deCONZ: websocket: assuming group 0 for id 65516 in event


wie an anderer Stelle geschrieben bei mir hat die neue All-Light-Gruppe die ID 65516
vielleicht könnte man das als Attribut machen, das man, wie in meinem Fall, die im Notfall selber einstellen kann.

Ich habe auch noch eine Group65519 bei der werden die Readings nach wie vor aktualisiert, diese erscheinen aber nicht im Log.

Code Auswählen Erweitern

Internals:
   .FhemMetaInternals 1
   DEF        group 65519  IODev=xx.GW.deCONZ
   FUUID      5eb170d1-f33f-e180-e31e-6189e91baa5faff9
   FVERSION   31_HUEDevice.pm:0.256480/2022-02-07
   ID         G65519
   INTERVAL   
   IODev      xx.GW.deCONZ
   NAME       xx.GW.deCONZ_Group
   NR         775
   STATE      on
   TYPE       HUEDevice
   lights     1
   name       deconz
   type       LightGroup
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2022-02-13 06:16:02   .associatedWith xx.GW.ConBee
     2022-02-13 06:13:31   IODev           xx.GW.deCONZ
     2022-02-13 15:01:05   alert           
     2022-02-13 15:01:05   all_on          1
     2022-02-13 15:01:05   any_on          1
     2022-02-13 15:01:05   bri             0
     2022-02-13 15:01:05   colormode       
     2022-02-13 06:16:02   ct              0
     2022-02-13 15:01:05   effect         
     2022-02-13 06:16:02   hue             0
    2022-02-13 15:01:05   onoff           1
     2022-02-13 15:01:05   pct             100
     2022-02-13 06:16:02   reachable       1
     2022-02-13 15:01:05   sat             0
     2022-02-13 06:16:02   state           on
     2022-02-13 06:16:02   xy              0,0
   helper:
     alert     
     all_on     1
     any_on     1
     bri        0
     colormode 
     ct         0
     devtype    G
     effect     
     hue        0
     onoff      1
     pct        100
     reachable  1
     sat        0
     state      on
     update_timeout 1
     xy         0,0
     json:
       etag       aa5a61e214369b0d6bccf9b835c22708
       id         65519
       name       deconz
       type       LightGroup
       action:
         alert      none
         bri        127
         colormode  hs
         ct         0
         effect     none
         hue        0
         sat        127
         scene     
         xy:
           0
           0
       devicemembership:
       lights:
         1
       scenes:
       state:
     lights:
       1          1
     scenes:
Attributes:
   DbLogExclude .*
   IODev      xx.GW.deCONZ
   alias      deConz
   cmdIcon    on:general_an@green off:general_aus@gray
   color-icons 2
   createActionReadings 1
   createGroupReadings 1
   delayedUpdate 1
   devStateIcon on:deconz@green off:deconz@lightgreen .*:deconz@yellow
   event-on-change-reading .*
   group      HUE-Group
   room       hidden
   sortby     01
   userattr   createActionReadings:1,0 createGroupReadings:1,0
   

[justme1968]

schau mal bitte in dem oben verlinkten beitrag den link zu github an. die nummer der gruppe die deconz für die alle gruppe verwendet ist scheibar auf deconz seite konfigurierbar. ansonsten habe ich das gefühl das das eigentliche problem auf deconz seite liegt. die biegen die gruppe 0 auf eine der 0xffxx gruppen um, biegen die events aber nicht wieder zurück auf gruppe 0 wie im api vorgesehen ist. oder zumindest sollten sie die gruppen für die events erzeugt werden auch in der liste alller gruppen mit aufführen.

wenn keine meldungen erzeugt werden taucht diese gruppe vermutlich beim get groups mit auf. kannst du versuchen rauszufinden woher diese gruppe kommt

[Brause]

Die Gruppe 65519 wurde damals automatisch im deconz erstellt, in Ihr ist nur der ConBee2 enthalten.
Im FhEM habe ich die Gruppe erstellt (weil mich die die Meldungen im Log neugierig gemacht hatten, was das für eine Gruppe ist).

Diese hohen ID's kannte ich bis dahin nur von der Tradfri. da beide Systeme (deconz-GW und Tradfri-GW) eine Zeitlang parallel liefen und die Lampen und Rollos nach und nach zur deconz gewandert sind,
könnte ich mir vorstellen das deconz da irgendetwas übernommen hat und die anderen 65er ID's durch gelöschte/alte Geräte intern noch reserviert sind.
Aber ich schau mal ob ich in den deconz-Eingeweihten was finde.

[Brause]

Naja fast wie erwartet.
Die gelb markierten sind Gruppen die es damals auf der Tradfri gab.
und scheinbar hat deconz auch schon mal eine All-Gruppe erstellt und wieder gelöscht.
bis ID 23 das war ich auf der deconz.

Aber im Endeffekt ist es mir auch egal. wie die All-Lights gruppe heisst und ob es sie gibt.
Ich will diese nicht schalten.
Wollte nur zeigen das die neue All-Lights nicht unbedingt die 65520 haben muss.

[slupus]

schau mal ob die meldungen mit der angehängten version weg sind.

Seit ich diese Version nutze, ist die Meldung nicht im mehr im Log zu finden. Scheint für mich also zu funktionieren.
Vielen Dank für den schnellen Support justme1968!

[rabehd]

Ich habe im Log Freezemeldungen, die eigentlich immer (meist auch nur) meine "Friends of Hue" Schalter enthalten. Leider aller paar Minuten.
Das war auch schon im früheren Modul so.
Hat jemand einen Hinweis ob das abstellbar ist und wo?

2022.03.23 10:34:41 1: [Freezemon] Lahmheit: possible freeze starting at 10:34:40, delay is 1.247 possibly caused by: fn-ReadFn(myHmUART) tmr-HUEDevice_GetUpdate(Wandschalter_WZ_Treppe) tmr-HUEDevice_GetUpdate(Wandschalter_Kue_1) tmr-HUEDevice_GetUpdate(Wandschalter_Kue_2) tmr-HUEDevice_GetUpdate(Wandschalter_WZ_Sofa) tmr-HUEDevice_GetUpdate(Wandschalter_WZ_vorn)

Das sind alle FoH-Schalter.

[justme1968]

GetUpdate deutet darauf hin die daten nicht aus einem event kommen sondern vom pollen. wie oft pollst du? es kann sein das einfach die bridge überlastet ist und nicht schnell genug antwortet. hast du HttpUtils aktiviert?

wie oft passiert das? sobald es die events gibt sollten die einzelnen devices garnicht mehr einzeln gepollt werden.

ist pollDevices aktiv?

[rabehd]

Danke für die Hinweise, das hilft sicher.
Hier erstmal ein List der Bridge (Geräte entfernt).

Code Auswählen Erweitern


Internals:
   DEF        192.168.178.66
   EventStream terminated; retrying later
   FUUID      5e5593c0-f33f-23c4-96c6-7b5335903f39b042
   FVERSION   30_HUEBridge.pm:0.257690/2022-03-03
   INTERVAL   60
   NAME       HueBridge
   NOTIFYDEV  global
   NR         666
   NTFY_ORDER 50-HueBridge
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.50.0
   bridgeid   001788FFFE6B0EE7
   has_v2_api 1
   host       192.168.178.66
   mac        00:17:88:6b:0e:e7
   manufacturer Signify
   modelName  Philips hue bridge 2015
   modelid    BSB002
   name       Wormser 34  Hue
   swversion  1950111030
   updatestate 0
   zigbeechannel 15
   READINGS:
     2022-03-22 22:28:33   groups          9/16
     2022-01-20 11:35:56   lastError       resource, /groups/8, not available
     2022-03-22 22:28:33   lights          11/16
     2022-03-22 22:28:33   rules           51/128
     2022-03-22 22:25:34   scenes          19/32
     2022-01-28 16:19:48   schedules       0
     2022-03-22 22:28:33   sensors         10/16
     2022-03-23 11:10:59   state           connected
     2022-03-17 15:59:40   swupdate        BSB002 - 1.50_SR2.1
   helper:
     apiversion 78336
     count      0
     last_config_timestamp 1648030258
     offsetUTC  3600
     updatestate 0
     HTTP_CONNECTION:
       EventSource 1
       NAME       
       addr       https://192.168.178.66:443
       auth       0
       buf       

       displayurl https://192.168.178.66/eventstream/clip/v2
       header     Accept: text/event-stream
HUE-Application-Key:lgelöscht
       host       192.168.178.66
       httpdata   
       httpdatalen -1
       httpheader HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Mar 2022 22:28:53 GMT
Content-Type: text/event-stream; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
Cache-Control: no-store
Pragma: no-cache
Referrer-Policy: no-referrer
       httpversion 1.1
       incrementalTimeout 1
       keepalive  1
       loglevel   4
       method     GET
       noshutdown 1
       path       /eventstream/clip/v2
       protocol   https
       redirects  0
       timeout    3600
       type       event
       url        https://192.168.178.66/eventstream/clip/v2
       hash:
       sslargs:

Attributes:
   httpUtils  1
   icon       hue_filled_bridge_v2
   key        gelöscht
   room       System->HUEDevice
   verbose    3


Ich habe jetzt "HttpUtils" aktiviert, mal beobachten.

Ich habe die Hilfe zu pollDevices so verstanden, dass bei v2 dieses Attribut gelöscht wird.
Wo sehe ich eigentlich ob Modul und API aktuell sind?

Wie oft es passiert? So aller 2-3 Minuten, manchmal ist der Abstand größer.

[rabehd]

Meine Freezemeldungen sind leider immer noch da.
HttpUtils hat keine Änderung gebracht.

[MadMax-FHEM]

Es ist ja auch das hmUart gelistet UND: es kann/können durchaus auch "false positive" sein.

Soll heißen, nicht alles was von FreezeMon gemeldet wird ist auch TATSÄCHLICH ein Freeze, es gibt auch "Konstellationen", wo es für FreezeMon nur so "aussieht"...

Für genauere Analyse müsste man bei FreezeMon einige Einstellungen machen und dann genau(er) prüfen, ist aber hier (aktuell) eher "OT"!?

Gruß, Joachim

[Thyraz]

Hallo Andre,

ich hatte nochmal den Fall, dass bei einem FHEM Neustart ein alter Tastendruck eines Zigbee Tasters als "neues Event" gewertet wurde und das SmartHome sich "verselbstständigt" hat.

Dürfte irgendwas mit der Zeitumstellung zu tun gehabt haben.
Ich hab wohl mittlerweile ein AT, welches das State-File zyklisch sichert, aber der Neustart den ich wöchentlich Nachts durchführen lasse war zufällig zu nah an der Zeitumstellung.

Dadurch scheint die Kombination Conbee2/Deconz und FHEM wohl der Meinung gewesen zu sein, dass das Event noch unbekannt war.

Da das Ganze immer noch seltene Randerscheinungen bleiben dürften, ein Wunsch / Vorschlag um das relativ unkompliziert zu umgehen (siehe dein Zitat unten):
Einfach ein Attribut, welches man den HUEDevices verpassen kann, mit dem man sagt "Du bist ein Device welches Events bekommt und somit nicht Pollen muss und im aktuellen Fall auch nicht Pollen soll".

Das könnte man dann z.B. Tastern zuweisen, Thermometern dafür nicht.
So kann der User das sauber bestimmen wenn er sich die Mühe machen will.
Das HUEBridge Modul muss es aber nicht selbstständig herausfinden (was wie von dir gut beschrieben ja nicht wirklich klappen kann).

Wenn man es noch feiner bestimmen will, könnte das Attribut auch eine Liste von Readings aufnehmen welche nicht gepollt werden sollen.
Dann könnte man battery etc. noch weiter zyklisch abholen lassen.
Aber darf auch gern die einfachere Version sein, wer weiß wer das außer mir jemals nutzen wird.

das ist im prinzip möglich. betrifft aber so auch alle anderen dinge die sich auf den vergleich mit einem vorherigen zustand (z.b. über OldReadingsVal) verlassen. wenn der alte zustand nicht zuverlässig ist gibt es ein problem.

dazu gibt es  mehrere mögliche lösungen, die alle ebenfalls irgendwelche nachteile haben:
- nach einem neustart wird grundsätzlich die erste zustandsänderung ignoriert -> es gehen möglicherweise
  zustände verloren

- nach einem neustart werden grundsätzlich die ersten daten die durch pollen rein kommen ignoriert
  das geht nur auf systeme bei denen die bridge auch events sendet.

- für sensoren grundsätzlich nicht mehr pollen wenn es events gibt. geht nur wenn es (zuverlässige) events
  gibt und das weiss ich eigentlich erst nach dem das erste event gekommen ist. wie merke ich mir das wenn
  ich mich nicht darauf verlassen kann das die readings nach dem neustart stimmen?

- man baut irgendwelche höchstalter für die daten ein. problem: wie alt ist alt genug zum ignorieren? 

die frage ist halt: was ist wichtiger, das der interne zustand nach einem neustart so schnell wie möglich stimmt und eventuell events doppelt kommen oder das niemals falsch ausgelöst wird und eventuell events verloren gehen. eventuell ist je nach sensor typ das eine oder das andere besser.

wie wäre ein attribut mit dem man 1., 2. oder 3. von oben und zusätzlich 4. konfigurieren kann?



ganz unabhängig davon eine geschichte: vor ein paar wochen hat der rollladen hier im schlafzimmer angefangen zu spinnen und ist mitten in der nacht mehrfach auf oder zu gefahren. nach langem suchen habe ich dann eine tablet ui installation an der wand als verantwortlichen gefunden. irgend ein netzwerk problem hat dazu geführt das das ding der meinung war jemand hat es von hand bedient.