all4hue Community

Moin,

so es ist soweit ich habe die Grenze der Regeln erreicht und auch schon alles optimiert was geht. Jetzt wollte ich gern Farbschleifen machen bei denen man die Übergangszeit einfach ändern kann und auch welche intensität die Farben haben sollen. Dabei hilft die HUELabs Collerloop geschichte, nur das de eben mehr Regeln benötigen als nötig. Daher wollte ich das was die Regeln machen adaptieren, bin nach langer Fehlersuche aber darauf gestoßen das ich das gar nicht vollständig mit all4Hue machen kann.

Problem ist, das die originalen Regeln von Hue eine Start-Aktion benutzen die ich mit all4Hue nicht anpassen kann. Anpassen schon aber dann geht aber das was die Farbschleife erzeugt verloren. Und zwar rufen sie in einer Schleife immer wieder die selbe Regel auf die nichts anderes macht als das entsprechende Zimmer Einzuschalten.
Mit einer anderen App habe ich mir mal angeschaut was genau in diesem Befehl steht, siehe da hier werden 2 weitere Werte übergeben die ich in all4Hue nicht sehen oder anpassen kann.

Und zwar übermitteln sie hier
1. den Zustand "ein"
2. die übergangszeit in Sekunden
3. die Sättigung 0..245
4. ein increment des Farbwertes "hue_inc = 4369"

Wenn ich die Regel anpassen oder Kopieren möchte gehen mir aber Wert 3 und 4 verloren. Das ist aber das effizienteste was ich machen kann, da ich genau genommen Pro Raum nur eine Regel benötige.

Daher meine Frag an unseren guten Rene, ist es möglich das man im Schaltbefehl "Schalten" mehr anpassungen wie:
-sat (Sättigung)
-bri (Hälligkeit)
-hue (Farbwert)
-Weißton (ct)
und eben noch die entsprechenden increments:
-inc_bri (increment Hälligkeit)
-inc_sat (increment Sättigung)
-inc_hue (increment Farbwert)
-inc_ct (increment ct)

vornehmen könnte? Ich habe hier mal alle aufgezählt, jetzt müsste man schauen welche im detail Sinn machen. Grundlegend denke ich das bri, sat und hue schon Sinnvoll sind da man mit nur einer Regel voll dynamische Farbverläufe kreieren kann.

Würde mich über positive Rückmeldung freuen

Grüße Sebastian

So ich habe mal ein bischen rum probiert. Es ist so das scheinbarnur der hue (Farbwert) und der ct (Weißwert) über "Null" springen können, so dass ein increment als loop unendlich weitergeführt werden kann. Helligkeit und Sättigung könnten dennoch Sinn machen, da man somit einen Sonnenaufgang und Sonnenuntergang kreieren kann und das auch nur mit 1-2 Regeln. Würde auch zu Einsparungen in den Regen führen.

Würde mich über Rückmeldung freuen

Hallo,

all4hue ist so konzipiert, dass pro Aktion nur eine tatsächliche Aktion möglich ist, also entweder einschalten oder Farbe ändern, etc. Leider lässt sich das nicht so einfach ändern, da sonst die gesamte SW-Architektur angepasst werden müsste.

Wäre es denn möglich in deinem Fall mehrere Aktionen in eine Regel aufzunehmen? Damit lassen sich dann gleichzeitig mehrere Operationen durchführen..

VG
Rene

Hallo Rene,

danke für deine Antwort. Also ich habe das gerade mal für die Sonnenauf- und Untergangsthematik probiert, das würde auch mit einer Regel mit 2 Aktionen funktionieren (bei manchen Änderungen versteht eine Leuchte ja nicht 2 getrennte Wertänderung in einer Regel, von daher dachte ich das es auch hier so ist). Aber scheinbar klappt das. Das einzige "Problem" ist die Aktion Lichttemperatur änder in Kelvin, hier scheint ein Fehler drin zu stecken. Da man über den Wert den man dort eintragen kann nicht die Lichtfarbe in Kelvin ändert, sondern direkt den ct-Wert. Dieser ist geht jedoch lediglich von 0-255, daher ist das hier irritierend und man muss deutlich kleine werte zur Änderung angeben. Vielleicht verstehe ich das auch einfach nur falsch .

