philips hue modul

ernst1024 · 09 Oktober 2016, 17:44:02

uupppps, ähhhh ja ..... da hast du wohl recht. Irgendwie war ich da auf einem ganz anderen Dampfer, sorry für die Verwirrung.
Also es ist da.

justme1968 · 09 Oktober 2016, 17:55:52

dann ist ja alles gut

Sacerd · 09 Oktober 2016, 19:19:41

Ich hab hier irgendwie noch komische Phänomene mit den (Fhem-)Sensor-Devices des Motion-Sensors.

Die Reading-Zeitstempel gehen irgendwie immer 2 Stunden zurück. Das war eben um 19:03 Uhr:

Readings
battery 100 2016-10-09 17:03:02
dark 1 2016-10-09 17:03:02
daylight 0 2016-10-09 17:03:02
reachable 1 2016-10-09 17:03:02
state 523 2016-10-09 17:03:02

wird ein Reading geupdatet, bzw. gechanged, wird auch der Zeitstempel auf die aktuelle Uhrzeit gesetzt (Ohne Browser-Refresh). Wenn ich anschließend den Browser refresche oder das Device neu aufrufe, ändern sich die Zeitstempel wieder auf das letzt Event minus 2 Stunden.

Das heißt bei einer Änderung des states, sehen die Readings so aus:

Readings
battery 100 2016-10-09 17:03:02
dark 1 2016-10-09 17:03:02
daylight 0 2016-10-09 17:03:02
reachable 1 2016-10-09 17:03:02
state 200 2016-10-09 19:05:08

Nach Browser-Refresh wieder so:

Readings
battery 100 2016-10-09 17:05:08
dark 1 2016-10-09 17:05:08
daylight 0 2016-10-09 17:05:08
reachable 1 2016-10-09 17:05:08
state 200 2016-10-09 17:05:08

Im Log habe ich folgendes gefunden (Hue_Bright = Name des Sensor-Devices)

2016.10.09 18:59:00 4: parse status message for Hue_Bright
2016.10.09 19:00:00 4: parse status message for Hue_Bright
2016.10.09 19:01:00 4: parse status message for Hue_Bright

Die Zeitstempel der Readings werden aber trotzdem nicht aktualisiert, auch nicht bei "event-on-update-reading:.*"

Dieses Verhalten kann ich nur bei den Sensoren beobachten...was kann das sein?

justme1968 · 09 Oktober 2016, 20:21:43

das modul verwendet die zeit die vom sensor geschickt wird als timestamp für das reading. damit bekommt man unabhängig vom poling intervall die echte zeit des sensors.

fhem verwendet aber beim longpoll update immer die aktuelle zeit als timestamp.

das eigentlich problem ist aber das ich gerade eben erst gesehen habe das die zeiten in utc angegeben sind. ich ändere das im modul.

gruss
andre

justme1968 · 09 Oktober 2016, 21:10:18

bitte mal testen ob mit der angehängten version die timestamps stimmen.

gruss
andre

Sacerd · 09 Oktober 2016, 21:47:12

Zitat von: justme1968 am 09 Oktober 2016, 21:10:18
bitte mal testen ob mit der angehängten version die timestamps stimmen.

gruss
andre

Timestamps passen jetzt!
Danke übrigens für den schnellen und guten Support

justme1968 · 09 Oktober 2016, 22:25:56

ist eingecheckt und somit ab morgen im update.

gruss
andre

Custodis Intestina · 11 Oktober 2016, 21:26:10

Guten Abend Fhem - Gemeinde

Habe mich nun auch dazu entschlossen Fhem zu nutzen, nun zu meinem Problem.
Raspberry Pi3, eq3MAX über CUL-Stick und DeCONZ über 23x Stick von DE
Also Lichtsteuerung funktioniert. Komme auch über Postman auf die REST Appi von DeCONZ
Aber Fhem will einfach nicht bzw habe ich die berüchtigte JSON Fehlermeldung die hier im Thread schon mehrfach auftauchte

Hier Mal ein LOG

Zitat
2016.10.11 21:01:56 5: Cmd: >setstate global no definition<
2016.10.11 21:01:56 5: Cmd: >setstate lightlink initialized<
2016.10.11 21:01:56 5: Cmd: >setstate lightlink 2016-10-11 21:01:48 state initialized<
2016.10.11 21:01:56 5: Triggering global (1 changes)
2016.10.11 21:01:56 5: Starting notify loop for global, first event INITIALIZED
2016.10.11 21:01:56 4: HttpUtils url=http://192.168.13.11/description.xml
2016.10.11 21:01:56 4: http://192.168.13.11/description.xml: HTTP response code 200
2016.10.11 21:01:56 4: HttpUtils http://192.168.13.11/description.xml: Got data, length: 1332
2016.10.11 21:01:56 5: HUEBridge_OpenDev: got description: <?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.13.11:80/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>Philips hue (192.168.13.11) compatible Wireless Light Control Gateway</friendlyName>
<manufacturer>dresden elektronik</manufacturer>
<manufacturerURL>http://www.dresden-elektronik.de</manufacturerURL>
<modelDescription>dresden elektronik Wireless Light Control</modelDescription>
<modelName>Philips hue bridge 2012</modelName>
<modelNumber>929000226503</modelNumber>
<modelURL>http://www.dresden-elektronik.de</modelURL>
<serialNumber>XXXXXXXX</serialNumber>
<UDN>uuid:X>
<gatewayName>Eurebia</gatewayName>
<presentationURL>index.html</presentationURL>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<height>48</height>
<width>48</width>
<depth>24</depth>
<url>hue_logo_0.png</url>
</icon>
<icon>
<mimetype>image/png</mimetype>
<height>120</height>
<width>120</width>
<depth>24</depth>
<url>hue_logo_3.png</url>
</icon>
</iconList>
</device>
</root>

