HM Dimmen up/down: Merkwürdiges Verhalten

[Sebastian Bieber]

Guten Abend, Gemeinde!

Ich werde wahnsinnig...

Im Moment versuche ich, das dimup/dimdown-Verhalten einer FS20-Fernbedienung auf einen HomeMatic-Dimmer zu übertragen.

Mein erster Ansatz war eine virtuelle Fernbedienung mit zwei Buttons -> peeren mit dem HM Dimmer -> dimup/dimdown abbilden durch "press long" der virtuellen Buttons.

Mein zweiter Ansatz war die Nutzung der "up"- und "down"-Befehle des CUL_HM-Devices.

Ergebnis: Funktioniert beides nicht. Es passiert schon was, aber meistens "irgendwas", nicht das, was ich erwarte. Mal dimmt "press long" in die falsche Richtung, oder gar nicht, oder das Dimmen wechselt die Richtung, oder, oder, oder... die up- und down-Kommandos springen mehr oder minder wild zwischen verschiedenen Helligkeitswerten hin und her.

Mache ich was falsch? Muss ich irgendwelche Register-Werte setzen? Hat jemand ähnliche Erfahrungen gemacht?

Hilfe! Bitte!!!

So long, Sebastian

[martinp876]

Hallo Sebastian

Mache ich was falsch

was machst du den?
fangen wir mit den up/down kommandos an. Die sollten immer um 10% heller/dunkler machen. Es sollte sich auch der state entsprechend aendern .
gibtst du "up" ohne parameter ein?
kannst du ein Beispiel beschreiben oder loggen?

Gruss
Martin

[Sebastian Bieber]

Hi, Martin!

Hmm, ok, sorry, ich hatte gehofft, auf ein bekanntes Problem gebrummt zu sein. Für ein Einzelschicksal war das natürlich deutlich zu wenig Information.

Also, die Idee ist einfach die folgende:

define fb_not_og_bad3B  notify fb_og_bad3:dimdown       set ib_og_bad3 down
define fb_not_og_bad3C  notify fb_og_bad3:dimup         set ib_og_bad3 up

fb_og_bad3 ist eine FS20-Fernbedienung, ib_og_bad3 der HM-Dimmer. Wenn ich das so umsetze, also alle 0.4 s einen "up"- oder "down"-Befehl absetze, dann passiert wirres Zeug. Ich beschreib' mal, was der Dimmer macht:

Vorbereitung: set ib_og_bad3 25, damit man was sieht.
Aktion:       set ib_og_bad3 up, etwa 2 x pro Sekunde

Das erste up inkrementiert um 5% = Ein Step. Sieht optisch auch richtig aus. Das zweite up inkrementiert wieder, sieht auch richtig aus. Mit dem dritten up landet der Dimmer wieder bei 25% (optisch geschätzt). Dann wieder 2 "gute", dann wieder zurück, und immer so weiter. Wenn man aufhört, die up-Kommandos abzusetzen, geht das Spiel noch eine Weile so weiter (Kommando-Buffer?) und hört dann auf.

Das ist das Ergebnis einer Simulation, also mit manuell abgesetzten Kommandos - die FS20-FB kann also nicht gestört haben!

Wenn man das gleiche macht, aber zwischen den up's mehr Pause macht (2 s), dann passiert genau das richtige, der Dimmer macht immer weiter auf und ist irgendwann bei 100%.

Ich hab' mit zwei verschiedenen HM-Dimmern gestestet (HM-LC-Dim1PWM-CV bzw. HM-LC-DIM1T-PL), die benehmen sich genau gleich.

Ein Protokoll kann ich aktuell leider nicht beisteuern, dazu müsste ich erstmal Feierabend machen ;-) Wie erstelle ich denn am besten einen aussagefähigen Mitschnitt?


So long, Sebastian

[martinp876]

Wenn ich das so umsetze, also alle 0.4 s einen ...

das ist schnell. Die default Rampe ist 2.5 sec. Wenn du also alle .4 sec eine step absetzt ist der Dimmer noch mitten im dimmen.
Anzumerken ist, dass das dimmen im FHEM errechnet wird. Ich nehmen den aktuellen wert und addiere 10%.
Nachdem der dimmer also noch im vollen galopp ist gibt es noch keinen neuen Status, wenn du den 2. Trigger schickst. Die Berechnung basiert warscheinlich noch auf dem alten Wert.
Das sollte das Verhalten erklaeren, auch, dass es mit der Pause funktioniert.

