on-for-timer

Begonnen von Zrrronggg!, 03 März 2021, 20:23:40

Vorheriges Thema - Nächstes Thema

Zrrronggg!

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?
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

betateilchen

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
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Otto123

zu 2: meine olle Schaltdose zeigt in der regList    3: lgOnTime         | 0.0 to 111600s     | required | on time special:unused
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Otto123

@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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Zrrronggg!

#5
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.
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

Zrrronggg!

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.
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

Otto123

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.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

off-for-timer sollte auch mit der statemachine möglich sein, denke ich.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Zrrronggg!

#9
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.

FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

Zrrronggg!

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.
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

Otto123

Ich würde denken, dass ist Modul abhängig. Habe ich bei Homematic noch nicht beobachtet.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

frank

#13
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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CQuadrat

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?
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue