on-for-timer und $EVENT

[Matthias]

Hi,

wenn ich einen notify à la

define bla_notify notify device:on* {blub($NAME, $EVENT)}

definiere und mit on-for-timer 500 device schalte, dann bekomme ich als $EVENT immer "on" zurück. Wenn ich in device schaue, dann ist der State ebenfalls on. Kann man irgendwie an den eigentlichen on-for-timer Wert kommen?

Vielen Dank,
Matthias

[frank]

schau auf deinen eventmonitor. bei mir wird ein "on-for-timer" auch im status gemeldet:

Code Auswählen Erweitern

2016-05-08 12:28:36.794 CUL_HM SwitchUP01 set_on-for-timer 30
2016-05-08 12:28:37.434 CUL_HM SwitchUP01 deviceMsg: on (to ccu)
2016-05-08 12:28:37.434 CUL_HM SwitchUP01 level: 100
2016-05-08 12:28:37.434 CUL_HM SwitchUP01 pct: 100
2016-05-08 12:28:37.434 CUL_HM SwitchUP01 on
2016-05-08 12:28:37.434 CUL_HM SwitchUP01 timedOn: running
2016-05-08 12:29:10.509 CUL_HM SwitchUP01 deviceMsg: off (to broadcast)
2016-05-08 12:29:10.509 CUL_HM SwitchUP01 level: 0
2016-05-08 12:29:10.509 CUL_HM SwitchUP01 pct: 0
2016-05-08 12:29:10.509 CUL_HM SwitchUP01 off
2016-05-08 12:29:10.509 CUL_HM SwitchUP01 timedOn: off

was hast du genau vor?

[Matthias]

Hi Frank,

vielen Dank, daran hatte ich nicht gedacht. Ein notify auf set_on-for-timer macht genau das was ich möchte .

Matthias

[justme1968]

ob das on-for-timer in den events auftaucht hängt vom device ab.

bei FS20: ja, bei HM: nein, bei allem was über die SetExtensions geht: nein.

ich habe eben hier: https://forum.fhem.de/index.php/topic,53137.0.html einen patch vorgeschlagen mit dem man das vereinheitlichen könnte.

gruss
  andre

[martinp876]

das macht doch eigentlich keinen Sinn. Oder: es ist alles da - in der Summe besser als bei FS20, wenn ich es korrekt sehe.

Code Auswählen Erweitern

SwitchUP01 set_on-for-timer 30
SwitchUP01 on
SwitchUP01 timedOn: running
SwitchUP01 off
SwitchUP01 timedOn: off
du kannst auswerten welches Kommando gesendet wurde (falls du es vergessen hast )
timedOn zeigt dir, dass der Zustand  (welcher auch immer) nicht permanent ist. Der Aktor wird irgendwann umschalten. Das Gute: es ist egal ob du on-till, on-for-timer oder eine Programmierung der direkten peers nutzt.
Wenn du das als state haben willst kombiniere state und timedOn nach deinen Wünschen.

[justme1968]

bei hm ist fast alles da. aber wenn man das event verpasst sieht man die dauer nicht mehr.

bei fs20 sieht man die dauer garnicht wenn man eventMap verwendet.

bei allem devices die die SE verwenden sieht man überhaupt nichts.

wenn hm auch noch die dauer ablegen würde wenn sie bekannt ist (und auch zurück setzt) und das kompatibel zu den anderen devices macht wäre das schon sehr praktisch.

[martinp876]

dauer wäre cool. ist aber nicht.
ein event verpassen ist auch nicht erlaubt. Wenn das ein mögliches Fehlerszenarion kannst du einpacken.

Man könnte aus einem on-for-timer eine Zeit filtern. Aus on-till könnte man auch, muss man aber umrechnen. Aus press geht es schon nicht mehr, da muss man die Register lesen. Und die Statemachine nachbilden.

Da es also alles nur die halbe Wahrheit ist baue ich es nicht ein. Wer sich auf so etwas einlassen will kann es einfach aus dem Kommando extrahieren

[justme1968]

mit event war FHEM event gemeint. wenn man das Event nicht sieht und anschließend im device nachschaut hat man keine dauer. diese events zu verpassen ist erlaubt. fhem sollte die fauer auch dann kennen. wenn man aus fhem heraus geschaltet hat.