Alternativen sind (achtung, in den Zeiten ist noch ein bug... da kann es Probleme geben

set ... up 10 0 0.5 # rampe ist 0.5 sec.

Aber du bist immer noch an die reaktionszeiten des dimmer gebunden.
Mal sehen, ob ich es hinbekommen, den Wert zu merken.

Logs brauche ich keine mehr dazu.

[Sebastian Bieber]

Hi, Martin!

Ok, jetzt bin ich ein gutes Stück weiter. Ich hab' mal mit timings experimentiert.

Folgendes funktioniert schonmal "halbwegs":

define test at +*{10}00:00:01 set ib_eg_wz6 up

Das korrespondierende Logfile sieht so aus:

2013.03.18 19:42:16 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "0.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:17 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:18 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "8 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:19 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "11.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:20 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "15 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:21 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "18.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:22 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "22 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:23 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "25.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:24 2: CUL_HM set ib_eg_wz6 up rxt:1
Argument "29 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:42:25 2: CUL_HM set ib_eg_wz6 up rxt:1
[/font]

Das hier klappt dann perfekt:

define test at +*{10}00:00:01 set ib_eg_wz6 up 10 0 0

Das korrespondierende Logfile sieht so aus:


2013.03.18 19:45:36 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "10 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:37 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "20 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:38 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "30 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:39 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "40 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:40 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "50 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:41 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "60 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:42 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "70 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:43 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "80 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:44 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
Argument "90 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2066.
2013.03.18 19:45:45 2: CUL_HM set ib_eg_wz6 up 10 0 0 rxt:1
[/font]

Ich hab' dann nochmal das hier versucht:

for (my $i=0;$i<10;$i++){
  fhem( "set ib_eg_wz6 up 10 0 0" );
  sleep( 0.5 );
}


Aber das ging voll nach hinten los - da kamen dann alle Statusmeldungen des Dimmers direkt NACH dem Ende der Schleife... ^^

Ich spiele noch ein bisschen weiter und melde mich mit Ergebnissen. Aber ein dickes "DANKE" schon mal für die Unterstützung, Martin!

So long, Sebastian

[martinp876]

Ich hab' dann nochmal das hier versucht:

for (my $i=0;$i<10;$i++){
fhem( "set ib_eg_wz6 up 10 0 0" );
sleep( 0.5 );
}

ja, die Parameter hatte ich "verrutscht" - schande...

probier es noch einmal mit Version 2946.
Aber alle 3 files nachladen wenn du es manuell machst,
HMConfig, 00_HMLAN und 10_CUL_HM

Gruss
Martin

[Sebastian Bieber]

Moin!

Neuer Tag, neue Runde. Martin, ich hab' die drei Module erneuert, und mache jetzt genau die gleichen Tests nochmal.

Test 1:
-------
define test at +*{10}00:00:01 set ib_eg_wz6 up

2013.03.19 06:20:19 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "0.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:20 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:21 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "8 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:22 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "11.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:23 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "15 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:24 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "18.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:25 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "22 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:26 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "25.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:27 2: CUL_HM set ib_eg_wz6  rxt:1
Argument "29 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:20:28 2: CUL_HM set ib_eg_wz6  rxt:1


Test 2:
-------
define test at +*{10}00:00:01 set ib_eg_wz6 up 10 0 0

2013.03.19 06:23:24 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "10 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:25 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "20 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:26 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "30 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:27 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "40 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:28 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "50 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:29 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "60 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:30 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "70 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:31 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "80 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:32 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
Argument "90 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:23:33 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1



Test 3:
-------
for (my $i=0;$i<10;$i++){
fhem( "set ib_eg_wz6 up 10 0 0" );
sleep( 0.5 );
}


Das benimmt sich deutlich anders! Komisch, aber nicht schlecht :-) :
Zuerst läuft die Schleife durch. Im Log erscheint das hier:
2013.03.19 06:26:53 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:54 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:54 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:55 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:55 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:56 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:56 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:57 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:57 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1
2013.03.19 06:26:58 2: CUL_HM set ib_eg_wz6 10 0 0 rxt:1

Am Dimmer tut sich in der Zeit NIX (!), der bleibt aus. Nach beendetem Schleifendurchlauf tickert der Dimmer dann ganz brav durch 10 Helligkeitsstufen von 0 nach 100% :-)))! Luschtig!

