Bin auf der Suche nach Details zur HM "on-for-timer" Unterstützung. Zwar benutze ich on-for-timer auch bei HM seit Jahren, aber im Grunde weiss ich im Gegensatz zu FS20 gar nicht, was da GENAU passiert.
1. Unterstützen HM Aktoren das wirklich nativ, oder ist das nur ein verdeckter FHEM "at .... switch device off" Befehl?
Ich glaube, die können das im Aktor. Aber daraus ergibt sich die Frage:
2. welche Granulation haben die Timerzeiten? Ist das wie bei FS20, dank 7bit Übertragung nur bestimmte Werte?
Was ich finde ist etwas ungenau, in einem Wikiartikel wird z.b. behauptet:
set <name> on-for-timer <sec> # schaltet den Aktor für <sec> ein
Können HM Aktoren im Gegensatz zu FS20 echt beliebige (Sekunden)zeiten?
3. off-for-timer kann HM nicht, korrekt?
Weiss jemand mehr?
1. on-for-timer wird vom Aktor selbst ausgeführt und die können das sogar ganz ohne FHEM
2. Ja, das geht funktioniert sehr genau, sogar mit Zeiträumen kleiner als 1 Sekunde.
3. korrekt
zu 2: meine olle Schaltdose zeigt in der regList 3: lgOnTime | 0.0 to 111600s | required | on time special:unused
zu 2. ich meine mich zu erinnern das die zeit intern ein float ist und deshalb ziemlich kleine und sehr grosse werte möglich sind, die genauigkeit aber bei größeren werten abnimmt.
wenn du lange zeiten sehr genau steuern möchtest bist du mit einem fhem at oder sleep vermutlich besser bedient.
@justme1968 jetzt wo Du es sagst fällt mir wieder ein: Da gab es glaub ich sogar eine Korrekturrechnung, ich denke: das hängt vom internen Quarz ab? Gefunden:
https://forum.fhem.de/index.php/topic,89561.msg820421.html#msg820421
Zitat von: justme1968 am 03 März 2021, 20:40:42
zu 2. ich meine mich zu erinnern das die zeit intern ein float ist und deshalb ziemlich kleine und sehr grosse werte möglich sind, die genauigkeit aber bei größeren werten abnimmt.
wenn du lange zeiten sehr genau steuern möchtest bist du mit einem fhem at oder sleep vermutlich besser bedient.
Das ist bei FS20 definitiv so, die Frage war eben, ob bei HM auch. Und wenn ja ob mit den gleichen Werten wie bei FS20. Die von Otto gefundenen Werte sprechen eher dagegen, denn FS20 max ist 15360 Sekunden.
Genauigkeit ist hier keine Thema.
Konkret ist die Aufgabe, ein Licht ca. 20 Minuten nach der letzten Auslösung eines PIRA aus zu machen.
Sicher funktioniert natürlich:
bei jeder Auslösung des PIRA Licht an und ausserdem defmod at +00:20:00 set X off
Aus Sicht von FHEM "billiger" da wenig Load ist aber: Licht on-for-timer irgendwas mit 1200 Sekunden.
Weiterer Vorteil: das Geht auch aus wenns Funkstörungen geben sollte.
Der Befehl geht auch immer, aber bei Aktoren die das nicht können, erzeugt FHEM - soweit ich mich erinnere - ein verdecktes at...
Dann wäre nichts gewonnen, nur schlechter lesbar, daher die Frage ob das auch bei HM echt im Aktor ist.
Und wenn ja welche Granulation bzw welches Feld. (Soweit ich mich erinnere rundet FHEM zum nächsten Wert den der Aktor kann, aber wäre eben doch nice zu wissen, was der Aktor kann, fand ich einfach nirgends.)
off-for-timer ist unter dem letzten Aspekt bei FS20 eine Super Sache bei Heizung. Der WAF eines Brenner die garantiert wieder angeht, selbst wenn Funk gestört ist oder FHEM tot umfällt ist schon ganz okay. ;D
Schade das HM das nicht kann.
EDIT: Otto123: Sieht für mich ein wenig so aus, als wenn das devicespezifisch ist. Wäre aber auch egal, für meine Anwendung sind sogar 30% Abweichung fast noch okay. Werd ich mal nachmessen.
Aber ob man Sekundengenau Werte übermitteln kann oder auch HM die Zeiten in einem Bitfeld abbildet, wissen wir trotzdem nich nicht. Aber für meine Fall nicht kritisch.
Zitat von: Zrrronggg! am 03 März 2021, 21:35:50
die Zeiten in einem Bitfeld abbildet
Wie denkst Du macht er es? Eine Feder aufziehen?
Man kann 0.1 sec Schritte angeben.
off-for-timer sollte auch mit der statemachine möglich sein, denke ich.
Zitat von: Otto123 am 03 März 2021, 21:46:58
Wie denkst Du macht er es? Eine Feder aufziehen?
Man kann 0.1 sec Schritte angeben.
Ich meinte, dass es ähnlich wie bei FS20 eine begrenzte Anzahl von Werten gibt. Bei 7 Bit wären das ja "nur" 128.
Dann kannst du wählen zwischen guter Auflösung oder guter maximaler Zeitdauer. Und bei FS20 ist es eben so gelöst, das die Auflösung nicht stetig ist.
Untenrum sind es 0.25 Sekunden, aber oben rum eher 1000 Sekunden: die letzten 3 Werte sind 13312, 14336, 15360 Sekunden.
In was überträgt HM die Zeit? 16 bit? Dann sind zwar mehr Werte möglich, aber das Problem bleibt bestehen. Wenn man stetig zwischen 0 und 111600 Sekunde in 0,1 Sekunden Auflösung linear alle Werte abbilden will, braucht man 1116000 Werte. Das ist in etwa zwischen 20 und 21 bit.
Ich halte es für unwahrscheinlich, dass HM die Timerzeit in 21 Bit Auflösung sendet und dann noch Werte ungenutzt lässt.
Daher ist anzunehmen, dass auch hier die Werte nicht linar auflösen.
Auf diesen Problemkreis wollte ich mit der stark verkürzten Formulierung "Bitfeld" hinweisen.
Was anderes: Ich habe eben zufällig gesehen, dass FHEM intern immer einen Timer anlegt, wenn man on-for-timer benutzt, selbst wenn der fragliche Aktor das autonom unterstützt. FHEM sendet also an einen FS20 Aktor "on-for-timer 20" und der Aktor schaltet nach 20 Sekunden ohne FHEM ab, FHEM sendet aber TROTZDEM nach 20 Sekunden selber zustzlich ein off.
Das wusste ich nicht. Ich dachte, FHEM macht das nur bei Aktoren, die timer nicht selber können.
Gut, sicher robuster. Kann ich aber paar Sachen ausdünnen.
Ich würde denken, dass ist Modul abhängig. Habe ich bei Homematic noch nicht beobachtet.
fhem macht das automatisch für devices die die setextensions nutzen.
hm verwendet keine setextension sondern implementiert alles selber. deshalb z.b. auch kein off-for-timer
die onTime steckt in den letzten 2 byte der raw message (0x0C80):
2021.03.04 10:00:53.044 3 : CUL_HM set SwitchPBU05 on-for-timer 10
2021.03.04 10:00:53.207 0 : HMLAN_Send: hmlan1 S:SFC77EBCC stat: 00 t:00000000 d:01 r:FC77EBCC m:F2 A011 1ACE1F 1A164B 0201C800000C80
eq3 beschreibt die unrechnung der onTime im xml file so:
<parameter id="ON_TIME" operations="write" control="NONE">
<logical type="float" min="0.0" max="85825945.6" default="0.0" unit="s" />
<physical type="integer" interface="store" id="ON_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>
cul_hm setzt das so um:
sub CUL_HM_encodeTime16($) {####################
my $v = shift;
return "0000" if($v !~ m/^[+-]?\d+(\.\d+)?$/ || $v < 0.05);
my $ret = "FFFF";
my $mul = 10;
for(my $i = 0; $i < 32; $i++) {
if($v*$mul < 0x7ff) {
$ret=sprintf("%04X", ((($v*$mul)<<5)+$i));
last;
}
$mul /= 2;
}
return ($ret);
}
nun sollte alles klar sein.
edit:
{CUL_HM_encodeTime16(85825945.6)}
das ergibt 0xCCB3.
sollten max sekunden nicht 0xFFFF ergeben?
eventuell ein fehler in der umsetzung?
gab es nicht auch berichte, dass grosse werte abweichungen in der onTime ergeben?
edit2:
scheinbar alles ok mit der berechnung, da über hmccu auch maximal 0xCCB3 gesendet wird.
auch grössere werte als 85825945.6 bei on-for-timer werden auf 0xCCB3 begrenzt.
Zitat von: justme1968 am 04 März 2021, 08:54:42
hm verwendet keine setextension sondern implementiert alles selber. deshalb z.b. auch kein off-for-timer
Verstehe ich das richtig, dass off-for-timer bei hm nicht implementiert ist aber grundsätzlich funktionieren sollte?
nein. wenn es nicht implementiert ist und keine setextenstion verwendet werden funktioniert es auch nicht.
So meinte ich das nicht.
Sondern so: off-for-timer ist in der hm-Hardware grundsätzlich angelegt (wie on-for-timer)? In cul-hm (FHEM) aber nicht implementiert?
ich denke mal laut nach:
Es gibt ein Reading timedOn - das ist der Status der bei on-for-timer gesetzt wird.
Die Aktoren sind normal einfache Schaltkontakte, in Ruhe aus, aktiv an.
Ein direkt flexibel steuerbares on-for-timer macht irgendwie Sinn (aktiv), ein off-for-timer nicht - das Ding ist ja normal aus.
Sieht für mich aus wie ein spezieller Modus - ohne Register schreiben! Deshalb gibt es eventuell kein off-for-timer.
Es gibt interne Register für die Peers, die sehen "symmetrisch" aus. Alles was mit On gibt gibt es auch mit off -> OnTime OffTimeMode usw.
Mit denen kann man on-for-timer per "Tastendruck" machen, sicher auch off-for-timer. Das funktioniert mit Register schreiben, also nicht "dynamisch" und beliebig änderbar. Das hat Frank ja gesagt: state-machine.
Ich habe dafür bisher keine Anleitung gefunden, im Gegensatz zum "Treppenlicht" ;) Muss sicher "bloß" mal einer konstruieren.
So etwas hatte ich in der Tat mal für einen Art Totmannschalter realisiert:
Durch ein Peering mit einem virtuellen Schalter und entsprechenden Setzen der Register konnte ich ein off-for-timer realisieren. Also regelmäßig (t<off-for-timer-Intervall) von FHEM ein off-for-timer-Kommando an den HM-Aktor dann bleibt der Aktor aus. Stirbt irgendwann FHEM schaltet der HM-Aktor automatisch an und ein Backup-System fährt hoch.
Da der HM-Aktor bei einem off-for-timer auch ein characteristisches Blinkschema aufweist, gehe ich auch fast davon aus, dass sich dies auch direkt innerhalb cul-hm realisieren ließe.
Zitat
Ein direkt flexibel steuerbares on-for-timer macht irgendwie Sinn (aktiv), ein off-for-timer nicht - das Ding ist ja normal aus.
Diese Aussage würde ich so nicht unterschreiben: ein off-for-timer kann durchaus Sinn ergeben; Beispiel: Totmannschalter (normal aus, aber an, wenn nicht mehr normal).
Zitat von: CQuadrat am 04 März 2021, 14:11:14
So meinte ich das nicht.
Sondern so: off-for-timer ist in der hm-Hardware grundsätzlich angelegt (wie on-for-timer)? In cul-hm (FHEM) aber nicht implementiert?
sieht nicht danach aus.
wenn ich einen on-for-timer befehl auf off-for-timer umbaue (10sek), wird die zeit einfach nicht beachtet. das licht wird ausgeschaltet, geht aber nicht wieder an:
2021.03.04 14:54:10.085 3 : CUL_HM set SwitchPBU06 raw ++A0111ACE1F3913D302010000000C80
2021.03.04 14:54:10.107 0 : HMLAN_Send: hmlan1 S:SFD846DB1 stat: 00 t:00000000 d:01 r:FD846DB1 m:73 A011 1ACE1F 3913D3 02010000000C80ZitatMuss sicher "bloß" mal einer konstruieren.
hier mal ein template für short oder long:
set hminfo templateDef off-for-timer_switch offTime "switch for offTime seconds to off level. " ActionType:jmpToTarget CtDlyOff:geLo CtDlyOn:geLo CtOff:geLo CtOn:geLo CtValHi:100 CtValLo:50 MultiExec:off OffDly:0 OffTime:p0 OffTimeMode:absolut OnDly:0 OnTime:unused OnTimeMode:absolut SwJtDlyOff:off SwJtDlyOn:on SwJtOff:no SwJtOn:dlyOff
Zitat von: frank am 04 März 2021, 15:45:51
wenn ich einen on-for-timer befehl auf off-for-timer umbaue (10sek), wird die zeit einfach nicht beachtet. das licht wird ausgeschaltet, geht aber nicht wieder an:
Möglichweise gibt es hier wirklich Limitierungen. Denn für alle Verknüpfungen wird eine in Grenzen anpassbare Statemachine angewendet, die Zentralenbefehle scheinen mir nach meinem bisherigen nebulösen Verständnis davon losgelöst - es gibt ja auch keine zu tunenden Register dafür.
Den Totmannwächter in Form einer über einen Steckdosenschalter bei FHEM-Ausfall eingeschalteten Lampe hatte ich auch schon mal testweise installliert, habe beim gezielten Herunterfahren sogar den Totmannwächter deaktivieren können.
Und für die Zeiten war ich doch auch schon mal in einer Diskussion über eine fehlerhafte Rundung involviert, ich finde die Beiträge aktuell nicht. Da gab es m.W. sogar eine Tabelle, in der die möglichen Zeiten und ihre Auflösungen gelistet waren...
edit.. Gefunden. Ging damals aber um andere Register mit nur einem Byte. https://forum.fhem.de/index.php/topic,112788.msg1071282.html#msg1071282
Ich bin noch nicht so ganz überzeugt.
Ich erkenne am HM-Aktor vier LED-Blink-Moden:
LED dauerhaft aus: Aktor off
LED dauerhaft an: Aktor on
LED blinkt (lang an, kurz aus): Aktor on (im on-for-timer-Modus; geht also nach vorgegebener Zeit automatisch dauerhaft aus)
LED blinkt (kurz an, kurz aus, lang an, lang aus): Aktor off (im off-for-timer-Modus; geht also nach vorgegebener Zeit automatisch dauerhaft an)
Durch diese deutlich unterschiedlichen Blinkcharakteristika vermute ich, dass das auch direkt in der HM-Hardware hinterlegt ist. Nein ich weiß es, da nach einem off-for-timer, der Aktor auch einschaltet, wenn zwischenzeitlich FHEM deaktiviert ist.
Register für den Totmannschalter:
set switch_Totmannschalter regSet shOnDly 600 virt_switch_Totmannschalter_Btn1
set switch_Totmannschalter regSet shSwJtOff dlyOn virt_switch_Totmannschalter_Btn1
set switch_Totmannschalter regSet shSwJtOn dlyOn virt_switch_Totmannschalter_Btn1
set switch_Totmannschalter regSet shSwJtDlyOn dlyOn virt_switch_Totmannschalter_Btn1
mit set virt_switch_Totmannschalter_Btn1 press short wird dann ein
set switch_Totmannschalter off-for-timer 600 "simuliert".
Bei mir so (nur Auszüge, ohne generelle Einrichtung der Geräte):
set vccu_Btn12_Watchdog CUL_HM pairChan 0 HM_WatchdogPlug single set # single peeren
set HM_Watchdog regSet shOffTime 130 vccu_Btn12_Watchdog # Auszeit 130 s
set HM_Watchdog regSet shSwJtOff dlyOff vccu_Btn12_Watchdog # short triggert immer off
defmod at_HM_Watchdog at +*0:01:30 set vccu_Btn12_Watchdog pressS HM_WatchdogPlug
Alle 90s latscht FHEM auf den virtuellen Button und schaltet den Aktor so aus. Bleibt das aus, geht er von allein an.
Ein simples "set HM_WatchdogPlug off" beendet den Zauber, weil die Statemachine unterbrochen wird.
Nichts anderes machst Du mit Deinem Beispiel (nur dass du mit einer Einschaltverzögerung arbeitest). Beide Varianten sind beliebig retriggerbar.
In meinem Fall ist das Blinkmuster allerdings invers zum Einzustand: kurz ein, lang aus. Das ist der echte Off-for-Timer Modus. Du hältst den Aktor im OnDelay, deswegen ein anderes Blinkmuster.
Nur: Auch Du benutzt hier die Statemachine einer Direktverknüpfung. Das funktioniert unstrittig. Die Zentralen-Schaltbefehle werden aber offenbar intern anders verarbeitet und wenn die Firmware dort kein Konstrukt zur Übergabe einer Ausschaltzeit vorsieht, können wir hier Kaffeesatzlesen veranstalten wie wir wollen - es wird nicht funktionieren. Man sieht das ja schon mal daran, dass die Zentralensteuerungen Parameter direkt übergeben und nicht aus programmierten Registern der Verknüpfung abrufen.
Wenn frank das schon nicht hinbekommt...
edit: Typo im Code
Zitat von: CQuadrat am 04 März 2021, 16:13:36
Ich erkenne am HM-Aktor vier LED-Blink-Moden:
es sind sogar 6 blink modes.
alle 4 timer der statemachine lassen die led unterschiedlich blinken, wenn der jeweilige timer eine
endliche zeit hat.
unendliche zeiten gibt es nur für die timer on/off, was die led dauerhaft an/aus schaltet.
on-timer => lang, lang, ...
offDly-timer => lang, kurz, längere pause, ...
off-timer => kurz, kurz, ...
onDly-timer => kurz, lang, längere pause, ...
da dein off-for-timer durch den onDly-timer realisiert ist, blinkt sie "kurz, lang".
in meinem off-for-timer template habe ich den off-timer genutzt, da blinkt sie dann "kurz, kurz".
Zitat von: CQuadrat am 04 März 2021, 15:20:55
Diese Aussage würde ich so nicht unterschreiben: ein off-for-timer kann durchaus Sinn ergeben; Beispiel: Totmannschalter (normal aus, aber an, wenn nicht mehr normal).
Ich meinte nicht die Sicht des Anwenders - sondern die des Herstellers ;) damals beim Grundlagendesign
Außerdem kann der, der sowas will doch mittlerweile auch einen Aktor mit Umschalter kaufen? Da wird ja durch den Kontakt aus on-for ein off-for :)
Aber ich sehe, ihr sprüht vor Ideen :)
Zitat von: frank am 04 März 2021, 12:24:04
eq3 beschreibt die unrechnung der onTime im xml file so:
<parameter id="ON_TIME" operations="write" control="NONE">
<logical type="float" min="0.0" max="85825945.6" default="0.0" unit="s" />
<physical type="integer" interface="store" id="ON_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>
cul_hm setzt das so um:
sub CUL_HM_encodeTime16($) {####################
my $v = shift;
return "0000" if($v !~ m/^[+-]?\d+(\.\d+)?$/ || $v < 0.05);
my $ret = "FFFF";
my $mul = 10;
for(my $i = 0; $i < 32; $i++) {
if($v*$mul < 0x7ff) {
$ret=sprintf("%04X", ((($v*$mul)<<5)+$i));
last;
}
$mul /= 2;
}
return ($ret);
}
nun sollte alles klar sein.
Ich werde 4 Tage brauchen um das zu durchdringen ... LOL
Edit: ging dann doch etwas schneller. HM also nur 1 bit besser als FS20 mit 512 Werten. Werde das die Tage mal in einen Wikiartikel giessen oder irgendwo ergänzen.