philips hue modul

[Loredo]

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

Hm, in meinen Modulen scheint auch der Aufbau nicht zu blockieren. Dort macht es keinen Unterschied, ob das Device erreichbar ist oder nicht.
Was machst du anders?




Gruß
Julian

[Loredo]

PS: Nach dem heutigen Update startet FHEM nicht mehr bei aktiviertem HUE Modul.
Folgende Meldung erhalte ich, bevor der Perl Prozess stirbt:

Code Auswählen Erweitern



2015.10.05 10:28:34 2: HUE: http request failed: http://192.168.6.91/api/xxxxxxxx: empty answer received
2015.10.05 10:28:35 4: using HttpUtils_NonblockingGet: GET lights/1
2015.10.05 10:28:35 4: using HttpUtils_NonblockingGet: GET lights/2
2015.10.05 10:28:35 4: using HttpUtils_NonblockingGet: GET lights/3
2015.10.05 10:28:35 4: using HttpUtils_NonblockingGet: GET lights/4
2015.10.05 10:28:35 4: using HttpUtils_NonblockingGet: GET lights/5
2015.10.05 10:28:37 4: using HttpUtils_NonblockingGet: GET groups/0
2015.10.05 10:28:38 4: using HttpUtils_NonblockingGet: GET sensors/2
2015.10.05 10:28:38 4: using HttpUtils_NonblockingGet: GET groups/1
2015.10.05 10:28:38 4: using HttpUtils_NonblockingGet: GET groups/2
substr outside of string at ./FHEM/31_HUEDevice.pm line 849.



Dabei ist meine Bridge so definiert:

Code Auswählen Erweitern



define HUE HUEBridge 192.168.6.91 30
attr HUE DbLogExclude .*
attr HUE alias Hue Bridge
attr HUE devStateIcon Connected:rc_GREEN update.*:rc_YELLOW *:rc_RED
attr HUE group Infrastructure
attr HUE httpUtils 1
attr HUE icon hue_bridge
attr HUE key xxxxxxxx
attr HUE pollDevices 1
attr HUE room System
attr HUE verbose 5







Edit:


Nachdem ich die Bridge und alle HUE Devices gelöscht und über Autocreate neu angelegt habe, startet FHEM wieder.
Anschließend habe ich httpUtils=1 und pollDevices=1 gesetzt. Beim Starten hängt FHEM sich jetzt nicht mehr auf, aber diese Meldungen hier bleiben:

Code Auswählen Erweitern


2015.10.05 10:57:49 2: HUE: http request failed: http://192.168.6.91/api/xxxxx: empty answer received
2015.10.05 10:57:56 2: HUE: http request failed: http://192.168.6.91/api/xxxxx/groups/2: empty answer received



Wenn ich die URLs manuell im Browser aufrufe, ist die Antwort nicht leer, sondern enthält den erwarteten JSON Code.

[justme1968]

der fehler hat nichts mit dem update von heute zu tun. hast du in fhem ein device für einen hue sensor definiert? da war noch etwas nicht in ordnung. hab es eben eingecheckt.

die empty answer meldungen sind schon immer da. scheinbar kommen die ab und zu wenn die bridge zu beschäftigt ist. oder sind die bei dir sehr oft vorhanden?

gruss
  andre

[Loredo]

Ja, ich hatte noch einen HUE Tap drin (just for fun).


Die Empty Answers kommen bei jedem FHEM Neustart. Ich kann mir nicht vorstellen, dass die Bridge da ständig so beschäftigt ist. Ich schalte recht selten etwas und es sind "nur" 5 Leuchten angemeldet.

[justme1968]

hat der tap funktioniert ? ich glaube die verzögerungen durch das pollen sind nicht wirklich praktikabel.

wenn es nur beim neustart ist ist es (glaube ich) erst mal kein problem. da fragt fhem unter umständen zeit gleich alle devices ab und die bridge kommt mit den gleichzeitigen anfragen nicht klar. vielleicht kommt es auch auf das netzwerk an.

ich bekomme keine bei 13 devices.

gruss
  andre

[Loredo]

nee, der Tap war unbrauchbar.


Es kommt hauptsächlich beim Start, allerdings auch unregelmäßig häufig während des Betriebs. Eine Regelmäßigkeit lässt sich da nicht erkennen.


Du hattest irgendwo auch geschrieben, wenn man pollDevices=1 nutzt, dann sollte man in den Devices das eigene Polling ausschalten. Das hatte ich bisher auch, indem ich in der Definition hinter der ID eine 0 gesetzt habe.
Nachdem ich gerade alle Devices per Autocreate neu angelegt habe, habe ich das jetzt erstmal noch weggelassen.

[justme1968]

wenn du nichts angibst wird automatisch der passende default abhängig vom bridge device gewählt. du siehst am internal INTERVAL ob das funktioniert hat. ganz optimal ist es aber nicht weil es nach setzen von pollDevices erst nach einem neustart greift.

gruss
  andre

[kennymc.c]

http://www.newscenter.philips.com/de_de/standard/news/lighting/20151005_Philips_Hue_und_Apple_HomeKit.wpd#.VhKyS7zF4Uo
Seit heute ist übrigens eine neue Bridge erhältlich, die sie endlich für Apple HomeKit kompatibel machen soll. Wenn man schon eine Bridge hat, bekommt man die neue ab November 33% günstiger. In der Pressemitteilung steht übrigens auch, dass die Bridge kompatibel mit Drittanwender HomeKit Apps sein soll. Vielleicht ja was zu HomeKit Integration in Fhem.

[justme1968]

es soll auch neue hellere birnen geben.

schön wäre es wenn es endlich ein push api gibt. wenn das nicht der fall ist ist immer noch homebridge mit dem fhem shim besser als die native homekit Integration weil sonst der status bis zum nächsten pollen auseinander läuft.

ich bin gespannt ...

gruß
  andre

ps: interessant wird das es vermutlich bald billige second hand bridges gibt die sich als repeater verwenden lassen.

[P.A.Trick]

Hm, in meinen Modulen scheint auch der Aufbau nicht zu blockieren. Dort macht es keinen Unterschied, ob das Device erreichbar ist oder nicht.
Was machst du anders?




Gruß
Julian

Ich habe non-Blocking mal abgestellt und dann klappt alles wunderbar. Ich hatte übrigens mit non-Blocking auch diese Empty Meldungen (habe nur 2 Devices).
@Loredo: Stelle doch mal HTTPUTILS und POLLDEVICES ab und beobachte ob du noch empty Nachrichten bekommst!

[Loredo]

Nein, dann bekomme ich diese Meldungen nicht. Ich nahm an das sei klar
Ich möchte ja Non-Blocking gerne einsetzen bzw. belassen und es nicht abändern.

[P.A.Trick]

Wie gesagt, bei mir ist non-Blocking suboptimal, da auch manche Schaltbefehle scheinbar einfach untergehen!

[sw]

Ich kann die Beobachtung von P.A.Trick (leider) bestätigen:
mit "httpUtils 1" werden die "hinteren" 2 Lampen einer Lightscene aus 8 Hue Devices fast nie geschaltet.
Einzeln lassen sich diese Devices einwandfrei ansprechen.

Mit "httpUtils 0" funktioniert die Lightscene einwandfrei.

Blöd: ich würde gerne den nonBlocking Call verwenden ...

[Loredo]

ah, das erklärt dann auch das, was einige bei Nutzung der ambiHue Funktion im PHTV Modul mal gemeldet haben.

[Loredo]

Habe übrigens auch httpUtils als Attribut entfernt und siehe da, keine Meldung mehr über leere Antworten bisher wie bei den anderen.