HM-HM-LC-DW-WM | Ramptime begrenzt?

[fast-eddy]

Hallo zusammen,

ich möchte auch Basis des Dual White LED Controllers HM-HM-LC-DW-WM eine Konstantlichregelung bauen.
Diese soll analog zum Sonnenstand (zumindest grob) Helligkeit und Lichtfarbe der LED Beleuchtung anpassen.
Mit Hilfe vom Damian und TomLee habe ich auch ein DOIF definiert was im Prinzip genau das abbildet was ich erreichen
möchte.

https://forum.fhem.de/index.php/topic,91218.0.html

Allerdings funktioniert das in der Praxis nicht, obwohl laut Logfile alle commands und Parameter korrekt abgesetzt werden.

2018.09.19 08:30:00 3: CUL_HM set eg_garderobe_HELLIGKEIT pct 5
2018.09.19 08:30:05 3: CUL_HM set eg_garderobe_HELLIGKEIT pct 40 0 20817.5
2018.09.19 08:30:05 3: CUL_HM set eg_garderobe_FARBE pct 100 0 20817.5

Meine Vermutung ist jetzt, dass die ramptime im Device limitiert ist und so lange Zeiträume (bis zu 33.000 Sekunden) nicht
abbilden kann. Im Controller selbst ist nur ein kleiner Atmega Controller mit wenig Speicher verbaut.

Abgesehen davon, dass der Regelprozess nach einer gewissen Zeit einfach aufhört (siehe Link oben) ist mir nichts aufgefallen
was auf einen Fehler hindeutet, außer die regelmäßig wiederkehrenden Attack Meldungen im Logfile:

2018.09.19 18:38:39 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:39 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:39 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:43 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:43 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:48 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:48 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:49 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:53 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:53 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E
2018.09.19 18:38:54 2: CUL_HM HM_59E794 attack:01F1234159E794020E,11F1234159E79402010A0320AB47:11E9FEE59E794010E

Kann mir jemand sagen ob die ramptime bei diesem device (oder in fhem generell) tatsächlich begrenzt ist oder woran es sonst liegen kann, dass
die Regelung nicht funktioniert bzw. nach eniger Zeit abbricht?

[papa]

Laut XML-Beschreibung rf_dw.xml

Code Auswählen Erweitern

<parameter id="RAMP_TIME" operations="write" control="NONE">
<logical type="float" min="0.0" max="85825945.6" default="0.5" unit="s"/>
<physical type="integer" interface="store" id="RAMP_TIME" volatile="true"/>
<conversion type="float_integer_scale" factor="10"/>
<conversion type="integer_tinyfloat" mantissa_start="5" mantissa_size="11" exponent_start="0" exponent_size="5"/>
</parameter>

sollte das gehen.

[frank]

attack: du steuerst das device wahrscheinlich mit einem gateway, das fhem nicht bekannt ist.
bei mehreren io solltest du eine vccu nutzen.

[fast-eddy]

Hallo Frank,

danke für Dein Feedback aber eine VCCU läuft bei mir von Anfang an und diese ist auch sauber im Device einegtragen.
Daran kann das attck also nicht liegen - leider! Sonst hätte ich das Problem schon gelöst

[fast-eddy]

Nachdem die commands:

Code Auswählen Erweitern

set eg_garderobe_HELLIGKEIT pct 40 0 25200   
set eg_garderobe_FARBE pct 100 0 32400
auch manuell eingegeben, d.h. ganz ohne DOIF nur einen dimup von 0.5% ausführen und dann abbrechen
bin ich doch davon überzeugt, dass entweder die Ramptime anders als in der XML Definition angegeben
beschränkt ist oder mit der Device Implementierung HM-HM-LC-DW-WM was nicht stimmt.

Hat noch jemand das Device und könnte das mal verifizieren?

[frank]

zeig mal je ein list von vccu und allen gateways.

[fast-eddy]

Hallo frank,

das Device verliert immer mal wieder das Pairing zur vccu.
Nach einem neuen Pairing mit der vccu sind die attack Meldung erst mal für ne weile weg.
Habe das Device jetzt mal hinter der Wanverkleidung vorgeholt und siehe da Blink Code 1 x lang / 2 x kurz => Gerät defekt.
Das würde auch erklären warum das mit den commands nicht klappt.

Mal sehen was ELV dazu sagt - ist ja ein Bausatz!

Danke für Eure Hilfe. Melde mich wieder wenn Fortschritte gibt.