die ota funk signale zu verpassen geht natürlich nicht. aber hier gäbe es sowieso keine dauer.

auch bei hm kann man es übrigens nicht mehr direkt aus dem event auslesen wenn man eventMap verwendet wie es z.b. nötig ist wenn man on-for-timer in den webCmd verwendet.

das es bei hm nicht in allen fällen geht ist klar. es geht aber in den meisten oder zumindest sehr vielen fällen. schade das die auch unter den tisch fallen. zumal es ja nicht darum geht etwas falsches anzuzeigen sondern die dinge die bekannt sind. die dauer ist entweder bekannt und dann ist sie auch korrekt, oder sie ist es nicht dann bleibt nur zu zeigen das es eine unbekannte dauer ist. es ist also nicht die halbe wahreit sonder die volle bekannte Information.

[martinp876]

Code Auswählen Erweitern

2016-05-08 18:43:39.620 CUL_HM laLnge set_on-for-timer 5
ist ein Event. der kommt in FHEM. Warum sollte man den verpassen? da ist kein Unterschied zu ota.

die ota funk signale zu verpassen geht natürlich nicht. aber hier gäbe es sowieso keine dauer.

wie meinst du das? es wird keine Dauer gesendet - die ist programmiert im Aktor. Also ist es in on-for-timer.

auch bei hm kann man es übrigens nicht mehr direkt aus dem event auslesen wenn man eventMap verwendet wie es z.b. nötig ist wenn man on-for-timer in den webCmd verwendet.

wenn man die events verbiegt ist es weg - klar. dann sollte man es eben anders machen - kann man ja - user-readings o.ä.

das es bei hm nicht in allen fällen geht ist klar.

kommt daruf an, wie viel energie man rein steckt. Für den einfachUser sicher.

es geht aber in den meisten oder zumindest sehr vielen fällen

je nach User, bei mir nicht. Alle Bewedingsmelder reagieren direkt (ok, nicht wenn man es per notify macht)

wer will kann es auch so bauen. Wann man dann duration wieder löscht... muss man selbst wissen. Wenn es die Zeit bis zum abschalten anzeigen würde, das wäre eine Sache.
Übrigens kann HM auch eine Dauer angeben für "off".
Bei Dimmern könnte man nich die Rampe berücksichtigen - additiv oder separat? und die Down-rampe? Das Blinken?
da kann man wirklich viel anzeigen.

Vielleicht hilft das user-reading bereits

Code Auswählen Erweitern

attr laLnge userReadings duration { my $s = ReadingsVal("laLnge","state",0);;my $d = $s;;$d =~ s/set_on-for-timer //;; return ($s=~m/set_on/?$d:ReadingsVal("laLnge","duration",0))}

[justme1968]

das man es von hand mehr oder weniger gut nachbilden kann ist klar. es wäre aber schön wenn man das nicht für jeden device type unterschiedlich machen müsste.

im oben verlinkten thread ist ein vorschlag der das ganze für alle devices einbaut die die SetExtensions für on- und off-for-timer nutzen. FS20 wird vermutlich nachgezogen und die gleichen internals für die dauer bereit stellen.

wenn hm ebenfalls die gleichen internals bereitstellen würde könnte man auf user ebene alle devices gleich behandeln. und auch im nachhinein sehen welcher timer wann gestartet wurde.

manchmal ist eine einheitliche lösung die so gut wie möglich ist besser als eine perfekte die dann ausbleibt weil es doch nicht geht.

[martinp876]

ich habe einmal einen kurzen Blick nach setExtentions geworfen. du willst die Kommandos auswerten?
sportlich.
in HM gibt es viele Kommandos mit Timer-Möglichkeit, auch pct.

on-for-timer usw sind doch identisch.
Das ganze in Internals anzuzeigen - da ist m.E. bereits jetzt deutlich überfrachtet. Wenn rudi alles direkt sehen will ist das eine Entwickleransicht. schade für den User mit diesen Informationen belastet zu werden.
und was willst du jetzt genau? Hoffentlich soll ich nicht meine Internals weiter aufblasen