ab morgen gibt es für die hue module eine verbesserte unterstützung der bridge basierten gruppen. mit diesen gruppen lassen sich mehrere hue devices auf ein mal steuern ohne das fhem für jedes device die parameter parsen und einzeln an die bridge übertragen muss. ich vermute das auch der funk weg von bridge zu den devices effizienter genutzt wird.
was ist neu:
- neues kommando set <bridge> creategroup <name> <lampe-1> [<lampe-2>..<lampe-n>]
hiermit wird auf der bridge eine neue gruppe <name> angelegt der die lampen <lampe-1> bis <lampe-n> zugeordnet sind.
wenn autocreate aktiv ist wird ein in fhem ein zugehöriges device angelegt.
- neues kommando set <bridge> deletegroup <group>
hiermit wird die benannte gruppe auf der bridge und das zugehörige fhem device gelöscht.
- neues commando set <group> lights <light-1> [<light-2>..<light-n>]
hiermit wir die liste der zur gruppe gehörenden lampen geändert.
- neues kommando set <hue-device> rename <neuer name>
ändert den zur gruppe oder lampe gehörenden namen in der bridge und passt den alias des fhem device an.
- die kommandos get <bridge> devices und get <bridge> groups haben erweiterte ausgaben bekommen.
die lampen im createcroup und lights kommando können entweder als fhem device name oder bridge device id angegeben werden und müssen jeweils durch lehrrzeichen getrennt werden.
wenn autosave in autocreate nicht deaktiviert ist wird nach createcroup, lights und rename automatisch über save gespeichert.
sontige änderungen:
- es gibt ein neues attribut pollDevices für die bridge
1 -> die bridge pollt auf einen schlag alle devices.
es ist damit nicht mehr nötig das die devices alle selber einzeln pollen.
wenn bei definieren eines HUEDevice dieses attribut im zugehörigen IODev gesetzt ist wird das default intervall im device automatisch auf 0 gesetz. d.h. nicht mehr gepollt. wer selber ein intervall im define angegeben hat sollte dies entfernen.
das intervall in der bridge sollte ensprechend kleiner als die 300 sekunden default gesetzt werden.
- es gibt für die bridge das neue attribut httpUtils
nicht gesetzt -> alles wie bisher, d.h die bridge wird für jede anfrage blockierend gepollt.
0 -> es wird HttpUtils_BlockingGet verwendet statt der eigenbau lösung. immer noch blockierend!
1 -> es wird (für fast alles) HttpUtils_NonblockingGet verwendet.
mit verbose 4 für die bridge sieht man im logfile womit abgefragt wird
ansonsten gab es vor kurzem noch änderungen zu presets für die farbtemperatur und erste/bessere unterstützung für osram lightify lampen.
mehr dazu gab es hier: http://forum.fhem.de/index.php/topic,11020.msg233471.html#msg233471 (http://forum.fhem.de/index.php/topic,11020.msg233471.html#msg233471) und hier: http://forum.fhem.de/index.php/topic,11020.msg233648.html#msg233648 (http://forum.fhem.de/index.php/topic,11020.msg233648.html#msg233648).
gruss
andre
ps: ich bin gerade am überlegen wo und wie ich am besten über updates informiere. jeweils mit einem neuen thread hier im bereich Beleuchtung oder besser in Ankündigungen ?
edit:
wichtig: die syntax um mehrere lampen anzugeben hat sich inzwischen geändert: die einzelnen lampen sind mit komma getrennt (und ohne leerzeichen) aufzuzahlen. mehr hier: http://forum.fhem.de/index.php/topic,42003.msg342251.html#msg342251 (http://forum.fhem.de/index.php/topic,42003.msg342251.html#msg342251).
Hallo André,
Wo besteht der Unterschied zu LightScene?
Wenn ich es richtig verstehe kann ich bei LightScene verschiedene Farben für die Lampen definieren und bei
creategroup nur eine Farbe?
gruppen sind für devices die alle gleich gesteuert werden sollen. also eher vergleichbar mit structure.
der vorteil ist das die jeweiligen kommandos nur ein mal von fhem an die bridge gesendet werden und nicht für jedes device einzeln.
gruss
andre
Hallo Andre,
Danke für das Update - ich habe es heute installiert und es ist schon eine super Verbesserung. Danke für diese schnelle Umsetzung meiner Anregungen bezüglich Lightify und Tunable white.
Folgendes hakt bei mir noch:
- Die Buttons zu dem webcmds "color 6500:color 3000" sind jetzt da - allerdings bei mir transparent/mit der Hintergrundfarbe gefüllt.
- Für einen Lightify GU10 TW habe ich folgendes: "webCmd color:color 6500:color 2700:toggle:pct 100:pct 40:pct 0" - "color" zeigt dabei jetzt nicht mehr einen slider von 2000-6500 an, sondern den RGB-Colorpicker. - Ich habe testweise rechts den Helligkeitsdimmer des pickers benutzt und in zwei von zwei Fällen ist fhem komplett angestürzt (ich weiß, du hast von der Verwendung abgeraten).
- ebenso spinnt bei mir der "ct" slider - er scheint sich nicht sicher zu sein, ob er ein "pct" oder ein "ct" slider ist. - wenn man Ihn zieht benimmt er sich wie ein pct-slider (0-100) - springt aber, wenn man mit color 3000 bzw color 6500 die Farbtemperatur ändert (auf Werte 153 bzw 370 - außerhalb seines Feldes).
Soviel ist mir erstmal aufgefallen - Danke nochmal.
Bisher hatte ich ja eine HueDevice-Version von Mitte Oktober - dabei ist mir aufgefallen, dass in den webcmd-presets für Hue RGB und Lightify unterschiedliche Grüntöne als Standard eingerichtet wurden: HUE hatte "rgb DEFF27" und die Lightify hatte (nach setzen von colordimmer) "rgb 98FF23" gibt/gab es dafür einen Grund? (jetzt sind es ja beides extcolordimmer)
Gruß
Axel
wie hast du denn das update gemacht? hast du Color.pm auch aktualisiert und neu geladen? deine symptome würden alle zu einer alten version passen.
der grün preset war schon immer auf hue bulbs und living colors zugeschnitten. das sind etwa die beiden maximal grün die möglich sind. da ich vorher die unterscheidung nicht am subtype fest machen konnte waren die bulbs an der modelid festgemacht. das ist aber falsch da auch für andere hue modelid gilt.
wenn du für die lightify bessere default presets hast poste sie einfach.
gruss
andre
Hallo,
habe seit dem update
PhilipsHue: empty answer received
Hat das was mit dem automatisch erstellten HUEGroup0 zu tun?
Gruß Otto
nein.
deine bridge hat aus irgend einem grund mit einer leeren antwort geantwortet. wenn das nicht gehäuft passiert kannst du es ignorieren.
gruß
andre
edit: ich hatte noch einen fall übersehen bei dem diese meldung fälschlicher weise ausgegeben wurde. das habe ich eben repariert.
@axterix: deine probleme können auch passieren wenn deine fhemweb version nicht aktuell genug ist. das matchen des jeweiligen widgets in 01_FHEMWEB.pm muss so aussehen:if(int(@c) && $allSets && $allSets =~ m/\b$c[0]:([^ ]*)/) {bei älteren versionen fehlt hier das \b in der regex. dann wird statt ct pct gefunden.
gruss
nadre
Hi André,
danke dir für das Update - ENDLICH zentrales Polling und so :D
Ich glaube für Group0 fehlen noch ein paar Ausnahmefälle.
Wenn ich Group0 über "set HUEGroup0 delete" lösche, dann gibts folgende Meldung:
2014.12.24 10:59:37 3: resource, /groups/0, not available
Ich denke hier sollte dann in dem Fall nur das FHEM Device gelöscht werden und der Befehl nicht an die Bridge geschickt werden, da man die Gruppe ja eh nicht verändern kann.
Außerdem wenn man versucht die HUE interne Bezeichnung der Group0 mit "set HUEGroup0 rename SoSollEsInDerHueAppHeissen" umzubenennen:
2014.12.24 11:02:29 3: parameter, /groups/0/name, is not modifiable
Hiernach ist mein FHEM abgestürzt.
Man sollte Group0 also einfach gar nicht erst umbenennen können :-)
Gruß
Julian
ein set HUEGroup0 delete kommando gibt es nicht und es sollte dann eigentlich die 'Unkown argument delete, choose one of...' meldung kommen. tut es bei mir auch. das korrekte kommando wäreset <bridge> deletegroup <group>hier fange ich jetzt die gruppe 0 ab und mache garnichts. das fhem device würde beim nächsten autocreate ja wieder erscheinen.
das rename der gruppe 0 fange ich jetzt auch ab, den absturz kann ich aber nicht nicht reproduzieren. wenn die fehlermeldung ausgegeben wird passiert danach nichts mehr.
kannst du den absturz reproduzieren?
gruss
andre
Super update. Danke. :-)
Was anderes: Hat jemand eine Idee. wie man einzelne Devices in der Bridge löschen kann? Über die original-Apps und andere Drittanwendungen finde ich keine Lösung.
Grüsse,
Fritzi
Zitat von: justme1968 am 24 Dezember 2014, 11:28:54
das korrekte kommando wäreset <bridge> deletegroup <group>
Von mir aus auch so, war einfach nur dahin gekritzelt ;)Zitat von: justme1968 am 24 Dezember 2014, 11:28:54
das fhem device würde beim nächsten autocreate ja wieder erscheinen.
Ja, sofern autocreate aktiviert wäre, wenn ich deine Doku richtig gelesen habe.Zitat von: justme1968 am 24 Dezember 2014, 11:28:54
das rename der gruppe 0 fange ich jetzt auch ab, den absturz kann ich aber nicht nicht reproduzieren. wenn die fehlermeldung ausgegeben wird passiert danach nichts mehr.
kannst du den absturz reproduzieren?
Hm, ich glaube ich habe zuerst HUEDevice0 gelöscht und dann wollte ich es in der Bridge über das Modul umbenennen.
@Fritzi: zur zeit scheint das nicht zu gehen. im api gibt es auch kein delete für lampen.
ein reset und alles anlernen scheint zur zeit die einzige möglichkeit zu sein.
gruss
andre
Zitat von: justme1968 am 24 Dezember 2014, 11:50:12
@Fritzi: zur zeit scheint das nicht zu gehen. im api gibt es auch kein delete für lampen.
ein reset und alles anlernen scheint zur zeit die einzige möglichkeit zu sein.
gruss
andre
Ja, das ist auch mein Kenntnisstand. Ist natürlich ein ziemlich gruseliger Weg (bei 13 Lampen)...
Trotzdem Frohe Weihnachten! :-)
Zitat von: justme1968 am 24 Dezember 2014, 09:41:35deine bridge hat aus irgend einem grund mit einer leeren antwort geantwortet. wenn das nicht gehäuft passiert kannst du es ignorieren.
Habe auch das Problem Exakt alle fünf Minuten wird ein Log-Eintrag "...empty answer received." angelegt.
Meine Bridge-Firmware ist auf dem aktuellsten Stand 1.5
ist morgen behoben.
gruss
andre