philips hue modul

[Phiolin]

"Update done" bedeutet normalerweise, dass ein Update fertig installiert wurde. Es sollte also eigentlich schon drauf sein.
Das aktuelle Update scheint bei vielen nicht wirklich gut zu laufen. Von daher ist das vielleicht auch einfach nur ein weiterer Fehler der jetzt auftritt. Liegt meines Erachtens auch nicht nur an FHEM, da die Bridge bei mir auch ihre internen Regeln nicht mehr ordentlich verarbeitet und Sensoren teilweise nicht ordentlich aktualisiert.

[Phiolin]

Ich habe im HUE Developer Forum ein Thema zu dem Problem gestartet, wo ich auch weitere Beobachtungen dokumentieren werde: https://developers.meethue.com/content/firmware-1801260942-bridge-v2-complete-broke-my-setup

Bei mir sieht es z.B. so aus, dass wenn ich einen PUT Request abschicke um einen Lightstate in einer Szene zu ändern, die Bridge zur Verarbeitung dieses Requests über 5 Sekunden braucht und in dieser Zeit keine weiteren Requests akzeptiert. Das erklärt natürlich auch, warum meine ganzen Lightstate Änderungen über FHEM ständig fehlschlagen. Das hat vor dem Update problemlos funktioniert, mit dutzenden von Lightstate Änderungen innerhalb von 1-2 Sekunden. Jetzt scheint sich die Bridge damit schwer zu tun.
Das betrifft auch nicht nur FHEM, sondern lässt sich auch mit dem Bridge-internen API Debug Tool nachvollziehen, wie in o.g. Thread beschrieben.
Einfach mal einen PUT Request für eine Lightstate Änderung absetzen und in einem 2. Fenster direkt versuchen per GET irgendwas von der Bridge abzurufen (z.B. /api/<key>/config). Bei mir bekomme ich dabei als Antwort nur "Error 0", was wohl soviel heißt, wie das die Bridge den Request gar nicht beantwortet hat. Erst 5-10 Sekunden später beantwortet die Bridge bei mir wieder Anfragen.
Würde mich interessieren, ob das jemand bei sich nachvollziehen kann oder ob das ein individuelles Problem bei meiner Bridge ist.

[Phiolin]

Es gibt aber trotzdem noch ein Problem mit dem FHEM Modul.
Ich habe hier z.B. gerade einen CLIPGenericStatus Sensor, der laut HUE API (Debug Tool) den Status 0 hat.
Trotzdem wird er mir in FHEM mit Status 1 angezeigt.

HUEBridge API Debug Tool:

Code Auswählen Erweitern

GET /api/<key>/sensors/19

Result:
{
"state": {
"status": 0,
"lastupdated": "none"
},
"config": {
"on": true,
"reachable": true
},
"name": "Motion SZ On/Off Switch",
"type": "CLIPGenericStatus",
"modelid": "SleepState",
"manufacturername": "FHEM",
"swversion": "1.0",
"uniqueid": "ABCABCEEAE",
"recycle": false
}

FHEM:

Code Auswählen Erweitern

Internals:
   DEF        sensor 19  IODev=DG.az.NE.HueBridge
   ID         S19
   INTERVAL   
   IODev      DG.az.NE.HueBridge
   NAME       OG.sz.Hue.MotionSensorSwitch
   NR         232
   STATE      Initialized
   TYPE       HUEDevice
   manufacturername FHEM
   modelid    SleepState
   name       Motion SZ On/Off Switch
   on         1
   reachable  1
   swversion  1.0
   type       CLIPGenericStatus
   uniqueid   ABCABCEEAE
   READINGS:
     2018-02-10 12:13:51   reachable       1
     2018-02-10 12:13:51   state           1
   helper:
     devtype    S
     update_timeout 1
     setList:
Attributes:
   IODev      DG.az.NE.HueBridge
   event-on-change-reading state
   group      Automatik-Licht
   room       Schlafzimmer

Wenn ich mir die Response der Bridge auf den Status Call vom HUEBridge Modul anschaue , dann ist der Status in dem zurückgegebenen JSON auch korrekt auf 0 gesetzt.

Verbose 5 auf dem Sensor Device liefert beim Refresh:

Code Auswählen Erweitern

