philips hue modul

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

Vorheriges Thema - Nächstes Thema

justme1968

anbei eine version zum testen die die oben vorgeschlagen änderungen implementiert:

- bri hat jetzt den bereich 0-255
- bri wird 1:1 zum device durchgereicht
- pct 0 bedeutet off, pct 255 bedeutet on

- state ist immer noch fs20 kompatibel, geht aber nur auf off wenn das device wirklich onoff 0 meldet.

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

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

Sukaos

#421
Ich habe das gerade einmal ausprobiert und hatte folgenden Widerspruch:

Hatte eine Hue Bulb ausgeschaltet über fhem mit set $DEVICE off. Der Prozentslider ging aber nicht auf 0, aber das Symbol der Lampe auf aus.
Bei Internals stand State off, der State ist auch richtig off, aber das Reading onoff liefert 1. Etwas später war die Lampe dann an und die Angabe des state mit dimXY% auch angepasst richtig.

Ich habe das dann versucht zu reproduzieren und folgendes erreicht:
Lampe mit Pct-Slider eingeschaltet. Lampe leuchtet korrekt, aber Lampensymbol bleibt bei off. Nachgeguckt unter den Details:
State: off, onoff: 1, level 0%, pct: 54, ...
Also sehr widersprüchlich.


Ergänzung: nach einer Weile ohne Änderungen schaute ich zufällig nochmal rein und der state war korrekt auf dim50%, ging dann aber recht bald wieder auf off. Und ja, die Lampe brennt noch immer. Pct steht weiter auf 54. Eine direkte Abfrage der Bridge liefert mir ganz korrekt
{"state": {"on":true,"bri":138,"hue":16299,"sat":50,"xy":[0.4051,0.3906],"ct":284,"alert":"none","effect":"none","colormode":"ct","reachable":false}, "type": "Extended color light", "name": "Flur 1", "modelid": "LCT001", "swversion": "66009663", "pointsymbol": { "1":"none", "2":"none", "3":"none", "4":"none", "5":"none", "6":"none", "7":"none", "8":"none" }}

Meine Vermutung gerade ist, dass es mit "reachable 0" zusammenhängt. Das hatte ich vorher nicht gesehen. Trotzdem wäre es ja sinnvoll, wenn der State der bridge genommen wird bzw. die Angaben level, pct, onoff und state nicht widersprüchlich wären.

justme1968

der state im fronted wird nicht durch das setzen selber sondern erst durch die rückmeldung der bridge aktualisiert. bei mir passiert das aber im prinzip sofort.

lampen die ein reachable false oder 0 haben bekommen eigentlich ein icon mit Fragezeichen. jedenfalls wenn du die svg icons verwendest. bei diesen lampen ist das was die bridge meldet nicht mehr unbedingt der zustand den die lampe wirklich hat.

die frage ist warum die bridge ein reachable=false meldet. das sollte normalerweise nicht passieren wenn die lampe noch an ist.

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

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

Sukaos

Ob da was falsches steht bei reachable=false oder nicht ist mir gar nicht so wichtig gewesen. Ich war mehr verwundert, dass die bridge on meldet und das Plugin auch onoff: 1 sagt, aber der state mit off zurückgeliefert wird. Also warum das Plugin nicht onoff: 0 und state off sagt oder eben state on passend zu onoff und dem Resultat der bridge.
So passten pct, bri, level, onoff und state einfach nicht zusammen und verwirrten mich.

Warum die bridge reachable=false lieferte obwohl ich die Lampe einwandfrei steuern konnte und die Lampe direkt daneben in der gleichen Deckenlampe erreichbar ist weiß ich nicht. Ist mir auch schleierhaft, vielleicht ist die Lampe nur durch das weiterleiten von der Nachbarlampe erreichbar...

justme1968

ok. ich dachte du hast auf das icon geschaut.

die saubere lösung wäre state auf unrechable zu setzen. ich muss mal schauen ob die icons dann passen wenn nicht die svg icons verwendet werden.

das problem ist: ich kann auf fhem seite nicht unterscheiden ob das reachable richtig oder falsch ist. sobald reachable=false ist sind die werte die die bridge liefert nicht mehr zuverlässig.