2016.10.11 21:01:56 4: using HUEBridge_HTTP_Request: GET config
2016.10.11 21:01:56 5: HUEBridge_HTTP_Request http://192.168.13.11/api/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/config: Got data, length: 0
2016.10.11 21:01:56 4: HUEBridge_HTTP_Request http://192.168.13.11/api/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/config: Zero length data, header follows...
2016.10.11 21:01:56 4: HUEBridge_HTTP_Request http://192.168.13.11/api/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/config: http
2016.10.11 21:01:56 3: HUEBridge_Call: failed, retrying
2016.10.11 21:01:56 4: using HUEBridge_HTTP_Request: GET config
2016.10.11 21:01:56 5: HUEBridge_HTTP_Request http://192.168.13.11/api/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/config: Got data, length: 0
2016.10.11 21:01:56 4: HUEBridge_HTTP_Request http://192.168.13.11/api/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/config: Zero length data, header follows...
2016.10.11 21:01:56 4: HUEBridge_HTTP_Request http://192.168.13.11/api/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/config: http
2016.10.11 21:01:56 3: HUEBridge_Call: failed, retrying
2016.10.11 21:01:56 3: HUEBridge_Call: failed
2016.10.11 21:01:56 2: HUEBridge_OpenDev: got empty config
2016.10.11 21:01:56 2: SecurityCheck: WEB has no associated allowed device with basicAuth. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.10.11 21:01:56 0: Featurelevel: 5.7
2016.10.11 21:01:56 0: Server started with 19 defined entities (fhem.pl:12311/2016-10-10 perl:5.020002 os:linux user:fhem pid:7933)
2016.10.11 21:01:57 4: Connection accepted from WEB_192.168.13.50_59709
2016.10.11 21:01:58 4: WEB_192.168.13.50_59709 GET /fhem?XHR=1&inform=type=status;filter=;since=1476212510.389;fmt=JSON&fw_id=94×tamp=1476212518601; BUFLEN:0
2016.10.11 21:02:00 4: Connection accepted from WEB_192.168.13.50_59710
2016.10.11 21:02:00 4: WEB_192.168.13.50_59710 GET /fhem?cmd=style%20list; BUFLEN:0
2016.10.11 21:02:00 4: name: /fhem?cmd=style%20list / RL:2841 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.10.11 21:02:00 4: Connection closed for WEB_192.168.13.50_59709: EOF
2016.10.11 21:02:00 4: WEB_192.168.13.50_59710 GET /fhem/pgm2/style.css?v=1476212515; BUFLEN:0
2016.10.11 21:02:00 4: WEB_192.168.13.50_59710 GET /fhem?XHR=1&inform=type=status;filter=;since=1476212519;fmt=JSON&fw_id=46×tamp=1476212521302; BUFLEN:0
2016.10.11 21:02:02 4: Connection accepted from WEB_192.168.13.50_59711
2016.10.11 21:02:02 4: WEB_192.168.13.50_59711 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-10.log; BUFLEN:0

Also ich erreiche die API aber die Verbindung kommt einfach nicht zu stande. Achso DeCONZ ist auf der heute rausgekommenen Version 2.04.18

justme1968 · 11 Oktober 2016, 21:36:32

ist dein fhem aktuell?

welchen wert hat das noshutdown internal?

geht es wenn du das noshutdown attribut auf 1 setzt?

gruss
andre

justme1968 · 11 Oktober 2016, 21:47:19

falls es mit gesetztem attribute geht: lösch das attribut wieder und versuch mal die angehängte version.

das problem ist das das deconz gateway andere socket einstellungen braucht als die hue bridge aber es leider nicht zuverlässig möglich ist das deconz gateway zu erkennen weil sie in der description einige falsche angaben machen und so tun als ob sie die hue bridge sind.

du scheinst aber eine neue software version zu haben bei denen manufacturer korrekt ausgefüllt ist.

gruss
andre

edit 2016-10-14: in etwas abgewandelter form eingecheckte

Custodis Intestina · 12 Oktober 2016, 08:25:18

Guten morgen

@justme1968
Ja die deconz Software wurde gestern erst freigeschalten. Wegen dem noshutdown muss ich mich erst einlesen wo der hinmuss, das wird erst heute Abend bzw morgen dann. Danke für die Hilfe ich melde mich.