2018.02.10 20:25:42 4: parse status message for OG.sz.Hue.MotionSensorSwitch
2018.02.10 20:25:42 5: {
  'swversion' => '1.0',
  'recycle' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
  'config' => {
                'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
                'reachable' => $VAR1->{'config'}{'on'}
              },
  'type' => 'CLIPGenericStatus',
  'name' => 'Motion SZ On/Off Switch',
  'uniqueid' => 'ABCABCEEAE',
  'manufacturername' => 'FHEM',
  'modelid' => 'SleepState',
  'state' => {
               'status' => 0,
               'lastupdated' => 'none'
             }
}


Wie man sieht ist hier der Status auch korrekt auf 0. Trotzdem wird er in FHEM nicht geändert.
Wenn ich das richtig sehe, wird kein Update durchgeführt, wenn "lastupdated" von der Bridge auf "none" gesetzt ist (in HUEDevice_Parse für Devtype S).
Da das offenbar bei der neuen Firmware regelmäßig passiert - warum auch immer - werden jetzt dann in FHEM die Sensoren nicht mehr aktualisiert.
Das ist natürlich auch ganz toll...

Hier noch ein List vom HueBridge Device wegen der Attribute:

Code Auswählen Erweitern

Internals:
   DEF        10.0.0.44 20
   INTERVAL   20
   NAME       DG.az.NE.HueBridge
   NOTIFYDEV  global
   NR         20
   NTFY_ORDER 50-DG.az.NE.HueBridge
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.23.0
   host       10.0.0.89
   mac        00:17:88:23:ab:cd
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   modelid    BSB002
   name       Huey
   swversion  1801260942
   updatestate 0
   zigbeechannel 11
   READINGS:
     2017-12-15 16:45:27   lastError       resource, /sensors/54, not available
     2018-02-10 20:06:22   state           connected
     2018-02-09 09:07:28   swupdate        BSB002 1.23.0
   helper:
     apiversion 71424
     count      0
     last_config_timestamp 1518289582
     offsetUTC  3600
     updatestate 0
Attributes:
   icon       hue_filled_bridge_v2
   key        <key>
   noshutdown 1
   pollDevices 2
   queryAfterSet 0
   room       Arbeitszimmer

Edit: Habe das bei mir jetzt per Workaround behoben, indem ich wenn lastupdated = none ist einfach die aktuelle Uhrzeit annehme. Das führt zwar zu erhöhten Reading Updates in FHEM, ist aber besser als überhaupt kein Update für die Sensoren zu bekommen.

[Mitch]

Ich hatte gestern einen Stromausfall, leider 4 Stunden in der Nacht, so dass die USV nicht mehr reichte.

Heute habe ich festgestellt, dass meine HUE Bridge nicht mehr reagiert.
Keine Ahnung, ob das zusammen hängt.

Habe die Bridge schon gelöscht und neu angelegt, keine Besserung.

Selbst wenn ich die Bridge vom Strom trenne, steht in FHEM immer noch "initialized".
Auch ein get statusRequest änder nichts, aber auch keinen Fehler.

Habe die Bridge wieder an dem Strom und ein verbose 5 liefert mir bei get statusRequest:

Code Auswählen Erweitern

2018.02.10 20:27:19 2: HUEBridge_OpenDev: got empty config
2018.02.10 20:27:19 3: HUEBridge_Call: failed
2018.02.10 20:27:19 3: HUEBridge_Call: failed, retrying
2018.02.10 20:27:19 4: using HUEBridge_HTTP_Request: GET config
2018.02.10 20:27:19 3: HUEBridge_Call: failed, retrying
2018.02.10 20:27:19 4: using HUEBridge_HTTP_Request: GET config

</root>
</device>
</iconList>
</icon>
<url>hue_logo_0.png</url>
<depth>24</depth>
<width>48</width>
<height>48</height>
<mimetype>image/png</mimetype>
<icon>
<iconList>
<presentationURL>index.html</presentationURL>
<UDN>uuid:2f402f80-da50-11e1-9b23-001788289ffe</UDN>
<serialNumber>001788289ffe</serialNumber>
<modelURL>http://www.meethue.com</modelURL>
<modelNumber>BSB002</modelNumber>
<modelName>Philips hue bridge 2015</modelName>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<manufacturerURL>http://www.philips.com</manufacturerURL>
<manufacturer>Royal Philips Electronics</manufacturer>
<friendlyName>Philips hue (192.168.0.59)</friendlyName>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<device>
<URLBase>http://192.168.0.59:80/</URLBase>
</specVersion>
<minor>0</minor>
<major>1</major>
<specVersion>
<root xmlns="urn:schemas-upnp-org:device-1-0">
2018.02.10 20:27:19 5: HUEBridge_OpenDev: got description: <?xml version="1.0" encoding="UTF-8" ?>

