philips hue modul

[Raven]

ich weiß nicht was passiert ist, 
Auf jeden Fall funktionierten meine Hue Lampen nicht mehr, ohne dass ich zuvor die FHEM-Konfiguration geändert hatte oder sonstige PERL Module zuvor aktualisierte.
Ich hab daraufhin ein FHEM Update durchgeführt und dann hängte FHEM mit der "bekannten" Meldung (ich hab kein Fritzmodul).

Code Auswählen Erweitern

malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/30_HUEBridge.pm line 682.

Nach Änderung der "bekannten" Zeile; läuft nun wieder alles. Gibt es ggf. noch weitere Quellen, die ich prüfen könnte, warum aus "heiterem Himmel" die o.g. Fehlermeldung beim FHEM Neustart kam? Dankeschön

Code Auswählen Erweitern

return HUEBridge_ProcessResponse($hash,decode_json($ret));

[Loredo]

Ich bekomme seit heutigem Update einen ähnlichen Fehler:

Code Auswählen Erweitern


2015.08.22 12:47:15 4: using HttpUtils_BlockingGet: GET config
2015.08.22 12:47:15 4: HttpUtils url=http://192.168.6.91/api/3b34312e73f834b60f03876495f5ffc7/config
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/share/perl5/JSON.pm line 171.




Bei mir läuft ein normales Debian Wheezy in einer virtuellen x64 Maschine.




EDIT: Stelle gerade fest, dass der Fehler deshalb kommt, weil meine HUE Bridge gerade offline ist. Da fehlt wohl noch etwas Errorhandling irgendwie :-/

[Motivierte linke Hände]

Hi, ich musste gestern feststellen, dass leider FHEM insgesamt blockiert, wenn die HUE Bridge nicht erreichbar ist und das Öffnen versucht wird. Wäre es möglich, das Öffnen der Bridge auf nonblocking umzustellen?

[justme1968]

hast du das httpUtils attribut passend gesetzt? damit steuerst du ob das pollen blocking oder non blocking ist.

gruss
  andre

[Motivierte linke Hände]

Natürlich nicht. 

Ich nehme mal an,

Code Auswählen Erweitern

attr <Bridge> httpUtils 1 (und nicht 0) sollte das Problem lösen? Mal testen.

Danke!

[Loredo]

Ich habe bei Nichterreichbarkeit auch Hänger trotz httpUtils=1 und pollDevices=1


In meinem Post oben steht ja auch, dass offenbar HttpUtils_BlockingGet verwendet wird.

[justme1968]

zeig mal bitte ein log mit verbose 4.

gruss
  andre

[Loredo]

siehe mein Post oben
http://forum.fhem.de/index.php/topic,11020.msg325061.html#msg325061

[Motivierte linke Hände]