Weitere Beobachtungen: Die rampup-time funktioniert jetzt. Die wurde gestern irgendwie nicht berücksichtigt, bzw. wirkte immer wie "0", egal, was man angab.

Das hier

define test at +*{10}00:00:01 set ib_eg_wz6 up 10 0 0.5


bringt ihn aber immer noch um:
2013.03.19 06:39:38 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "0.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:39 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "10.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:40 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "11 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:41 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "21 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:42 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "22 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:43 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "31.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:44 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "32.5 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:45 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "42 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:46 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1
Argument "43 %" isn't numeric in addition (+) at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2073.
2013.03.19 06:39:47 2: CUL_HM set ib_eg_wz6 10 0 0.5 rxt:1


Wohingegen das hier:
for (my $i=0;$i<10;$i++){
fhem( "set ib_eg_wz6 up 10 0 0.5" );
sleep( 0.5 );
}


Perfekt funktioniert: Erst die Schleifendurchlauf, dann 10 "weiche" Dim-Vorgänge.

Ich werde als nächstes mal folgendes versuchen:

define fb_not_og_bad3B  notify fb_og_bad3:dimdown       set ib_og_bad3 down 10 0 0
define fb_not_og_bad3C  notify fb_og_bad3:dimup         set ib_og_bad3 up 10 0 0


und schauen, wie sich das benimmt!

So long, Sebastian

[martinp876]

Hi Sebastian,

ok, liegt am '%' - das hatte ich nicht in meinen tests - muss ich  noch entfernen, sonst kann perl nicht rechnen.
seltsam, dass es bei mir nicht kam...

Gruss
Martin

[Sebastian Bieber]

:-) Ich find' die Warnings im Moment ganz praktisch - da sieht man schön, was Dein Modul gerade "sieht" vom Dimmer! Bau' das mal noch nicht aus... :-)


So long, Sebastian

[martinp876]

ich kann ggf ein log drin lassen. Aber die warnings muessen raus. Das ist ja das Problem. Ich will die Werte nutzen um die 10% zu addieren. Perl sieht aber keine Zahl sondern einen string - und damit ist der Rechenwert '0' - wir kommen also immer auf 10%, es wird nicht hochgerechnet.
Es werden aber die readings virtLevel incrementiert oder state. Mit inform on bekommst du dann die aenderungen auch.
Da jetzt aber immer '0' rauskommt ist es keine aenderung und  - wenn ru event-on-change gesetzt hast, kommt auch kein notify.

[martinp876]

ready for test, 2951. 10_CUL_HM und HMConfig (fuer WDS)

[Sebastian Bieber]

Moin!

Ich melde mich mal mit einem Zwischenstand, damit nicht der Eindruck entsteht, ich würde mich nicht mehr kümmern!

Also, ich habe jetzt mal ausprobiert, die dim-Kommandos der FS20-Fernbedienung so zu übersetzen:

define fb_not_og_bad3B notify fb_og_bad3:dimdown set ib_og_bad3 down 10 0 0
define fb_not_og_bad3C notify fb_og_bad3:dimup set ib_og_bad3 up 10 0 0


Das funktioniert im Prinzip. Bei kurzen Betätigungen der Fernbedienung (z.B. 2 Sek.) bekommt man, wie gewünscht, ein stufiges Herauf- oder Herunterdimmen des HM-Dimmers. Hält man die Fernbedienung länger gedrückt, bekommt man einen "Nachlauf": Auch nach Loslassen der Taste werden an den Dimmer noch Befehle gesendet, und zwar ggf. auch mehrere Sekunden lang! Das verstehe ich aktuell noch gar nicht, wo das herkommt.

In den nächsten Tagen bekomme ich eine zusätzliche FHZ. Die sollte mir helfen, die Funkstrecke erheblich zuverlässiger zu machen, gerade in der hier getesteten Umgebung, insofern sind meine Beobachtungen erstmal nur vorläufig. Ich werde mich hier wieder melden, wenn ich endgültige Resultate habe.

So long, Sebastian

[martinp876]

Hallo Sebastian,

"down 10 0 0" bedeuten:
  step=10%
  ontime=0 wird nach unendlich ersetzt
  ramptime 0=> muss ich mal ansehen, was da kommt. Evtl nimmst du einmal 0.5 hier?

bekommt man einen "Nachlauf"