Zum Thema des Farbwechsels, hier habe ich die in den Aktionen verfügbare Farbänderung probiert, diese greift jedoch auch die x,y Steuerung des Farbwertes zu. Dieser kann leider nicht unbegrenzt durch laufen, sondern endet. Es würde auch mit einer Regel klappen ohne die Einschaltaktion nutzen zu müssen, dazu müsste man aber die Farbe nicht über die x,y Variante anpassen, sonder über die inc_hue, diese ist auch für Aktionen mit Gruppen verfügbar. Der Vorteil ist das dieser Wert als Schleife laufen kann.

Wäre es denn möglich den inc_hue bei den Aktionen mit aufzunehmen?
Hier könnte man auch die Sättigung also inc_sat und sat mit aufnehmen wenn das möglich ist, dann sollte eigentlich alles abgedeckt sein

Grüße Sebastian

Muss mich korrigieren, der ct Wert läuft in dem Bereich von 153-500, dennoch ist es keine Kelvin Angabe.

Hallo zusammen,

hue_inc würde ich (wie schon mehrfach angemerkt) als sinnvolle Ergänzung für auf der Bridge laufende Farbschleifen sehen, bei Verwendung von kleinen increments. Negativ ist auch möglich. Zu hohe Werte können aber leider zu einer "Abkürzung" über Weißwerte führen...

Der von der Bridge intern verwendete Wert für die Farbtemperatur ist in "mired" angegeben. Errechnet sich aus 1 Mio geteilt durch den Kelvin Wert.

Viele Grüße
Marcus

Hallo Marcus,

danke für deine Antwort.
Habe mir deinen Post dazu angeschaut, du hast das Thema tatsächlich schon vor fast einem Jahr angemerkt, da komme ich ja spät mit meinem Wunsch . Genau wie von dir angesprochen mache ich es, ich habe mich da an den von den HUE Labs vorgeschlagenen Wert von 4369 mit 5 Sekunden Übergangszeit und 5 Sekunden Timer als Trigger. Das macht das ganze sehr schlank und auch super simpel bei Anpassungen. Daher auch von meiner Seite die Bitte an unseren Rene das hue_inc zu implementieren.

An Mired habe ich ja mal gar nicht gedacht . Danke, jetzt verstehe ich auch wie ich auf bestimmte Farbtemperaturen umrechnen kann. Dennoch bleibt es dabei, das die App beschreibt das wir einen Kelvinwert angeben sollen, dann würde ich davon ausgehen das das ganze dann im Hintergrund der App in Mired umgerechnet wird und somit der Bridge der richtige Wert zur Verfügung steht. Das scheint aber nicht zu passieren. Daher der Hinweis die Beschreibung anzupassen und eventuell auch das mit dem Mired aufzunehmen oder eben es über die App umrechnen zu lassen.

Grüße

Sebastian

Hi Sebastian,

hinsichtlich der nicht ganz passenden Beschreibung hast du natürlich recht. Glücklicherweise können Computer ansonsten gut rechnen, so dass wir uns am Ende zumindest nicht selbst den Kopf zerbrechen müssten: ct_inc mit positiven mired Werten senkt ja die Farbtemperatur (in Kelvin) und umgekehrt. Hirnverdrehen vom feinsten ;-)

Ich sehe aber, dass du auch Spaß an der Materie hast, und wünsche entsprechend viel Spaß beim weiter basteln. Mir fehlt aktuell leider etwas die Zeit dafür, meine Hue läuft aber zum Glück ganz gut wie sie ist - dank Bewegungsmeldern, Dimmer Schaltern und Speichersensoren, vieles bereits nahe am Limit ;-)

Viele Grüße an die Community
Marcus