[kennymc.c]

Mir ist der Call: failed Fehler im Log heute auch aufgefallen als die Lampensteuerung plötzlich über Fhem nicht mehr funktionierte. Hab eben aber einfach mal ein Fhem Update gemacht und danach neu gestartet. Jetzt geht auch schon wieder alles wie bisher

[Phiolin]

Wer noch Probleme wie "Call failed" hat, sollte das noshutdown Attribut für die HUEBridge auf 1 stellen. Das sollte jetzt nach dem Update von vorgestern auch Default sein.

Es werden aber einige Probleme bleiben, die offenbar durch Bugs in der neuen Bridge Firmware verursacht werden. Diese fallen möglicherweise nur bei größeren oder komplexeren Installation auf, das normale Ein/Aus der Lampen ist davon nicht betroffen:

- Lastupdated Felder für Sensoren werden manchmal von der Bridge auf "none" gesetzt ohne erkennbaren Grund. Dann aktualisiert FHEM den Status des Sensors nicht mehr. Das kann im Übrigen auch Regeln durcheinander bringen, die mit ddx Operatoren prüfen, wie lange die letzte Status-Änderung schon her ist (z.B. Bewegungsmelder). Äußert sich dadurch, dass der Bewegungsmelder das Licht zwar einschaltet, aber dann nicht mehr automatisch ausschaltet. Das könnte auch nur eine Folge des Updates sein, denn bei mir ist das in den letzten 24 Stunden definitiv deutlich besser geworden als es direkt nach dem Firmware Update war. Vielleicht werden beim Update einmalig alle Sensoren auf lastupdated = none gesetzt und müssen sich davon erst "erholen"...
- Das "modifyscene" Kommando der HueBridge führt zum Freeze auf der Bridge der bis zu 10 Sekunden anhalten kann. Während dieser Zeit werden keine anderen Befehle mehr von der Bridge verarbeitet.

[Mitch]

Danke euch, ein update hat es gefixet

[Numael]

Ich hab mich auch mal im Philips Dev Forum angehängt. Probleme mit dem Bewegungsmeldern hab ich nämlich auch. Manchmal gehen die Lichter einfach nicht mehr aus. Erst wenn ich erneut Bewegung auslöse passiert was.
Und ich kann so gut wie keine LightScenes mehr nutzen. Bei mehr als 2 Lampen in der Szene wird nicht mehr zuverlässig geschaltet.

[blackbite]

OK,
hab mich auch an den HUE-Dev. Beitrag gehängt. Mal sehen ob und was dazu geantwortet wird. Vermutlich braucht die Bridge für das sagenumwobene HUE Entertainment mehr "Denkpausen". 
Meine LightScenes für "homecoming" und "lasse HUE 5x rot blinken, wenn ein bestimmter Bewegungsalarm ausgelöst wird und stelle danach die vorherige LightScene wieder her" sind im Moment leider auch hinfällig.

P.S: Updates tragen zum Erhalt unzähliger IT-Arbeitsplätze bei...

[Numael]

Könnte evtl. dieser Beitrag helfen das die Kommunikation mit der Bridge wieder zuverlässiger klappt?

https://developers.meethue.com/content/loxone-script-hue-light-http11

[Phiolin]

Nein, ein einfaches sleep vor dem schließen der Verbindung reicht leider nicht.
Davon abgesehen, dass das Problem ja selbst in dem Bridge eigenen API Debug Tool auftaucht.

Ich habe das gerade mal ausprobiert indem ich ein usleep 2000 in HUEBridge_HTTP_Request eingebaut habe. Die Bridge friert aber trotzdem für 5-10 Sekunden ein, sobald ich ein modifyscene Kommando ausführe.

Code Auswählen Erweitern

  syswrite $conn, $hdr;
  syswrite $conn, $data if(defined($data));
  Log3 undef, 1, "HUEBridge_HTTP_Request $displayurl: sleeping 2 seconds";
  usleep(2000);
  shutdown $conn, 1 if(!$noshutdown);

Ergebnis:

Code Auswählen Erweitern