kann ich auch nicht sagen. hier waeren die trigger interessant, kannst du alle trigger aufzeichnen? Und die messages zu HM dazu.

Was HM betrifft erwarte ich einen dim-step je trigger.
Wie viele trigger loest dein FS20 aus? wie schnell? gibt es wiederholer? doppel-trigger?

Einstellen wuerde ich, dass die Ramp-time dem trigger interval des FS20 buttons entspricht.

Gruss, Martin

[Sebastian Bieber]

Seltsam... Ich war fest davon überzeugt, dass ich dazu schonmal was geschrieben hab. Aber ich finde den Beitrag nicht wieder. Ich muss echt mal auf meinen Konsum achten... :-)

Also: Mit ramp-time 0 bekommt man vom HM-Dimmer sofort eine Rückmeldung mit dem finalen Status (äh - "dim:stop" oder so ähnlich). Wenn man aber eine ramp-time > 0 vorgibt, bekommt man _zwei_ Meldungen, eine "in progress"-Meldung sofort, und hinterher eine "dim:stop"-Meldung. Bloß: Die stop-Meldung kommt frühestens (geschätzt) eine Sekunde nach der Start-Meldung! Bei kurzen ramp-times also lange, nachdem der Dim-Vorgang abgeschlossen ist. Das, Martin, bringt Dein Modul komplett durcheinander!

Konsequenz: Wenn man schnelle, wiederholte Vorgänge haben will (einen pro Sekunde oder mehr), dann muss man auf ramp-Zeiten verzichten. Soweit, zumindest, meine Forschungen.

So long, Sebastian

[martinp876]

Hi,

Ich war fest davon überzeugt, dass ich dazu schonmal was geschrieben hab

ja, ich denke es waren so 2 sec? Wollte noch einmal den aktuellen Stand - und vorallen das konkrete Verhalten an hand der Trigger.

Mit ramp-time 0 bekommt man vom HM-Dimmer sofort eine Rückmeldung... ramp-time > 0 ... bekommt man _zwei_ Meldungen, eine "in progress"-Meldung sofort, und hinterher eine "dim:stop"-Meldung. Bloß: Die stop-Meldung kommt frühestens (geschätzt) eine Sekunde nach der Start-Meldung! !

ja, hoert sich gut an. Der Aktor sendet seinen Zustand immer verzoegert, kann man u.U. sogar einstellen.
Es sollte eigentlich eine AckStatus und eine Info_Status geben. KMoeglichm das die Info_status bei ramp=0 eingespart wird....

Bei kurzen ramp-times also lange, nachdem der Dim-Vorgang abgeschlossen ist. Das, Martin, bringt Dein Modul komplett durcheinander!

hmm... up/down nimmt den aktuellen Status und addiert den gewuenschten Wert.
Der aktuelle Status wird aus dem gemeldeten Wert errechnet. Soweit kann ich am Prinzip nichts aendern. Schliesslich gibt es viele moeglichkeiten, die Helligkeit einzustellen.
Somit gibt es ein Problem bei bestimmten Verzoegerungen der Trigger und der Status-Meldungen. Ich werde einmal nachdenken ob ich die 'transienten' Meldungen aus der Berechnung entfernen kann.

Konsequenz: Wenn man schnelle, wiederholte Vorgänge haben will (einen pro Sekunde oder mehr), dann muss man auf ramp-Zeiten verzichten.

Die Rampe sollte immer kuerzer sein als die angestrebte wiederholrate. Schneller sollte kein Problem sein. Die schnellste Rampe sollte 0.05sec sein (oder eben 0).
Hab ich nicht getestet: was passiert, wenn man einen trigger 'in einer Rampe' schickt.
Test:
up 10 0 20  # schoene lang Rampe, da kann man bequem von Hand einen trigger nachreichen
pct 20 0 3  # setze auf 20% in 3 sec
=> wann ist der Vorgang beendet? Welchen Wert hat der Aktor? Ist die Rampe unterbrochen worden?

Das ganze erklaert aber in keinem Fall dein 'nachlaufen'. Auch wenn ein falscher Wert errechnet wuerde:
- jeder FS20 trigger sollte ein HM kommando ausloesen
- ein nachlaufen sollte nicht stattfinden, auch wenn der Wert nicht korrekt waere.
- verzoegerte Statusmeldungen sollten kein Nachlaufen erzeugen
==> zum Thema "nachlaufen" haette ich gerne die Logs

Gruss Martin