[patch] 10_FBDECT: Unterstützung von LED HAN-FUN Lampen und FritZ!DECT 500

[amenomade]

Hallo Rudi

Da der TE keine weitere (insb. negative) Rückmeldung schreibt, und es bei mir mit einer Telekom Magenta E27 LED Lampe seit 2 Wochen zuverlässig funktioniert, anbei das Patch aus dem Thread https://forum.fhem.de/index.php/topic,111667.msg1064374.html#msg1064374


Mit der bitte um Kontrolle und ggf. Einchecken.
Vielen Dank im Voraus.
VG

[rudolfkoenig]

Habs ueberflogen, und mir faellt auf, dass beim set etliche Readings gesetzt/Events generiert werden, das ist aber nicht im Sinne des Erfinders Warum ist das in set noetig?
Und wofuer wird "use Color" benoetigt?

[amenomade]

Vielen Dank für die Rückmeldung!

Laut Doku im wiki ist Color nötig, damit das Widget colorpicker in

Code Auswählen Erweitern

    $cmd{"colortemperature"} = "colorpicker,CT,2700,100,6500";
    $cmd{"hue"} = "colorpicker,HUE,0,1,359";
benutzt werden kann.

Das Setzen von Readings ist mMn bei set nötig, weil die 3 Parameter saturation, hue und colormode immer im Zusammenhang arbeiten: eine Änderung von hue führt z.B. auch zu eine Änderung von saturation, weil die Fritzbox nur bestimmte Kombinationen von beiden akzeptiert.
Wenn ich die Readings nicht setze, kriege ich erst nach polling Interval die Änderung. Wenn inzwischen ein neues set gemacht wird überschreiben sich die Sachen.

Deine Meinung, oder Ideen wie man es anders machen könnte?

[amenomade]

Veilleicht könnte ich FBAHAHTTP_Poll($hash->{IODev}) aufrufen, um sofort eine Aktualisierung der betroffenen Readings zu bekommen? Wäre das besser?

EDIT: OK, ich habe vielleicht eine andere Idee. Ich muss aber implementieren, und testen.
Und ich habe auch beim Überlegen einen Fehler in das ParseHttp von meinen Readings entdeckt.

Ich melde mich

[amenomade]

So jetzt:
- tatsächlich scheint colorpicker ohne "use Color;" zu funktionieren => habe ich entfernt.
- mein Problem mit Abhängigkeiten habe ich über $hash->{helper} gelöst. Damit wird kein Reading mehr in "set" gesetzt, sondern erst in parseHttp beim nächsten FBAHAHTTP_Poll. Hoffe, das ist jetzt so mehr "im Sinne des Erfinders"

[rudolfkoenig]

Habe dein Patch uebernommen und eingecheckt.

Da ich es Maintainen muss, habe ich es relativ stark ueberarbeitet:
- Einrueckung/Zeilenlaenge angepasst.
- {helper} entfernt, ich wuesste nicht, welchen Nutzen sie hat
- temperature in colortemperature geaendert, um Missverstaendnisse zu vermeiden.
- da mein Hirn mit // nicht zurechtkommt, es umgebaut.
- %colordefaults verkuerzt.

Ich hoffe dabei nichts kaputtgemacht zu haben, da ich es aber nicht testen kann, bitte ich Dich die Aenderungen zu pruefen, und Feedback zu geben.

[amenomade]

Kein Thema, der Maintainer herrscht auf seinem Modul Danke auf jeden Fall für deine Mühe

Ich teste weiter heute Abend, aber in erster Linie scheint das Setzen von saturation umgekehrt zu funktionieren. satindex dagegen ok, aber die funktionieren nw. in gegenseitige Richtung: je höher satindex, desto kleiner die Sättigung. Das finde ich auch komisch, aber so ist es in der AHA Doku beschrieben. Fakt ist aber im Moment mit der jetzige Implementierung, dass wenn man set saturation höher macht, die Sättigung an der Lampe reduziert wird.

Der Rest sonst perfekt.
Ich analysiere das heute Abend und sage Dir Bescheid.

[amenomade]

Es reicht wahrscheinlich in FBDECT_getDiscreteSat ein