2018.02.13 17:58:13 3: HUEBridge_Call: failed
2018.02.13 17:58:17 1: HUEBridge_HTTP_Request http://10.0.0.44/api/key: sleeping 2 seconds
2018.02.13 17:58:17 3: HUEBridge_Call: failed, retrying
2018.02.13 17:58:17 1: HUEBridge_HTTP_Request http://10.0.0.44/api/key: sleeping 2 seconds
2018.02.13 17:58:17 3: HUEBridge_Call: failed, retrying
2018.02.13 17:58:17 3: HUEBridge_Call: failed


Nachtrag:
Ich habe gerade mal in der API geschaut (https://developers.meethue.com/documentation/scenes-api#43_modify_scene).
Das FHEM HUEBridge Modul benutzt offenbar einen veralteten Weg um Lightstates zu ändern. Anstatt nach /scene/<id>/lights/<id>/state sollte ab Version 1.11 eigentlich besser nach /scene/<id>/lightstates/<id> geschrieben werden.
Wenn ich das bei mir ändere, funktioniert modifyscene wieder ohne Verzögerungen.

Code Auswählen Erweitern

--- ../30_HUEBridge.pm 2018-02-13 18:13:44.336628218 +0100
+++ 30_HUEBridge.pm 2018-02-13 18:13:55.136675379 +0100
@@ -632,7 +632,7 @@
       HUEDevice_SetParam(undef, \%obj, $cmd, $value, $value2);
     }

-    my $result = HUEBridge_Call($hash, undef, "scenes/$arg/lights/$light/state", \%obj, 'PUT');
+    my $result = HUEBridge_Call($hash, undef, "scenes/$arg/lightstates/$light", \%obj, 'PUT');
     return $result->{error}{description} if( $result->{error} );

     return undef;


[stera]

Hallo,

ich hoffe die Probleme können bald gelöst werden. Bei mir schalten auch die Lampen nicht alle Ein/Aus, wenn mehrere Befehle hintereinander folgen.

Habe lange nichts von Andre hier gelesen. Hoffe er hat bald eine Lösung parat.

Gruß,
SteRa

[justme1968]

ich habe eben eine version eingecheckt die das neue api für modifyscene verwendet. das hatte ich beim umbau damals scheinbar übersehen.

mehr ideen habe ich leider aktuell nicht. ich verwende auch noch die alte firmware und kann nicht wirklich testen.

beim neuen 10 kommandos/sekunde wird scheinbar auch das on selber mitgezählt. das schickt fhem aber nur noch wenn die lampe aktuell einen anderen zustand hat.

ich habe keine idee ob man hier noch sparen kann, vielleicht ist aber auch in der aktuellen bridge firmware mit der zählung etwas im eimer. d.h. es wird nicht auf 10 pro sekunde begrenzt sondern auf 1 pro 1/10 sekunde.

[Markus M.]

ich habe eben eine version eingecheckt die das neue api für modifyscene verwendet. das hatte ich beim umbau damals scheinbar übersehen.

Klappt bei mir nicht, geht irgendwie trotzdem noch auf den alten Aufruf.

Code Auswählen Erweitern

apiversion 1.23.0
   helper:
     apiversion 71424


Allerdings funktioniert es auch mit dem neuen Aufruf mit lightstates bei mir nicht:

Code Auswählen Erweitern

2018.02.14 15:17:26 4: using HUEBridge_HTTP_Request: PUT scenes/XXXXhJd5FHbXXXX/lightstates/2
2018.02.14 15:17:26 3: HUEBridge_Call: failed, retrying
2018.02.14 15:17:26 4: using HUEBridge_HTTP_Request: PUT scenes/XXXXhJd5FHbXXXX/lightstates/2
2018.02.14 15:17:26 3: HUEBridge_Call: failed, retrying
2018.02.14 15:17:26 3: HUEBridge_Call: failed
2018.02.14 15:17:26 4: using HUEBridge_HTTP_Request: PUT scenes/XXXXhJd5FHbXXXX/lightstates/3
2018.02.14 15:17:26 3: HUEBridge_Call: failed, retrying
2018.02.14 15:17:26 4: using HUEBridge_HTTP_Request: PUT scenes/ORymhJd5FHb0ecT/lightstates/3
2018.02.14 15:17:26 3: HUEBridge_Call: failed, retrying
2018.02.14 15:17:26 3: HUEBridge_Call: failed


[justme1968]

ich hatte die beiden versionen vertauscht. habs es eben repariert. merke: nichts am frühen morgen einchecken.


warum es bei Phiolin hilft und bei dir nicht kann ich aber nicht sagen...