philips hue modul

Begonnen von justme1968, 11 Februar 2013, 13:55:14

Vorheriges Thema - Nächstes Thema

Loredo

Zitat von: justme1968 am 08 September 2014, 13:00:35
ist es wirklich richtig? die lampe ist ja im prinzip noch an. und dim0% würde ich eher als aus sehen.

also:
dim00% ?
dim01% ?
dim06% ?


Würden wir ja alle, aber Philips offenbar ja nicht. Ich bin nicht sicher, ob es wirklich Sinn macht deren Logik dann komplett umzurechnen. Rechnest du denn -1 bis 255 auf die 100% oder 0 bis 255? Konsequenterweise müsstest du intern bis -1 zählen. Der BRI Wert sollte aber weiterhin dem HUE System entsprechen, sprich man kann über BRI die Leuchte nicht ausschalten, sondern sie leuchtet zwischen 0 und 255 wie von Philips vorgesehen. Bei diesem Unterschied zum FS20 Systeme sehe ich den Knackpunkt. Ich denke es macht Sinn, dass man sich eher nahe am System des Herstellers hält, anstatt sich einem anderen Hersteller anzunähern. Das ist logischer, wenn man sich spezifisch mit HUE beschäftigt finde ich.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

eben weil man es nicht so machen muss ist ja dim0 genau nicht gut.

ich würde bri 0 eigentlich lieber auf dim06 wenn es fa20 kompatibel sein soll mappen oder auf dim1 wenn es nicht kompatibel sein muss.

dim0
ist eigentlich die schlechteste variante.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

Zitat von: justme1968 am 08 September 2014, 13:19:19
eben weil man es nicht so machen muss ist ja dim0 genau nicht gut.

ich würde bri 0 eigentlich lieber auf dim06 wenn es fa20 kompatibel sein soll mappen oder auf dim1 wenn es nicht kompatibel sein muss.

dim0
ist eigentlich die schlechteste variante.


Dir gehts nur um die Grafik, oder?
Wenn ich so drüber nachdenke: Da sollte es natürlich schon eine sein, die auch tatsächlich zeigt, dass was brennt.  :D


Die Frage, die sich zusätzlich stellt: Möchte man pct und level nicht auch so haben, dass in deren Fall 0 auch wirklich "aus" ist, damit beim Schalten über eine Gruppe auch wirklich alle ausschalten, wenn man statt "off" lieber "pct 0" sendet (aus diversen Gründen)? Wer bri=0 als geringste Helligkeit haben möchte, der müsste dann wohl eben bri statt pct verwenden. Erst dann gäbe es ein wirklich einheitliches Verhalten zu den FS20.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

ich verwende die farbigen SVG icons da gibt es das problem nicht. und meine lampen sind eh nie so dunkel.

aber es sollte schon konsistent sei.  es gibt übrigens noch die feinheit das die living whites stecker sich hier anders verhalten.

die endgültige version hat also noch ein paar randbedingungen mehr.

ich denke noch mal in ruhe darüber er nach. aber pct und bri zu trennen ist eine gute idee bri währe hue bzw. device spezifisch und pct währe fhem spezifisch und device unabhängig.

mal sehen ob das halbwegs rückwärts kompatibel geht.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

wie wäre es mit diesem vorschlag:
onoff   bri   pct   state
0        X     0    off
1        0     1    dim06%
1        1     1    dim06%
             .         
             .         
1      128    50    dim50%
             .         
             .         
1      254   100    on


setzen von bri wird 1:1 weiter gereicht, setzen von pct auf 0 schaltet wirklich aus.

state würde ich konfigurierbar machen (vielleicht sogar direkt abhängig von color-icons). entweder die fs20 werte oder off, 1-99 und on wie bei homematic.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Sukaos

Das klingt sinnvoll.  :)
Und solange off nur erscheint, wenn sie wirklich aus ist bin ich sowieso zufrieden.
Pass auf die fehlende Rundung bei pct und level auf in der Version, die du mir gestern beigefügt hattest.

Loredo

#411

Zitat von: justme1968 am 08 September 2014, 16:05:05
wie wäre es mit diesem vorschlag:
onoff   bri   pct   state
0        X     0    off
1        0     1    dim06%
1        1     1    dim06%
             .         
             .         
1      128    50    dim50%
             .         
             .         
1      254   100    on



setzen von bri wird 1:1 weiter gereicht, setzen von pct auf 0 schaltet wirklich aus.


Ich überlege gerade noch, ob ich X als Wert bei BRI so toll finde. Besser fände ich es im nummerischen Bereich zu bleiben (wg. Verwendung in Programmen zB). Den sichtbaren Nummernbereich würde ich deshalb vielleicht eher auf 0-255 definieren und intern auf 0-254 für "on" umrechnen und den sichtbaren BRI bei 0 eben intern als Sonderlocke behandeln.


