philips hue modul

[justme1968]

ab morgen gibt es folgende änderungen:

• nach einem set wird der darauf folgende status update um 1 sekunde verzögert. dadurch lassen sich mehrere lampen direkt nacheinander schalten ohne das zwischendurch nach jeder lampe der status abgefragt wird sondern erst nach dem alle lampen durch sind. damit werden die verzögerungen zwischen dein einzelnen lampen minimiert. (mehr dazu findet sich ab hier: http://forum.fhem.de/index.php/topic,16103.msg111456.html#msg111456)


• die zweite änderung ist eine erste möglichkeit gruppen direkt über die bridge zu steuern:
  
  hierbei handelt es sich um gruppen von lampen die gemeinsam geschaltet werden. hiermit lassen sich ebenfalls verzögerungen vermeiden.
  
  die aktuelle firmware der bridge hat aber leider noch einige einschränkungen:
  
  
  • gruppe 0 sind immer alle erreichbaren lampen
  • anglernte lc fernbedienungen legen jeweils eine gruppe mit den der gepairten lampen an
  • es gibt maximal 16 gruppen
  • zur zeit lassen sich über gruppen nur alle lampen identisch schalten. also entwerder alle auf die gleiche farbe, alle aus, alle an (hierbei bleiben die farben aber erhalten), oder alle auf alert.
  • und die zur zeit größte: es lassen sich über das api offiziell noch keine gruppen selber anlegen
  
  was noch kommt:
  
  
  • selber gruppen anlegen (eventuell abhängig von firmware updates)
  • gruppen mit unterschiedlich gesteuerten lampen sobald das scene api der bridge verfügbar ist
  
  alle auf der bridge verfügbaren gruppen lassen sich mit 'get <bridge> groups' auflisten und werden beim neustart automatisch angelegt.
  
  
  

gruss
  andre

Beispiele:

Code Auswählen Erweitern

define gruppeAlle HUEDevice group 0

Code Auswählen Erweitern

set gruppeAlle on

Code Auswählen Erweitern

set gruppeAlle alert select

[Jaydee]

An anderer Stelle scheint dies aber Verzögerungen zu produzieren...

Nachdem dimUp/dimDown eingeführt wurde hatte ich dies auf tasten meiner Fernbedienung gelegt. Anschließend konnte man wunderbar durch zügiges Drücken der Tasten hoch- und runterdimmen.

Jetzt ist es leider so, dass nach einem Dimm-Schritt erstmal für eine Sekunde keine weiteren Befehle mehr angenommen werden. Wenn man innerhalb dieser Zeit wiederholt die Taste drückt, verlängert sich die Pause, bis man irgendwann mal etwas abwartet. Dann kann man einen neuen Befehl absetzen und dann nach einer Sekunde wieder einen....

Für die Nutzung von dimUp/dimDown ist dies leider sehr unpraktisch...

[justme1968]

ich weiß was es ist

keine verzögerung sondern beim dimup/dimdown wird ja lokal der neue wert aus dem alten berechnet. das geht natürlich nur wenn sich der alte auch ändert. also nur wenn er aus der bridge zurück gelesen ist.

ich baue ein das die sekunde verzögerung nur gilt wenn die bridge das kommando direkt ausführt und nicht wenn fhem was emuliert.

dann sollte es für beide fälle passen.

gruss
  andre

[Jaydee]

Ah supi, danke!

[der-Lolo]

Kann es sein das es durch die Änderung Nebeneffekte gibt?
Zur zeit schaut es übel aus in meinem Log

2013.12.09 23:40:19 1: HUEBridge_HTTP_Request http://192.168.178.31/api/0ff0fc5fdca610c715c74f486d75e4f3/lights/1: Select timeout/error:
2013.12.09 23:40:19 1: Perfmon: possible freeze starting at 23:40:16, delay is 3.995
2013.12.09 23:40:51 1: HUEBridge_HTTP_Request http://192.168.178.31/api/0ff0fc5fdca610c715c74f486d75e4f3/lights/7: Select timeout/error:
2013.12.09 23:40:51 1: Perfmon: possible freeze starting at 23:40:48, delay is 3.806
2013.12.09 23:41:23 1: Perfmon: possible freeze starting at 23:41:20, delay is 3.233
2013.12.09 23:41:55 1: Perfmon: possible freeze starting at 23:41:54, delay is 1.614
2013.12.09 23:42:27 1: HUEBridge_HTTP_Request http://192.168.178.31/api/0ff0fc5fdca610c715c74f486d75e4f3/lights/11: Select timeout/error:
2013.12.09 23:42:27 1: Perfmon: possible freeze starting at 23:42:24, delay is 3.895

[justme1968]

das schaut eher wie
ein netzwerkproblem bei dir aus.

an der eigentlichen komunikation habe ich nichts geändert. d.h. die senden der kommandos und dir statusabfrage sind jeweils absolut gleich geblieben. es gibt nur eine sekunde verzögerung dazwischen.

ich mache aber trozdem die verzögerung konfigurierbar.

gruss
  andre

[justme1968]

ich habe eben eine version eingecheckt die:

• ein attribut delayedUpdate hat. wenn es auf 1 gesetzt ist ist die 1 sekunde verzögerung für dieses device aktiv
• ein kommando delayedUpdate das in ein set mit eingebaut werden kann um die verzögerung für dieses eine set zu aktivieren
• ein kommando immediateUpdate um die verzögerung für dieses eine set zu deaktivieren
• bei dimUp und dimDown wird die verzögerung immer deaktiviert

damit sollten alle möglichen anforderungen erst mal abgedeckt sein.

gruss
  andre

[justme1968]

noch ein kurzer hinweis: mit

Code Auswählen Erweitern

define HUEUpdate notify <bridge>:swupdate.* {...}kann man sich per notify über zur verfügung stehende firmware updates informieren lassen.

gruss
  andre

[volschin]

Hallo Andre,
guter Hinweis! Kann mann das notify dann auch gleich mit

Code Auswählen Erweitern

set MyHueBridge swupdate
abschließen oder würdest Du das eher nicht empfehlen?

Gruß,
Veit

[justme1968]

das event wird auch ausgelöst wenn der update durchgeführt wurde. in dem fall ist dasn swupdate kommando nicht mehr gültig und du bekommst ein mal einen fehler im log.

wenn das update aus irgend einem grund schief geht könnte es sein das es durch das notify immer wieder versucht wird zu triggern. aber das sollte nicht weiter schlimm sein.

probier es aus. es sollte nichts schlimmes passieren

gruss
  andre

[volschin]

Das ist meine Lösung, die ich jetzt implementiert habe. Ich nutze Prowl.

Code Auswählen Erweitern

define HUEUpdate notify MyHUEBridge:swupdate.* { if(ReadingsVal("$NAME","updatestate",'1') eq "2") {{ myProwl('HUE is updating', "$NAME $EVENT",0)};; Log 3, "$NAME: Update status $EVENT";; fhem("set $NAME swupdate");;}}


[justme1968]

updatestate ist kein reading sondern ein internal value ist. du muss also InternalVal verwenden.

gruss
  andre

[volschin]

Hallo Marc,
danke, habe ich geändert. Der STATUS der Bridge bleibt auf "updating". Müsste der nicht durch das Modul zurückgesetzt werden, wenn updatestate wieder auf 1 zurück geht.

Gruß,
Veit 

[justme1968]

nach dem update geht updatestete auf 0 und der status geht auf 'update done'.

das update scheint aber diesmal zwei stufig zu sein. es ist nicht nur die firmware für die bridge sondern auch für die bulbs aktualisiert worden. meine bridge hat dazu eine ganze weile gebraucht und scheinbar auch ein zwei malignes triggern des update. leider ist nicht dokumentiert wie es genau passiert.

gruss
  andre

[justme1968]

und noch was: ich würde das prowl notify an den anfang vor das if ziehen. dann bekommst auch eine nachricht nach dem update und wenn was schief geht.

gruss
andre