philips hue modul

[justme1968]

es gibt einen rückkanal, aber wenn ein schaltbefehl verloren geht wird er nicht erneut gesendet. ich denke das ist weil es dann zu problemen kommen würde wenn ein schalter eine lampe direkt schaltet.


wenn du nur über fhem schaltest:
vergleich mal das desired internal mit dem tatsächlichen zustand. wenn es hier abweichungen gibt kannst du damit periodisch nachhelfen.

[cyablo]

Öhm, ich hab an keiner der Lampen ein desired internal.

[justme1968]

desired internal

[cyablo]

Tut mir leid, bin ich überfragt. Wie kommme ich an den Wert?

[Master_Nick]

Denke mal das ist was er meint.


Aus interesse was besagt dieser Wert in welche Ausprägung ?

[cyablo]

Ja, das ist mir schon klar, aber wie gesagt, hab ich nicht:

[justme1968]

1 bedeutet sollte ein, 0 bedeutet sollte aus sein.

welche fhem und modul version hast du?

[cyablo]

30_HUEBridge.pm:0.198540/2019-07-19
31_HUEDevice.pm:0.201220/2019-09-07
fhem.pl:20069/2019-08-27

[Fredi69]

Seit ein paar Tagen gehen sämtliche Hue Lampen in einem Raum manchmal völlig selbständig an.
Ich kann mir das nicht erklären und habe auch keinen Ansatzpunkt, hatte jemand sowas schon mal?

[Jamo]

Ich habe sowas auch schon mal beobachtet, bei mir gehen die Lampen auch schon mal an, habe gedacht es liegt vielleicht an den Bewegungsmeldern. Aber gerade sind ALLE Lampen angegangen, obwohl ich nicht zu Hause bin. Und dass alle Bewegungsmelder gleichzeitig fälschlicherweise eine Bewegung melden, wäre komisch.

Ich habe allerdings auch eine 'at' Routine laufen, die alle 10 Minuten checked, ob noch Lampen an sind, und wenn ja, die dann alle wieder aus schaltet.... Ist also nicht ganz so schlimm.

[justme1968]

wenn lampen unerwartet angehen können es auch spannungsschwankungen oder kurze stromausfälle sein.

bei neuen lampen und aktueller firmware kann man das statt verhalten konfigurieren. bei alten lampen hilft diebinnen angesprochene überwachung in fhem.

[Markus M.]

Das Modul verträgt sich seit Kurzem scheinbar nicht mehr ganz mit meinen BlockingCall Aufrufen.
Vermutlich ist $name in AttrVal($name, "subType", "extcolordimmer") nicht immer definiert?!
Aufgerufen wurde konkret der Befehl set huebridge modifyscene ... mit gültigen Daten.

Code Auswählen Erweitern

2019.10.01 00:00:00 1: PERL WARNING: Use of uninitialized value $d in hash element at /opt/fhem/fhem.pl line 4523.
2019.10.01 00:00:00 1: eval: {
BlockingCall("setnightlightscenes","updatenighthue");
fhem "define hue_trigger at +00:00:30 BlockingCall(\"triggersceneupdate\",\"updatenighthue\")";
}
2019.10.01 00:00:00 1: stacktrace:
2019.10.01 00:00:00 1:     main::__ANON__                      called by /opt/fhem/fhem.pl (4523)
2019.10.01 00:00:00 1:     main::AttrVal                       called by /opt/fhem/FHEM/31_HUEDevice.pm (435)
2019.10.01 00:00:00 1:     main::HUEDevice_SetParam            called by /opt/fhem/FHEM/30_HUEBridge.pm (693)
...

Hat sich irgendwas geändert?

Gruß, Markus

[justme1968]

ja. es gab eine änderung: für rollos wird up und down statt on und off akzeptiert. dafür wird der subtype geprüft. im modifyscene context wird die set routine aber ohne device bzw. namen aufgerufen.

sollte mit dem update morgen repariert sein.

[Markus M.]

sollte mit dem update morgen repariert sein.

Nicht ganz, die aktuelle SVN Version läuft gar nicht.
Besser das mal lieber noch aus ehe es morgen ins Update geht
Du darfst eine Variable nicht innerhalb eines If definieren, wenn sie danach verwendet wird.
Sollte ab Zeile 435 also ca. so aussehen:

  my $subtype = "extcolordimmer";
  if( $name ) {
    $subtype = AttrVal($name, "subType", "extcolordimmer");



Und in deiner aktuellen Zeile 1080 kannst du noch das Fallback zu ner 0 statt einem leeren String ändern:

      my $Y = ReadingsVal($name,"bri",0) / 254.0;

Grüße, Markus

[justme1968]

danke.

ich habe keine ahnung warum manche fehler bei manchen perl versionen durch ein reload nicht gefunden werden. sehr komisch.