Sähe dann so aus:




onoff   bri   pct   state
0        0     0    off
1        1     1    dim06%
1        2     2    dim06%
             .         
             .         
1      128    50    dim50%
             .         
             .         
1      255   100    on
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

lach

X sollte heissen egal was da steht :) wenn onoff auf 0 steht geht pct auf jeden fall auf 0 und state auf off.

und wegen den bereichen: ich würde gerne bri 1:1 durchreichen und nur pct unabhängig machen. aber die neue api dokumentation hat inzwischen einen bereich von 0-255 für bri. d.h. die 254 sind auch hinfällig.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

Zitat von: justme1968 am 08 September 2014, 17:13:20
aber die neue api dokumentation hat inzwischen einen bereich von 0-255 für bri. d.h. die 254 sind auch hinfällig.

DAS hatten wir aber schon an anderer Stelle mal festgestellt, André :P
Mir war so, als hättest du das schonmal abgeändert gehabt (oder warst zumindest fest entschlossen  ;D )

Zitat von: justme1968 am 08 September 2014, 17:13:20und wegen den bereichen: ich würde gerne bri 1:1 durchreichen und nur pct unabhängig machen.


Ja verstehe ich, mein Denkfehler. Die konsistente Steuerung erfolgt ja dann mit pct ;-)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

Zitat von: Loredo am 08 September 2014, 17:19:40
DAS hatten wir aber schon an anderer Stelle mal festgestellt, André :P
Mir war so, als hättest du das schonmal abgeändert gehabt (oder warst zumindest fest entschlossen  ;D )

ich hatte sogar schon damit angefangen :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo


Zitat von: justme1968 am 08 September 2014, 17:21:20
ich hatte sogar schon damit angefangen :)


Gut der Mann *thumbsUp*



Und achso: Ich plädiere für den HM ähnlichen State, da granulärer. Wer will schon an FS20 erinnert werden, pfff  8)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Strippenzieher

#416
So, jetzt mal aus der MSR-Ecke ... Hatte das praktischerweise heute erst beruflich als Problemsituation.

Also im technischen Sinn ist Dim0, bri0, etc. beim (M)essen/(S)teuern/R)egeln nicht = Off und wird auch nicht als Off definiert. In einer Visualisierung kommt es deshalb auch meistens zu Komplikationen - Faktor Mensch eben ...

Hatte das heute im Zusammenhang einer Dali-Steuerung, da wurden Leuchten in der Fernüberwachung noch als Aktiv angezeigt obwohl sie runter gedimmt waren auf 0, also optisch gesehen Aus ...

yves

Hab jetzt mal mit diesem dim-Befehl rumgespielt und folgende Frage:

Sollte wenn ich folgendes ins Befehlfenster eingebe

set bridge_HUEDevice7 dim80% 1000

die entsprechende Birne nicht gaaaanz langsam hochdimmen? Sie dimmt sich hoch, aber ganz flott, ob die 1000 dahinter steht oder nicht macht keinen Unterschied. Im FHEM-Wiki beim WakeUp-Light steht ja auch sowas:

{fhem("set Lamp1 dim100% 1280") }

Wird dieser Zusatzparameter für die Dauer des Dim-Vorgangs bei hue nicht unterstützt?

justme1968

@Strippenzieher: eben damit diese komplikationen z.b. bei bri=0 lampe ist aber nicht aus vermieden werden die trennung in das was tatsächlich ans device durchgereicht wird. der bei parameter der dann auch device abhängig ist und dem 'nur' in fhem vorhanden pct parameter. und dieser wird so definiert das pct = 0 aus ist, pct = 100 ist an und alles dazwischen ist gedimmt. das ist glaube ich einem anwender deutlich einfach zu erklären als deine technische definition. homematic kompatibel ist es auch noch und das verhalten lädt sich device unabhängig verwenden.

das ein dimmer aus technischen gründen eventuell nicht bis komplett 0 dimmen kann ist eine sache, im interface aber diese hardware abhängigkeit zu haben lässt sich schwer vermitteln. ich glaube es gibt keinen wirklichen grund bei pct = 0 nicht wirklich abzuschalten.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

@yves: der zeit parameter war im dim...% befehl niemals vorgesehen (hab es jetzt aber nachgezogen). und der dim..% befehl ist auch eigentlich nicht dokumentiert.

am besten ist es alles explizit hin zu schreiben: set bridge_HUEDevice7 pct 80 : transitiontime 1000

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968