level ist bei dir nicht konsistent weil ich das reading komplett rausgeschmissen habe. es war eh immer das gleiche wie pct und war nur da weil es mal einen fhem standartd gab der das vorgeschlagen hat. der standard ist aber hinfällig weil es niemand sonst macht :). du solltest level mit deletereading TYPE=HUEDevice levellöschen.

pct und bri sind übrigens im obigen vorschlag nicht unbedingt konsistent. bri ist immer das was die bridge liefert und pct ist die logische sicht von fhem. d.h. wenn die bridge onoff=0 meldet wird pct=0 sein und state=off auch wenn bri=255 ist.

pct, state und onoff sollte konsistent sein und bri kann device abhängig abweichen. hue bulbs behalten bri beim ausschalten bei und man kann ein on senden und die lampe hat die alte helligkeit, die living whites adapter behalten bri nur eine zeit lang nach dem ausschalten bei und gehen irgendwann auf 0, die living colors lampen verhalten sich wieder etwas anders.

welche firmware hast du auf der bridge? reachable sollte auch beim weiterleiten richtig sein.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Sukaos

Gut level nehme ich raus.
Dann war aber immer noch state anders als onoff und pct! Auf bri, level, etc greife ich eh nicht zurück, hatte das dir nur der Vollständigkeit halber angemerkt.

Ich kann sowohl damit leben dass bei unreachable der State ein anderer ist oder fhem die Lampe als off darstellt oder einfach die Werte weiterverwendet die die bridge liefert. Ich möchte nur wissen was der Fall ist und das konsistent. Oder sowas wie ein attr mit dem ich setzen kann ignoriere reachable.

Als firmware habe ich Firmware-Version: 01012917 und laut der hue app ist das die aktuelle.

Sukaos

Ich habe jetzt erstmal für mich sinnvoller die Zeile $s = 'off' if( !$reachable ); dahingehend geändert, dass ich den State dort auf unknown setze statt auf off. Das erscheint mir für die Anzeige sinnvoller, als das unreachable einfach zu ignorieren.

justme1968

genau so habe ich es inzwischen auch eingebaut.

ich teste noch ein bischen und dann checke ich es so ein.

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

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

Steeßer17

#428
Zitat von: bapou am 16 Januar 2014, 18:49:53
Hallo,

vielleicht eine triviale Frage aber ich hatte hier noch keine Loesung gesehen.

Hat einer von Euch schon FS20 Taster mit den Hue's verbunden, so dass
nur ein Taster zum schalten und dimmen noetig ist? Also kurz druecken = toggle zwischen an und aus; lang druecken = dimmen?

Ich kam nur soweit (SL_Taster_LU ist ein FS20 Schalter; SL_Hue_Drehlicht ein Hue Device = LivingWhites Dimmer Steckdose)

define SL_Hue_Drehlicht_PAIR notify  SL_Taster_LU {
  if (Value("SL_Taster_LU") eq "toggle")  {
    if (Value("SL_Hue_Drehlicht") eq "off")  {
      fhem ("set SL_Hue_Drehlicht dim100%%");
    }
    else {
      fhem ("set SL_Hue_Drehlicht off");
    }
  }
  if (Value("SL_Taster_LU") eq "dimupdown")  {
    fhem ("set SL_Hue_Drehlicht dimDown");
  }
}

Unten gibt es noch zwei Probleme; 1.) hier nur dimDown; 2.) Wenn man lange drueckt wird auch nur ein Schritt heruntergedimmt.

Herzlichen Dank,
Thom


Steeßer17

folgender Code funktioniert, um Philips HUE an und aus zu schalten und hoch und runter zu dimmen

define HUE_Malin notify Licht_Malin1 {\
if ("$EVENT" eq "off") {fhem("set HUEDevice2 off")}\
if ("$EVENT" eq "on") {fhem("set HUEDevice2 on")} \
if ("$EVENT" eq "dimdown") {fhem("set HUEDevice2 dimDown")}\
if ("$EVENT" eq "dimup") {fhem("set HUEDevice2 dimUp")}\
}


bearbeiten kann man den Code natürlich direkt in der fhem.cfg oder wie ich dank http://fhem.de/Heimautomatisierung-mit-fhem.pdf auf Seite 28 (Kapitel "Schalten von Ereignissen abhängig machen-notify") Unterkapitel "Bearbeiten über das Webfrontend"
aber auch über das Menü auf ,,Everything" ! Wer es noch nicht kennt, muss es einfach ausprobieren!