Code Auswählen Erweitern

  @discreteSat = sort { $a <=> $b } @discreteSat;

direkt nach

Code Auswählen Erweitern

  my @discreteSat = (@{$colordefaults{$color}{sat}}, 9999);

weil Du sonst in @discreteSat für z.B. red folgendes kriegst:

Code Auswählen Erweitern

$VAR1 = 180;
$VAR2 = 112;
$VAR3 = 54;
$VAR4 = 9999;was natürlich die Intervalsuche vom kleinsten zum grössten verzerrt
aber, wie gesagt, ich gucke heute Abend genauer an und teste ggf mit dieser Änderung.

[rudolfkoenig]

Danke fuer die Suche, ich habe reverse dazugepackt.

[amenomade]

Jepp, mit reverse scheint alles wieder wie gedacht zu funktionieren.

Frage: hast Du Interesse an einen neuen Patch von mir für die restliche neue Kommandos / Readings, die neulich in der Doku von AVM aufgetaucht sind, oder machst Du es lieber selbst? Das sollte einfacher als diese bl... Farbe / Sättigung Kombinationen von den Lichter sein.

Das wurde z.B. hier https://forum.fhem.de/index.php/topic,103621.msg1066443.html#msg1066443 gestern noch erwähnt.

Wenn ich es richtig verstehe, kann man nun folgende Werte manipulieren:

    sethkrwindowopen
    sethkrboost


Und folgende Werte auslesen:

    <boostactive>
    <boostactiveendtime>
    <windowopenactive>
    <windowopenactiveendtime>
    <holidayactive>
    <summeractive>

[rudolfkoenig]

hast Du Interesse an einen neuen Patch von mir für die restliche neue Kommandos / Readings

Ja, gerne, dann hat das naemlich jemand einmal getestet

[amenomade]

Hier der Patch

Getestet bis zu Fritzbox: ich habe leider nur Fritz/Comet DECT 300 (nicht 301), die den Boost Modus nicht unterstützen. Die Kommandos werden bis zum Fritzbox weitergeleitet, die Antwort von der Fritzbox entspricht die AHA Doku, aber was dann die Fritzbox mit den Geräte machen würde, kann ich nicht testen. Die Werte werden aber richtig gesetzt, da die Readings beim nächsten Poll stimmen

Ich weiss nicht, wie man den Benutzern klar machen könnte, dass das Setzen von einem boost oder windowopen Modus erst beim nächsten Wecken vom entspr. "Batterie-gesteuerten" Device mitberücksichtigt wird. Eigentlich haben hier die Befehle nur Sinn, wenn man die Dauer gross genug setzt, und ggf. manuell bei Bedarf mit Dauer 0 cancelt. Na gut... das ist (leider) wie die Fritz!DECT Geräte funktionieren (keine Push Funktion)

[rudolfkoenig]

Danke fuer den Patch, habs eingecheckt.

das Setzen von einem boost oder windowopen Modus erst beim nächsten Wecken vom entspr. "Batterie-gesteuerten" Device mitberücksichtigt wird.

Ist das gesichert? Ich meine was Anderes gelesen zu haben, weiss aber nicht mehr wo. Wie auch immer: das ist kein FHEM-Problem, sondern Eigenschaft der entsprechenden AVM-Produkte.

Anders ist das beim Knopf-Druecken: Bei FritzBox-Verknuepfungen funktioniert es, FHEM haengt nur wegen der "neuen" API hinterher, und das ist fuer den Benutzer nicht transparent.

[kptkip]

Aloa,

ich hab gerade ein update all gemacht und mir die "specific help" eines der Fritzdect 301 Devices angeschaut. Dort steht munter die neue boost- und windowopen-Beschreibung drin. Also dachte ich: Alles paletti!

Habs nun ausprobiert:

Code Auswählen Erweitern

set [DEVICENAME] boost 500

und erhalte folgende Fehlermeldung:

Code Auswählen Erweitern

Unknown argument boost, choose one of closed desired-temp open raw attrTemplate:

Im set Dropdown-Feld sehe ich auch keine Befehle für boost und windowopen.

Hab ich was übersehen?

[amenomade]

Bitte ein "list" vom Device.