Achso Fhem Update habe ich gemacht.

duu75 · 12 Oktober 2016, 10:13:01

Kriege mein Starter Kit einfach nicht sauber zum laufen.

Die Bridge habe ich mit fester IP konfiguriert, gepairt und connected.
HUEDevices wurden automatisch angelegt und funktionieren auch.
Bridge wurde mit der Android App auf aktuellste Firmware upgedatet.
FHEM ist auch aktuellste Version.

Auf der Bridge sind Attribute "pollDevices 1" und "httpUtils 1" gesetzt.

Im Log sehe ich auch jede Minute "using HttpUtils_NonblockingGet: GET lights", aber die Lampen bekommen im FHEM keine neue Info ob an oder aus oder sonst was.
Der letzte Zeitstempel der Devices ist der vom FHEM restart oder manuel ON/OFF oder statusRequest.

Wenn ich manuell die Lampen mit statusRequest abfrage, wird der Status reachable und state aktualisiert.
Der Rest bleibt alter Zeitstempel.
Beim ON/OFF werden auch noch onoff, bri etc. mit aktualisiert.

Nur automatisch in regelmäßigen Abständen erfolgt keine Aktualisierung der Stati der Lampen.
So kann ich aber nicht checken, ob nach Stromausfall/-wiederkehr die Lampen undefiniert bzw. ungewollt an sind und mittels desired und state Vergleich ausschalten.

Was ist da los?
Mache ich was falsch?

Auch pollDevices 0 und dafür dann INTERVAL 60 auf den Devices bringt keine Änderung/Lösung.

justme1968 · 12 Oktober 2016, 10:24:02

bei pollDevices muss das intervall in der bridge ungleich 0 sein und in den devices gleich 0.

setz mal httpUtils auf 0 oder lösche es.

gruss
andre

duu75 · 12 Oktober 2016, 10:39:29

Zitat von: justme1968 am 12 Oktober 2016, 10:24:02
bei pollDevices muss das intervall in der bridge ungleich 0 sein und in den devices gleich 0.

setz mal httpUtils auf 0 oder lösche es.

gruss
andre

pollDevices gelöscht, also Defaultwert 1 auf der Bridge.
Nach SHUTDOWN RESTART um 10:30:31 steht auf der Bridge die konfigurierten 60 Sekunden und auf den Devices INTERVAL 0

Habe auf der Bridge und Device1 verbose 4 und im Log sieht es so aus, aber keine Readings werden aktualisiert.

Hat das vlt. auch was mit dem allerersten Logeintrag nach dem Start zu tun "empty answer received"?

Code Auswählen


2016.10.12 10:30:31 2: HUEBridge: http request failed: http://10.0.0.5/api/*********************************: empty answer received
2016.10.12 10:30:35 4: using HttpUtils_NonblockingGet: GET lights/1
2016.10.12 10:30:35 4: using HttpUtils_NonblockingGet: GET lights/3
2016.10.12 10:30:35 4: using HttpUtils_NonblockingGet: GET lights/2
2016.10.12 10:30:35 4: using HttpUtils_NonblockingGet: GET groups/0
2016.10.12 10:30:36 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:31:26 4: using HttpUtils_NonblockingGet: GET lights
2016.10.12 10:31:26 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:32:26 4: using HttpUtils_NonblockingGet: GET lights
2016.10.12 10:32:26 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:33:26 4: using HttpUtils_NonblockingGet: GET lights
2016.10.12 10:33:26 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:34:26 4: using HttpUtils_NonblockingGet: GET lights
2016.10.12 10:34:26 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:35:26 4: using HttpUtils_NonblockingGet: GET lights
2016.10.12 10:35:26 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:36:26 4: using HttpUtils_NonblockingGet: GET 
2016.10.12 10:36:26 4: parse status message for HUEBridge
2016.10.12 10:36:26 4: HUEBridge: message for unknow sensor received: HUEBridge-S1
2016.10.12 10:36:26 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:37:26 4: using HttpUtils_NonblockingGet: GET lights
2016.10.12 10:37:26 4: parse status message for HUEBridge_HUEDevice1
2016.10.12 10:38:26 4: using HttpUtils_NonblockingGet: GET lights
2016.10.12 10:38:26 4: parse status message for HUEBridge_HUEDevice1

Habe auch schon zwischenzeitlich alles gelöscht und komplett neu konfiguriert, aber auch das gleiche Ergebnis.

justme1968 · 12 Oktober 2016, 10:58:03

das eine empty answer ist kein problem.

laut deinem log wird die bridge regelmäßig gepollt. das schaut gut aus. und es kommen antworten die geparden werden.

hast du denn zwischenzeitlich auch an den lampen etwas umgestellt? wenn es keine veränderung gab wird auch kein reading aktualisiert. auch nicht der timestamp.

trenn mal ein lampe vom strom. nach einer weile solltest du ein unreachable sehen. wenn du sie dann wieder anschliessst sollte (nach etwas kürzerer zeit) reachable zu sehen sein und on.

gruss
andre