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
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?
Vielen Dank für die Rückmeldung!
Laut Doku im wiki ist Color nötig, damit das Widget colorpicker in
$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?
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 :)
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" ;)
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.
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.
Es reicht wahrscheinlich in FBDECT_getDiscreteSat ein
@discreteSat = sort { $a <=> $b } @discreteSat;
direkt nach
my @discreteSat = (@{$colordefaults{$color}{sat}}, 9999);
weil Du sonst in @discreteSat für z.B. red folgendes kriegst:
$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.
Danke fuer die Suche, ich habe reverse dazugepackt.
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.
ZitatWenn ich es richtig verstehe, kann man nun folgende Werte manipulieren:
sethkrwindowopen
sethkrboost
Und folgende Werte auslesen:
<boostactive>
<boostactiveendtime>
<windowopenactive>
<windowopenactiveendtime>
<holidayactive>
<summeractive>
Zitathast Du Interesse an einen neuen Patch von mir für die restliche neue Kommandos / Readings
Ja, gerne, dann hat das naemlich jemand einmal getestet :)
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)
Danke fuer den Patch, habs eingecheckt.
Zitatdas 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.
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:
set [DEVICENAME] boost 500
und erhalte folgende Fehlermeldung:
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?
Bitte ein "list" vom Device.
Voilà:
Internals:
DEF FritzDECT:09995_0049294 actuator,tempSensor
FUUID 5c4f9cf5-f33f-57e4-3069-76fbffbdf3f06e47
FritzDECT_MSGCNT 24
FritzDECT_TIME 2020-07-01 18:59:36
IODev FritzDECT
LASTInputDev FritzDECT
MSGCNT 24
NAME Heizung_Schlafen
NR 23
STATE desired-temp: 18.0 C
STILLDONETIME 0
TYPE FBDECT
id 09995_0049294
props actuator,tempSensor
webCmd desired-temp
Helper:
DBLOG:
temperature:
DBLogging:
TIME 1593618576.49452
VALUE 22.0
READINGS:
2020-07-01 18:59:36 AIN 09995 0049294
2020-07-01 18:59:36 FBNAME Schlafzimmer
2020-07-01 18:59:36 FBPROP actuator,tempSensor
2020-07-01 18:59:36 FBTYPE FRITZ!DECT 301
2020-07-01 18:59:36 ID 21
2020-07-01 18:59:36 battery 100 %
2020-07-01 18:59:36 batteryPercent 100
2020-07-01 18:59:36 batteryState ok
2020-07-01 18:59:36 batterylow 0
2020-07-01 18:59:36 boostactive no
2020-07-01 18:59:36 boostactiveendtime N/A
2020-07-01 18:59:36 day-temp 18.0 C
2020-07-01 18:59:36 desired-temp 18.0 C
2020-07-01 18:59:36 devicelock no
2020-07-01 18:59:36 errorcode noError (0)
2020-07-01 18:59:36 fwversion 04.94
2020-07-01 18:59:36 holidayactive no
2020-07-01 18:59:36 locked no
2020-07-01 18:59:36 nextPeriodStart 2020-07-01 22:00:00
2020-07-01 18:59:36 nextPeriodTemp 18.0 C
2020-07-01 18:59:36 night-temp 18.0 C
2020-07-01 18:59:36 present yes
2020-07-01 18:59:36 state desired-temp: 18.0 C
2020-07-01 18:59:36 summeractive no
2020-07-01 18:59:36 tempadjust -4.0 C
2020-07-01 18:59:36 temperature 22.0 C (measured)
2020-07-01 18:59:36 windowopenactiv no
2020-07-01 18:59:36 windowopenactiveendtime N/A
Attributes:
DbLogExclude .*
DbLogInclude desired-temp,temperature
IODev FritzDECT
alias Heizung Schlafzimmer
event-min-interval power:120
event-on-change-reading state,temperature,desired-temp
group Geräte für Heizung
homebridgeMapping TargetTemperature=desired-temp::desired-temp,minValue=5,maxValue=35,minStep=0.5,nocache=1 CurrentTemperature=temperature,nocache=1
icon hm-cc-rt-dn
room Obergeschoss->Schlafzimmer
Ok, mein Schuld. Als ich die Änderungen in die inzwischen von Rudi wieder modifizierte Version übertragen habe, habe ich eine Zeile vergessen.
Ich bereite den Patch vor.
Und hier der Patch
Danke, habs eingecheckt.
Aloa,
Ich hab die neuen Funktionen getestet mit meinen Fritz!DECT 301 Heizungsthermostaten.
Kurze Rückmeldung: Es klappt!
Was hier allerdings das Problem ist - und dafür könnt Ihr als FHEM-Entwickler nunmal nix - ist die lange Latenz beim Synch zwischen Fritzbox und Thermostat.
Ich mach mal ein Beispiel:
- Es ist 10:00 Uhr und schicke den Befehl set DEVICENAME boost 300 (vulgo: Booste für 5 Minuten)
- Der ,,timestamp" im FHEM-Device steht also auf 10:05, um wieder abzuschalten.
- Der wird auch an die Fritzbox gesendet
- Dann dauert es - bei mir so rund 2-5 Minuten, bis das Thermostat auch reagiert. Kann offiziell bis zu 15 Minuten dauern.
- Die Konsequenz ist, dass das Thermostat u.U. Erst um 10:04 Uhr boostet und um 10:05 wieder abschaltet.
Ob das - gerade beim windowopen - so zielführende ist, darf bezweifelt werden. Selbst wenn er nicht den absoluten timestamp sondern die Dauer übermitteln würde, wäre das m.E. nicht optimal, weil der Zeitversatz immer noch drin wäre.
Aber wie gesagt, das ist ein Problem in der Kommunikationsstrategie von AVM.
Soweit mein Erfahrungsbericht.
Ob ich das ernsthaft einsetzen werde, bin ich mir noch nicht sicher. Trotzdem vielen Dank an @amenomade und @rudolfkönig.
Gruß
Alex
Danke für die Rückmeldung