So, nun habe ich auch die Information zu httpUtils (hier http://forum.fhem.de/index.php?topic=30895.0) gefunden. Ins Wiki habe ich httpUtils als Tipp mit aufgenommen. Vielleicht wäre es für zukünftige Generationen hilfreich, httpUtils (und pollDevices) auch in der Commanref zu dokumentieren.

[Motivierte linke Hände]

Auch hier gibt es mit

Code Auswählen Erweitern

attr HUEBridge1 httpUtils 1 nach wie vor ein freeze bei Nichterreichbarkeit der Bridge:

Code Auswählen Erweitern

2015.09.05 13:34:27 1: Perfmon: possible freeze starting at 13:34:25, delay is 2.107
2015.09.05 13:34:30 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:34:30 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:34:30 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:35:05 3: get gds alerts 108115000 : Keine Warnmeldung für die gesuchte Region vorhanden.
2015.09.05 13:35:30 4: using HttpUtils_NonblockingGet: GET lights/2
2015.09.05 13:35:30 4: using HttpUtils_NonblockingGet: GET lights/3
2015.09.05 13:35:30 4: using HttpUtils_NonblockingGet: GET lights/1
2015.09.05 13:35:30 1: Perfmon: possible freeze starting at 13:35:28, delay is 2.141
2015.09.05 13:35:33 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:35:33 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:35:33 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:36:33 4: using HttpUtils_NonblockingGet: GET lights/2
2015.09.05 13:36:33 4: using HttpUtils_NonblockingGet: GET lights/3
2015.09.05 13:36:33 4: using HttpUtils_NonblockingGet: GET lights/1
2015.09.05 13:36:33 1: Perfmon: possible freeze starting at 13:36:31, delay is 2.259
2015.09.05 13:36:36 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:36:36 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:36:36 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:36:37 4: using HttpUtils_NonblockingGet: GET config
2015.09.05 13:36:39 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:37:36 4: using HttpUtils_NonblockingGet: GET lights/2
2015.09.05 13:37:36 4: using HttpUtils_NonblockingGet: GET lights/3
2015.09.05 13:37:36 4: using HttpUtils_NonblockingGet: GET lights/1
2015.09.05 13:37:36 1: Perfmon: possible freeze starting at 13:37:34, delay is 2.107
2015.09.05 13:37:39 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:37:39 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner
2015.09.05 13:37:39 2: HUEBridge1: http request failed: 192.168.1.11: Keine Route zum Zielrechner

Ich hoffe, das Log mit verbose 4 hilft?

[Jumbo]

hab genau das gleiche Problem. Zwar nicht so oft, aber die gleichen Meldungen kommen immer wieder.

[sw]

Hallo, ich muss noch einmal das Thema "mehrere Bridges" öffnen.
Grundsätzlich funktioniert meine Testkonfiguration mit 2 HUE Bridges.

Allerdings habe ich das Problem, das sich Fhem nicht wieder mit einer Bridge verbindet, wenn diese einmal nicht erreichbar war (und Fhem das Disconnect bemerkt hat).
Ich habe die Bridges mit statischen Adressen definiert:

Code Auswählen Erweitern


define hub_og_HueBridgeOG HUEBridge 192.168.178.151
...viele weitere Einträge...
define hub_dg_HueBridgeDG HUEBridge 192.168.178.152


Zum Test ziehe ich den Netzwerkstecker der Bridge auf 192.168.178.151 ab. Im Log sehe ich dann folgendes:

Code Auswählen Erweitern


2015.09.25 17:29:22 1: HUEBridge_HTTP_Request http://192.168.178.151/api/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/config: Can't connect to http://192.168.178.151:80
2015.09.25 17:29:22 3: HUEBridge_Call: failed, retrying
2015.09.25 17:29:22 3: HUEBridge_Detect
2015.09.25 17:29:23 3: HUEBridge_Detect: 192.168.178.152
2015.09.25 17:29:23 3: unauthorized user
2015.09.25 17:29:23 3: unauthorized user
2015.09.25 17:29:23 3: unauthorized user


Ich interpretiere das so: Die Instanz  hub_og_HueBridgeOG bemerkt den Verbindungsabbruch. Statt jetzt auf der konfigurierten Adresse 192.168.178.151 zu warten, bis die Bridge wieder auftaucht, wird das Netzwerk durchsucht, die andere Bridge auf  192.168.178.152 gefunden und der Connect versucht. Da  der Zugriffschlüssel falsch ist, geht das (Gott-sei-dank) schief.

Wenn ich die Bridge auf 192.168.178.151 wieder anschliesse, ändert sich nichts, das Log wird weiterhin mit "unautorized user" Einträgen geflutet.
Erst ein "shutdown restart" behebt das Problem.

Mache ich etwas falsch, oder kann das Verhalten nur im Modul geändert werden?

Gruß, Sven

Nachtrag 03.10.15:
Ich hatte bei meinen Bridges das Attribut "httpUtils" nicht definiert. Damit kam es zum beschriebenen Fehlverhalten.
Ich habe jetzt "httpUtils" auf 1 gesetzt. Damit funktioniert der Reconnect einwandfrei. Andere Werte von "httpUtils" habe ich nicht probiert.
Danke auch an Andre für den Mailsupport.
Gruß Sven

Nachtrag 05.10.15:
In der aktuellen Version von Andre (http://forum.fhem.de/index.php/topic,41777.0.html) klappt der Reconnect auch ohne Attribut "httpUtils" einwandfrei, gerade getestet - danke.
Gruß Sven

[P.A.Trick]

Bei mir blockiert die Abfrage der Bridge auch FHEM, trotz non-Blocking-Get!

Code Auswählen Erweitern

2015.10.04 12:16:48.884 4: parse status message for hue_bridge
2015.10.04 12:16:51.423 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:17:06.741 1: Perfmon: possible freeze starting at 12:17:04, delay is 2.74
2015.10.04 12:17:14.701 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:17:14.722 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:17:48.859 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:17:48.888 4: parse status message for hue_bridge
2015.10.04 12:17:51.436 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:18:14.707 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:18:14.726 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:18:48.865 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:18:48.893 4: parse status message for hue_bridge
2015.10.04 12:18:51.443 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:19:09.751 1: Perfmon: possible freeze starting at 12:19:07, delay is 2.75
2015.10.04 12:19:14.713 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:19:14.734 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:19:48.872 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:19:48.914 4: parse status message for hue_bridge
2015.10.04 12:19:51.449 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:20:14.718 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:20:14.739 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:20:48.879 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:20:48.908 4: parse status message for hue_bridge
2015.10.04 12:20:51.455 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:21:12.765 1: Perfmon: possible freeze starting at 12:21:10, delay is 2.764
2015.10.04 12:21:14.725 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:21:14.745 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:21:48.887 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:21:48.914 4: parse status message for hue_bridge
2015.10.04 12:21:51.462 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:22:00.589 3: CUL_HM set EG.WC.Deckenleuchte on
2015.10.04 12:22:14.731 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:22:14.752 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:22:44.708 3: CUL_HM set EG.WC.Deckenleuchte getConfig
2015.10.04 12:22:48.892 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:22:48.920 4: parse status message for hue_bridge
2015.10.04 12:22:51.470 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:23:00.315 3: CUL_HM set vccu hmPairForSec 600
2015.10.04 12:23:15.789 1: Perfmon: possible freeze starting at 12:23:13, delay is 2.788
2015.10.04 12:23:15.796 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:23:15.825 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:23:37.431 3: CUL_HM pair: EG.WC.Deckenleuchte switch, model HM-LC-Sw1PBU-FM serialNr LEQ1310492
2015.10.04 12:23:41.456 3: CUL_HM set EG.WC.Deckenleuchte getConfig
2015.10.04 12:23:48.899 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:23:48.929 4: parse status message for hue_bridge
2015.10.04 12:23:50.871 3: CUL_HM EG.WC.Deckenleuchte repeat, level 00 instead of C8
2015.10.04 12:23:51.476 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:24:15.633 3: CUL_HM set EG.WC.Deckenleuchte on
2015.10.04 12:24:15.823 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:24:15.847 4: parse status message for EG.WZ.Fensterleuchte
2015.10.04 12:24:18.305 3: CUL_HM set EG.WC.Deckenleuchte off
2015.10.04 12:24:48.904 4: using HttpUtils_NonblockingGet: GET config
2015.10.04 12:24:48.931 4: parse status message for hue_bridge
2015.10.04 12:24:51.482 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.04 12:25:18.796 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.04 12:25:18.807 1: Perfmon: possible freeze starting at 12:25:16, delay is 2.806


[justme1968]

@sw: dein fehler sollte mit der version hier: http://forum.fhem.de/index.php/topic,41777.0.html behoben sein.

@P.A.Trick: über die httputils ist nur die eigentliche antwort nicht blockierend. der verbindungsaufbau selber kann immer noch blockieren.

setz mal bitte pollDevices in der bridge auf 1, das poll intervall in der bridge auf den gewünschten wert und lösche das intervall in allen lampen. damit sollte es unterm strich weniger anfragen an die bridge geben.

gruss
  andre

[P.A.Trick]

Danke werde ich ausprobieren!