on-for-timer

[justme1968]

nein. wenn es nicht implementiert ist und keine setextenstion verwendet werden funktioniert es auch nicht.

[CQuadrat]

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?

[Otto123]

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.

[CQuadrat]

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.

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).

[frank]

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:

Code Auswählen Erweitern

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 02010000000C80

Muss sicher "bloß" mal einer konstruieren.

hier mal ein template für short oder long:

Code Auswählen Erweitern

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

[Pfriemler]

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

[CQuadrat]

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:

Code Auswählen Erweitern


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".

[Pfriemler]

Bei mir so (nur Auszüge, ohne generelle Einrichtung der Geräte):

Code Auswählen Erweitern


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

[frank]

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".

[Otto123]

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

[Zrrronggg!]

eq3 beschreibt die unrechnung der onTime im xml file so:

Code Auswählen Erweitern

      <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:

Code Auswählen Erweitern

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.