Hallo,
ich habe einen FS20-Dimmer, den ich mit der "Hardware"-Variante des timers betreibe. Um den Status im FHEM nachzuführen, habe ich entsprechend "follow-on-timer" auf die gleiche Zeit wie im Gerät gesetzt. Das Nachführen funktioniert leider nur beim "on"-Befehl, nicht bei den dimXY%-Befehlen. Der Dimmer selbst beachtet seinen internen Timer auch bei den Dim-Befehlen. Im Code habe ich diese Stelle gefunden:
10_FS20.pm:
Zeile 211:
if($a[1] eq "on" && $na == 2 && $onTime) {
ersetzt durch
if(($a[1] eq "on" || $a[1] =~ m/dim(06|[1-9][0-9]|100)%/) && $na == 2 && $onTime) {
Das hat bei mir geholfen. Die Regex ist sicher nicht optimal kurz. Das "on" habe ich auch bewusst so gelassen, damit es nicht den "follow-on-for-timer" in den nächsten Zeilen vorwegnimmt. Was ich nicht beurteilen kann: Beachtet nur "mein" Dimmer den timer bei den Dim-Befehlen? Oder ist das so allgemein, dass es der Maintainer (Rudolf) im Modul ergänzen kann? (mit hübscherer Regex ;) ).
Falls es nicht ins Modul kommt: Was kann ich tun, damit meine lokale Änderung bei mir beim nächsten Update nicht überschrieben wird?
Grüße,
Torben
Habs kurz getestet, in der Doku erwaehnt und eingecheckt.
Ob der timer bei allen Geraeten funktioniert, weiss ich nicht, ich waere aber nicht ueberrascht.
Um lokale Aenderungen zu behalten gibt es zwei Moeglichkeiten:
- update mit "attr global exclude_from_update FS20".
- FHEM aus einem ausgecheckten SVN Baum betreiben, und update durch "svn update" ersetzen. Vorteil: beide Aenderungen bleiben (wenn moeglich) erhalten. Nachteil: es kann schiefgehen, Stichwort conflicts
Hallo,
danke fürs Einbauen. Mein krudes Regex sollte die Reaktion auf Dim00% verhindern, aber mittlerweile habe ich gesehen: 0% gibt es ja gar nicht :)
Danke auch für die Hinweise zum direkten arbeiten auf SVN. Mergeprobleme sollte ich ja nur mit eigenen Änderungen bekommen und die sollte ich dann auch gelöst bekommen.
Auch wenn es hier leicht OT wird: Irgendwelche "Migrationsaufrufe" des normalen updates bekomme ich nach shutdown restart dann auch mit? Oder muss ich da mehr aufpassen, wenn es größere Änderungen gibt?
Grüße,
Torben
Wenn du die Zeilen in der CHANGED Datei meinst: diese Datei darf/muss man bei einem svn update freiwillig lesen.
Ok, die CHANGED meinte ich nicht. Ich habe vermutlich einfach die Mächtigkeit des FHEM-update Befehls überschätzt. Danke für die Info.
Hallo,
ich hatte gestern bei mir auch ein Problem mit follow-on-timer festgestellt, deshalb hänge ich mich hier ran. Bei mir ist die Situation etwas anders:
Der FS20 Schalter ist auf automatisches Ausschalten konfiguriert. In fhem ist die Zeit über das follow-on-timer Attribut konfiguriert. Das Ganze funktioniert wunderbar, solange der Schalter über seine direkte Adresse angesprochen wird. Beim Schalter ist aber auch eine lokale sowie eine globale Masteradresse konfiguriert. Wird der Schalter darüber angesprochen scheint das follow-on-timer nicht zu greifen, d.h. in fhem bleibt der Status auf "on".
Grüße
Physikus
Zitat von: Physikus1 am 28 Februar 2016, 10:25:45
... Schalter ist aber auch eine lokale sowie eine globale Masteradresse konfiguriert. Wird der Schalter darüber angesprochen scheint das follow-on-timer nicht zu greifen, d.h. in fhem bleibt der Status auf "on".
Hast Du denn bei Deiner Definition des Schalters in Fhem die anderen Adressen auch mit angegeben? Mach doch mal ein
list deinFS20SchalterSiehe auch commandref zu FS20:
define <name> FS20 <housecode> <button> [fg <fgaddr>] [lm <lmaddr>] [gm FF]Peter
Ja, die habe ich angegeben. Wenn ich über die Masteradressen schalte, wird der Status des FS20-Schalters in fhem auch entsprechend aktualisiert.
Man kann das Problem einfach nachstellen, indem man follow-on-timer bei einem Schalter zu Testzwecken einfach auf z.B. 10 Sekunden setzt. Schaltet man dann, sollte in fhem der Status nach 10 Sekunden wieder auf "off" gehen. Das passiert aber nur beim Schalten über die direkte Adresse.
Physikus
Ich habe mir das FS20-Modul angeschaut. So wie ich es verstehe, wird am Ende der Set-Methode über alle "verknüpften" Devices iteriert und jeweils readingsSingleUpdate aufgerufen. Dabei wird aber ignoriert, dass für diese Geräte auch ein "follow-on-timer" gesetzt sein kann. Ich habe hier die schon in der Methode vorhandene Behandlung übernommen und in die Schleife integriert. Das behebt mein Problem. Allerdings fehlt mir der Gesamtüberblick, so dass es ggf. Seiteneffekte geben kann. Daher wäre es schön, wenn mein Patch begutachtet werden und dann ins Modul einfließen könnte.
Physikus
Habe den Patch nochmal hier etwas sichtbarer gepostet:
http://forum.fhem.de/index.php/topic,50138.0.html (http://forum.fhem.de/index.php/topic,50138.0.html)