siggi85

#430
Zitat von: HolyMoly am 14 April 2014, 08:56:39
Hallo,

hier meine aktuelle Version des Kaminfeuereffekts, sehr gemütlich  ;)
Gibt es noch Potential die hue Kommunikation effizienter zu gestalten
oder ist immediateUpdate momentan das Maß aller Dinge?

sub
startFireEffect()
{
    my $hue = int((rand()*3460)+5460);
    my $sat = int(rand(64)+170);
    my $bri = int(rand(60)+16);
    my $delay = (rand()+0.1);
    my $transitiontime = int($delay * 10);
    fhem("set Schlafzimmer.NachtkastenLampe hue $hue: sat $sat : bri $bri : transitiontime $transitiontime immediateUpdate");
    InternalTimer(qw(gettimeofday)+$delay, "startFireEffect", "fireEffectTimer", 0);
}

sub
stopFireEffect()
{
   RemoveInternalTimer("fireEffectTimer");
}

Ich habe den Effekt von HolyMoly umgebaut, so dass man mehrere Hue Bulbs angeben kann.

sub
startFireEffect(@)
{
  my @bulbs=@_;
  foreach (@bulbs) {
    my $bulb=$_;
    my $hue = int((rand()*3460)+5460);
    my $sat = int(rand(64)+170);
    my $bri = int(rand(60)+16);
    my $delay = (rand()+0.1);
    my $transitiontime = int($delay * 10);
    fhem("set $bulb hue $hue: sat $sat : bri $bri : transitiontime $transitiontime immediateUpdate:noUpdate");
    InternalTimer(qw(gettimeofday)+$delay, 'FireEffect', $bulb, 0);
  }
}

sub
stopFireEffect(@)
{
  my @bulbs=@_;
  foreach (@bulbs) {
    my $bulb=$_;
    RemoveInternalTimer($bulb);
    fhem("set $bulb off");
  }
}


Der Effekt kann folgendermaßen aufgerufen und gestoppt werden:


{startFireEffect("wz_bulb1","wz_bulb2")}
{stopFireEffect("wz_bulb1","wz_bulb2")}

justme1968

sehr schön. ich habe immer noch vor das mit einer schnittstelle enger und effizienter ans modul anzubinden.

vorsicht: immediateUpdate und delayedUpdate betreffen die kommunikation mit der bridge und wie schnell fhem den status von der bridge abfragt damit der interne state und das icon nachgezogen werden kann.

um so schnell wie möglich zu senden und fhem nicht auszulasten ist es sinnvoll dieses update komplett zu unterdrücken. dazu sollte noUpdate gesetzt werden.

den update parameter musst du mit : an das set anhängen. ich glaube der fehlt bei dir.

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

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

siggi85

#432
Zitat von: justme1968 am 26 September 2014, 17:37:14
vorsicht: immediateUpdate und delayedUpdate betreffen die kommunikation mit der bridge und wie schnell fhem den status von der bridge abfragt damit der interne state und das icon nachgezogen werden kann.

um so schnell wie möglich zu senden und fhem nicht auszulasten ist es sinnvoll dieses update komplett zu unterdrücken. dazu sollte noUpdate gesetzt werden.

den update parameter musst du mit : an das set anhängen. ich glaube der fehlt bei dir.

Danke für den Tipp!

So?
fhem("set:noUpdate $bulb hue $hue: sat $sat : bri $bri : transitiontime $transitiontime immediateUpdate");

EDIT:
Nein, so :P Ich änder das gleich oben im Code.
fhem("set $bulb hue $hue: sat $sat : bri $bri : transitiontime $transitiontime immediateUpdate:noUpdate");

justme1968

so:fhem("set $bulb hue $hue: sat $sat : bri $bri : transitiontime $transitiontime : noUpdate");

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

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

HolyMoly

@siggi85
schöne Erweiterung  ;D
@Andre
Gäbe es eine Möglichkeit {startFireEffect("Wohnzimmer.EckStrahler","Wohnzimmer.StehLampe")} setcmd mit lightScene zu verwenden? Bei mir schmiert er da irgendwie leider immer ab....
FHEM auf Raspi2 & Radxa Rock