Hauptmenü

Ankündigung: Intervall-Timer

Begonnen von Damian, 21 April 2018, 21:42:17

Vorheriges Thema - Nächstes Thema

Damian

Ich plane sogenannte Intervall-Timer zu realisieren:

Die Syntax

[<beginn>-<ende>,<relativer Timer>]

Beispiel:

[10:00-12:00,+00:01]

Zwischen 10 und 12 Uhr wird im Minutentakt getriggert.

Der relative Timer wird mit Beginn gestartet und endet mit Ende des Zeitintervalls. Es ist nicht das Gleiche, wie [10:00-12:00] and [+00:01] , denn hier wird auch außerhalb des Zeitintervalls getriggert.

Natürlich sollen ebenso indirekte Timer oder auch Timer-Funktionen oder Zeitberechnungen kombinierbar mit Wochentagen möglich sein.

z. B.

[{sunrise()}-[ende:state],+(rand(300)+100)|Sa So]

Edit: aktuelle Version wurde eingecheckt
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Ich wüsste schon ein paar Anwendungen dafür.

Damian

Zitat von: Ellert am 04 Mai 2018, 08:56:10
Ich wüsste schon ein paar Anwendungen dafür.

ja, man könnte damit elegant bestimme Probleme lösen, ohne dass dauerhaft getriggert wird. Ich muss jetzt nur noch dazu kommen es umzusetzen :)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

#3
Version v0.1 im ersten Post angehängt.

Es sollten alle genannten Features funktionieren. Z. Zt. kann man noch unsinnige Angaben machen (Intervalle mit einer Intervallgrenze, absolute Intervalltimer, ...), das werde ich in der nächsten Version abfangen.

Intervalltimer dürfen nicht mit Fragezeichen beginnen.

Wenn sich der Definitionszeitpunkt innerhalb eines Zeitintervall befindet, wird zum Definitionszeitpunkt der Intervalltimer gesetzt:

Bsp. 1 Um 20:01:05 Uhr wird definiert:

DOIF ([19:00-21:00,+00:01])


so lauten die nächsten Trigger 20:02:05, 20:03:05...20:59:05 und um 21:00 für cmd_2, am nächsten Tag dann: 19:00, 19:01,...20:59 und 21:00 für cmd_2

Bsp. 2 Um 20:01:05 Uhr wird definiert:

DOIF ([19:00-21:00,+:01])


so lauten die nächsten Trigger 20:02:00, 20:03:00...20:59:00 und um 21:00 für cmd_2, am nächsten Tag dann: 19:00, 19:01,...20:59 und 21:00 für cmd_2


Indirekte Timer funktionieren ebenfalls, sogar mit sofortiger Auswertung der Intervallgrenzen bei Änderung:

Bsp. 3 Um 20:01:05 Uhr wird definiert:

set begin 20:30
set end 21:00


DOIF ([[begin]-[end],+:01])


kein Timer triggert, da 20:30 Uhr noch nicht erreicht, die ersten Trigger wären um 20:30, 20:31, ...

mit

set begin 20:00

beginnt der Timer zu triggern um 20:02, 20:03, ...

ebenso kann man vorzeitig Intervalltimer beenden, indem man die Intervallgrenze verschiebt.

z. B. mit
set end 20:01


Anmerkung: Intervalltimer triggern nie außerhalb des Zeitintervalls inkl. Wochentagauswertung



Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Wenn ich richtig verstanden habe, würde ich

bisher
([?05:00-22:00] and ([:07] or [:27] or [:47]))

durch neu ersetzen können
([05:07-22:00;+:20])

Damian

#5
Zitat von: Ellert am 06 Mai 2018, 19:40:50
Wenn ich richtig verstanden habe, würde ich

bisher
([?05:00-22:00] and ([:07] or [:27] or [:47]))

durch neu ersetzen können
([05:07-22:00;+:20])

ja, mit dem Nebeneffekt, dass nach 22:00 Uhr bis 05:00 Uhr kein Timer mehr gesetzt wird und das DOIF-Modul außerhalb des Zeitintervalls nicht getriggert wird :)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Mit Version 0.1 nach Neustart gibt es beim Anlegen folgender Definition
define IntervallTimer DOIF ([05:07-22:00;+:20])
die Fehlermeldung
ZitatIntervallTimer DOIF: no right bracket: ([05:07-22:00
Unknown command +:20]), try help.

Das Semikolon scheint Probleme zu machen.

Damian

#7
Zitat von: Ellert am 06 Mai 2018, 23:46:33
Mit Version 0.1 nach Neustart gibt es beim Anlegen folgender Definition
define IntervallTimer DOIF ([05:07-22:00;+:20])
die Fehlermeldung
Das Semikolon scheint Probleme zu machen.

In der Kommandozeile musst du es doppeln -> bekannte FHEM-Problematik

Man könnte auch anderes Trennzeichen definieren, allerdings sind  | (Trennzeichen für Wochentage) und , (Trennzeichen für Default-Werte) schon vergeben.

Edit: Ich habe Version v0.2 mit Komma im ersten Post angehängt, da das Komma bei Zeitintervallen nicht für Default-Werte benutzt wird, kann man es an dieser Stelle als Trennzeichen nutzen

z. B.

DOIF ([[beginn,"09:00"]-[end],+:20])
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Version v0.3 im ersten Post mit genauerer Syntaxprüfung und Doku - eincheckbereit.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Zitat von: Damian am 07 Mai 2018, 23:11:37
Version v0.3 im ersten Post mit genauerer Syntaxprüfung und Doku - eincheckbereit.

Ich habe startup und Intervall-Timer in der Kurzreferenz von V 0.3 ergänzt , commandref_join.pl liefert keine Fehler.

Damian

Zitat von: Ellert am 08 Mai 2018, 11:42:58
Ich habe startup und Intervall-Timer in der Kurzreferenz von V 0.3 ergänzt , commandref_join.pl liefert keine Fehler.

ok, dann noch mal gut testen. Diese Version hat bereits CheckReadingEvent 1 intern voreingestellt. Das muss ich in der Doku noch berücksichtigen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Beide DOIF wurde ausserhalb des Zeitintervalls definiert

Die Syntax
([14:07-16:00,+:20]) {Log 1, "Intervall_1"}
liefert
Zitat
2018.05.08 14:07:00.016 1: Intervall_1
2018.05.08 14:20:00.017 1: Intervall_1
2018.05.08 14:40:00.017 1: Intervall_1
2018.05.08 15:00:00.017 1: Intervall_1

auf die volle Stunde ausgerichtete Triggerzeitpunkte,


Diese Syntax
([12:07-14:00,+00:20]) {Log 1, "Intervall_2"}
liefert
Zitat
2018.05.08 12:07:00.016 1: Intervall_2
2018.05.08 12:27:00.016 1: Intervall_2
2018.05.08 12:47:00.017 1: Intervall_2
2018.05.08 13:07:00.016 1: Intervall_2
2018.05.08 13:27:00.016 1: Intervall_2
2018.05.08 13:47:00.016 1: Intervall_2

auf den Startzeitpunkt ausgerichtete Triggerzeitpunkte.

Das ging aus den Angaben im ersten Beitrag nicht so deutlich hervor. Gut, dass es beide Varianten gibt.

Ellert

#12
Abhängig vom Definitionszeitpunkt vor dem Zeitintervall wird der Timer unterschiedlich gesetzt.

Zitat
Internals:
   DEF        ([16:07-18:00,+00:20]) {Log 1, "Intervall_3"}
   MODEL      FHEM
   NAME       IntervallTimer2
   NR         166
   NTFY_ORDER 50-IntervallTimer2
   STATE      initialized
   TYPE       DOIF
   READINGS:
     2018-05-08 15:57:15   cmd             0
     2018-05-08 15:57:15   mode            enabled
     2018-05-08 15:57:15   state           initialized
     2018-05-08 15:57:15   timer_01_c01    08.05.2018 16:07:00
     2018-05-08 15:57:15   timer_02_c01    08.05.2018 18:00:00
     2018-05-08 15:57:15   timer_03_c01    08.05.2018 16:17:15
hier ist der Bezugspunkt der Definitionszeitpunkt

Zitat
   Internals:
   DEF        ([16:27-18:00,+00:20]) {Log 1, "Intervall_3"}
   MODEL      FHEM
   NAME       IntervallTimer2
   NR         166
   NTFY_ORDER 50-IntervallTimer2
   STATE      initialized
   TYPE       DOIF
   READINGS:
     2018-05-08 16:02:53   cmd             0
     2018-05-08 16:02:53   mode            enabled
     2018-05-08 16:02:53   state           initialized
     2018-05-08 16:02:53   timer_01_c01    08.05.2018 16:27:00
     2018-05-08 16:02:53   timer_02_c01    08.05.2018 18:00:00
     Timer 03 wird noch nicht gesetzt
und hier wird Timer 03 zum Definitionszeitpunk nicht berechnet, sondern erst beim Intervallbeginn.

Durch dieses unterschiedliche Verhalten wird die Ausrichtung der Triggerpunkte nicht immer gleich gesetzt.

Würde sich die Ausrichtung  der Triggerpunkte bei Neustart ändern?
Ja, habe ich gerade probiert.

Damian

#13
Dann ist da noch ein Bug drin, denn vor dem Intervallbeginn darf noch kein Intervalltimer gesetzt werden.

Edit: Auf der anderen Seite landet der errechnete Intervalltimer zum Zeitpunkt der Definition im Zeitintervall, daher ist es gar nicht so falsch, zumal der Intervalltimer ohnehin bei nicht ausgerichteten Timern, wenn sie innerhalb des Zeitintervalls definiert werden, sich nicht am Intervallbeginn orientiert, sondern am Definitionszeitpunkt
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Version v0.4 im ersten Post. Jetzt werden grundsätzlich keine Intervalltimer gesetzt, wenn der Definitionszeitpunkt außerhalb des Zeitintervalls liegt.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Mein Ziel ist es von 06:00-22:00 jeweils um HH:07, HH:27 und HH:47 zu triggern.

Wenn ich jetzt im Intervall definiere
([06:07-22:00,+00:20]) {Log 1, "Intervall_3"}

dann bezieht sich der relative Timer auf den Definitionszeitpunkt. Ab morgen 06:07 wird dann so getriggert wie ich es vorhabe.

Auch bei jedem FHEM-Neustart im Intervall wird bis zum Ende des Intervalls, ab dem Initialisierungszeitpunkt alle 20 Minuten getriggert.

Habe ich das so richtig verstanden?

Damian

Zitat von: Ellert am 08 Mai 2018, 19:31:25
Mein Ziel ist es von 06:00-22:00 jeweils um HH:07, HH:27 und HH:47 zu triggern.

Wenn ich jetzt im Intervall definiere
([06:07-22:00,+00:20]) {Log 1, "Intervall_3"}

dann bezieht sich der relative Timer auf den Definitionszeitpunkt. Ab morgen 06:07 wird dann so getriggert wie ich es vorhabe.

Auch bei jedem FHEM-Neustart im Intervall wird bis zum Ende des Intervalls, ab dem Initialisierungszeitpunkt alle 20 Minuten getriggert.

Habe ich das so richtig verstanden?

So ist es. Besser ist natürlich ausgerichtete Timer zu verwenden, denn diese sind immer gleich.





Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

FunkOdyssey

Damit ihr nicht denkt, dass ihr immer alleine seid; ich bin - wie immer - total begeistert von den ständigen neuen Features. Danke.

Damian

#18
Bis vor kurzen ging als Zeitberechnung auch [([+:20]+[00:07])] für HH:07, HH:27, HH:47

Das ließe sich auch als Intervalltimer angeben. Leider wird seit der letzten Version diese Zeitberechnung nicht als relativer Timer erkannt (fehlendes Plus-Zeichen am Anfang), daher wird nur noch einmal am Tag geschaltet.

Edit: Ich sehe, dass diese Regelung (ein mal pro Tag schalten) beim Intervalltimer nicht aktiv ist, daher könnte auch funktionieren:

([06:07-22:00,([+:20]+[00:07])])


Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Zitat von: Damian am 08 Mai 2018, 20:18:31
Bis vor kurzen ging als Zeitberechnung auch [([+:20]+[00:07])] für HH:07, HH:27, HH:47

Das ließe sich auch als Intervalltimer angeben. Leider wird seit der letzten Version diese Zeitberechnung nicht als relativer Timer erkannt (fehlendes Plus-Zeichen am Anfang), daher wird nur noch einmal am Tag geschaltet.

Dann bleibt also nur diese Lösung?
([?05:00-22:00] and ([:07] or [:27] or [:47]))

Damian

Zitat von: Ellert am 08 Mai 2018, 20:28:45
Dann bleibt also nur diese Lösung?
([?05:00-22:00] and ([:07] or [:27] or [:47]))

Wie gerade festgestellt, vermutlich auch diese:

([06:07-22:00,([+:20]+[00:07])])

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Zitat von: Damian am 08 Mai 2018, 20:37:03
Wie gerade festgestellt, vermutlich auch diese:

([06:07-22:00,([+:20]+[00:07])])

Wie gerade getestet: es funktioniert tatsächlich :)

Das Modul macht inzwischen mehr, als ich mir ausgedacht habe. Sind wir schon bei KI? :)

Nicht, dass wir nicht genügend Alternativen hätten ;)

([06:00-22:00,+:20])

mit wait 7 Minuten verzögern
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

#22
Version v.05. Ich musste noch etwas nachhelfen. Jetzt funktionieren wieder grundsätzlich ausgerichtete Timer mit Berechnung (insbesondere mit Zeitverschiebung)

z. B.

Fünfzehn Sekunden nach einer vollen Minute

[([+:01]+[00:00:15])]

Wer so etwas braucht.  :D
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Zitat von: Damian am 08 Mai 2018, 23:33:59
Version v.05. Ich musste noch etwas nachhelfen. Jetzt funktionieren wieder grundsätzlich ausgerichtete Timer mit Berechnung (insbesondere mit Zeitverschiebung)

z. B.

Fünfzehn Sekunden nach einer vollen Minute

[([+:01]+[00:00:15])]

Wer so etwas braucht.  :D

([06:07-22:00,([+:20]+[00:07])])
Startet mit dem korrekten Timer.
Auf die Idee, den relativen Timer so zu berechnen wäre ich vermutlich nicht gekommen, danke für den Tip.

Es gibt Warnungen mit V0.5 beim Neustart
Zitat
2018.05.09 07:34:29.764 1: PERL WARNING: "my" variable $time masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 1571, <$fh> line 192.
2018.05.09 07:34:29.982 1: PERL WARNING: "my" variable $wday masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 2679, <$fh> line 192.
2018.05.09 07:34:29.984 1: PERL WARNING: "my" variable $hms masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 2680, <$fh> line 192.

Damian

Zitat von: Ellert am 09 Mai 2018, 07:58:34
([06:07-22:00,([+:20]+[00:07])])
Startet mit dem korrekten Timer.
Auf die Idee, den relativen Timer so zu berechnen wäre ich vermutlich nicht gekommen, danke für den Tip.

Es gibt Warnungen mit V0.5 beim Neustart
Dass Berechnungen mit ausgerichteten Timern funktionieren, war mehr oder weniger Zufall. Ich käme nicht auf die Idee, dass HH:07, HH:27, HH:47 für jemanden wichtig sein kann. Ich hätte gedacht, dass HH:00, HH:20 und HH:40 ausreichend wäre.

Mit v0.05 funktionieren zumindest jetzt auch Berechnungen mit ausgerichteten Timern, damit kann man sicherlich auch Unsinn berechnen.

Die Warnungen baue ich noch aus.

Übrigens, man kann auch mit Sekunden rechnen

[([+:20]+[00:07])] entspricht [([+:20]+420)]

oder wie wäre es mit "ausgerichtetem Zufall":

[([+:20]+rand(120))]
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

#25
Zitat von: Damian am 09 Mai 2018, 09:44:59
Ich käme nicht auf die Idee, dass HH:07, HH:27, HH:47 für jemanden wichtig sein kann.
Ich hole mir Daten von einer in der Nähe liegenden Wetterstation, die alle 20 min aktualisiert, als ich das eingebaut habe lagen die optimale Zeitpunkte zum Abholen der Daten bei HH:07, HH:27, HH:47  und nachts benötige ich die Daten nicht.

Damian

Zitat von: Ellert am 09 Mai 2018, 13:21:10
Ich hole mir Daten von einer in der Nähe liegenden Wetterstation, die alle 20 min aktualisiert, als ich das eingebaut habe lagen die optimale Zeitpunkte zum Abholen der Daten bei HH:07, HH:27, HH:47  und nachts benötige ich die Daten nicht.
Klar, irgendwie so etwas habe ich mir schon gedacht.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Bereinigte Version v.06 im ersten Post.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Ich habe im Wiki einen Hinweis zu dem zukünftig geänderten checkReadingEvent eingefügt https://wiki.fhem.de/wiki/DOIF

Damian

#29
OK, ich werde noch die Doku dazu anpassen.

Edit: Die Beschreibung zu checkReadingEvent lautet jetzt:

Readingauswertung bei jedem Event des Devices   

Bei Angaben der Art [<Device>:<Reading>] wird das Modul getriggert, wenn ein Ereignis zum angegebenen Device und Reading kommt. Soll das Modul, wie bei Statusangaben der Art [<Device>], auf alle Ereignisse des Devices reagieren, so muss das Attribut auf Null gesetzt werden.

Bemerkung: In früheren Versionen des Moduls, war checkReadingEvent 0 per default intern voreingestellt gewesen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Aktuelle Version wurde eingecheckt.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

2Meterpdm

Abend Leute,

Was müsste ich denn jetzt eigentlich am unten kopierten DOIF ändern damit es mit der neuen Version klappt ohne das attr checkE... 0?Vielen Dank schon mal im vorraus.

Code:
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "off" and [Sz.Rollo.Garage:working] eq "off")(set Sz.Rollo.* down)
DOELSEIF
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "on" and [Sz.Rollo.Garage:working] eq "on")(set Sz.Rollo.* stop)
DOELSEIF
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "on" and [Sz.Rollo.Garage:working] eq "off")(set Sz.Rollo.* stop)
DOELSEIF 
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "off" and [Sz.Rollo.Garage:working] eq "on")(set Sz.Rollo.* stop)

Damian

Zitat von: 2Meterpdm am 17 Mai 2018, 00:57:47
Abend Leute,

Was müsste ich denn jetzt eigentlich am unten kopierten DOIF ändern damit es mit der neuen Version klappt ohne das attr checkE... 0?Vielen Dank schon mal im vorraus.

Code:
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "off" and [Sz.Rollo.Garage:working] eq "off")(set Sz.Rollo.* down)
DOELSEIF
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "on" and [Sz.Rollo.Garage:working] eq "on")(set Sz.Rollo.* stop)
DOELSEIF
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "on" and [Sz.Rollo.Garage:working] eq "off")(set Sz.Rollo.* stop)
DOELSEIF 
([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "off" and [Sz.Rollo.Garage:working] eq "on")(set Sz.Rollo.* stop)

Gar nichts. Ich habe gerade die aktuelle Version gefixt. Ich werde sie heute noch einchecken, wenn ich sie ausreichend getestet habe.

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Per

Zitat von: 2Meterpdm am 17 Mai 2018, 00:57:47Was müsste ich denn jetzt eigentlich am unten kopierten DOIF ändern
Außer den Code-Tags
  • könntest du noch folgende Änderung reinbringen:
    ([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "off" and [Sz.Rollo.Garage:working] eq "off")(set Sz.Rollo.* down)
    DOELSEIF
    ([Sz.Taste5:"^press_short:..*$"] and ([Sz.Rollo.Front:working] eq "on" or [Sz.Rollo.Garage:working] eq "on"))(set Sz.Rollo.* stop)

    zumindest, falls du die verschiedenen Cases nicht weiter behandelst.
    Hat aber nix mit der neuen Version zu tun, nur mit DOIF/Perl/Logik im allgemeinen.
    Gibt es bei den beiden Readings working nur on und off, kannst du den zweiten Case sogar zu
    ([Sz.Taste5:"^press_short:..*$"] and [Sz.Rollo.Front:working] eq "off" and [Sz.Rollo.Garage:working] eq "off")(set Sz.Rollo.* down)
    DOELSEIF
    ([Sz.Taste5:"^press_short:..*$"])(set Sz.Rollo.* stop)

    verkürzen, weil der 2xoff-Fall eh schon abgearbeitet ist.

2meter_pdm

Danke für die Tipps!Alles umgesetzt.

Laser

#36
Funktioniert denn nun der Intervall-Timer wie in der Referenz beschrieben oder nicht? Wo kann man lesen, wie es funktioniert?
Zitat aus Referenz:
Anwendungsbeispiel: Zwischen 08:00 und 22:00 Uhr soll eine Pumpe jede halbe Stunde für fünf Minuten eingeschaltet werden:
Perl-Modus:
define di_pump DOIF {[08:00-22:00,+:30];fhem_set"pump on-for-timer 300"}

Habe Lamp1 statt pump. Bei mir schaltet nichts (Dummy-Lamp1 -Symbol ändert sich, aber die Lamp1 schaltet nicht ein.
on-one-for-timer funktioniert bei mir nicht, nur on ist OK.

Ellert

Zitat von: Laser am 15 September 2020, 15:23:24
Funktioniert denn nun der Intervall-Timer wie in der Referenz beschrieben oder nicht? Wo kann man lesen, wie es funktioniert?
Zitat aus Referenz:
Anwendungsbeispiel: Zwischen 08:00 und 22:00 Uhr soll eine Pumpe jede halbe Stunde für fünf Minuten eingeschaltet werden:
Perl-Modus:
define di_pump DOIF {[08:00-22:00,+:30];fhem_set"pump on-for-timer 300"}

Habe Lamp1 statt pump. Bei mir schaltet nichts (Dummy-Lamp1 -Symbol ändert sich, aber die Lamp1 schaltet nicht ein.
on-one-for-timer funktioniert bei mir nicht, nur on ist OK.

Du musst den on-for-timer erst einschalten mit useSetExtensions, siehe https://commandref.fhem.de/commandref_DE.html#setExtensions

Laser

#38
Danke für den Tipp!
Wie die Syntax für das Anlegen ist, wird natürlich erst mal nicht beschrieben. Ein popeliges Beispiel ohne viel Klimbim drumherum mit 100000 Möglichkeiten im Wiki oder in der Dev Specific help würde die Sache brauchbar machen. Ich bin neu hier. Ist es evtl. gar nicht gewollt, dass die breite Masse dieses System verwendet?
Natürlich ist es arbeitsintensiv, etwas zu beschreiben.

Damian

#39
Zitat von: Laser am 16 September 2020, 10:22:02
Danke für den Tipp!
Wie die Syntax für das Anlegen ist, wird natürlich erst mal nicht beschrieben. Ein popeliges Beispiel ohne viel Klimbim drumherum mit 100000 Möglichkeiten im Wiki oder in der Dev Specific help würde die Sache brauchbar machen. Ich bin neu hier. Ist es evtl. gar nicht gewollt, dass die breite Masse dieses System verwendet?
Natürlich ist es arbeitsintensiv, etwas zu beschreiben. Aber statt immer neue undokumentierte Dinge zu kreieren, sollte man evtl. das vorhandene dokumentieren.

"pump" ist ein Device, welches on-for-timer unterstützt, da muss man nichts machen. Es steht nicht in der Doku, dass es ein Dummy ist.

Ansonsten gebe ich dir Recht, fhem ist nichts für "auf die Schnelle", eher ein System von Nerds für Nerds. Da hilft am Anfang nur viel fragen und lesen oder ansonsten ein "intuitiveres" System nehmen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Zitat von: Laser am 16 September 2020, 10:22:02
Danke für den Tipp!
Wie die Syntax für das Anlegen ist, wird natürlich erst mal nicht beschrieben. Ein popeliges Beispiel ohne viel Klimbim drumherum mit 100000 Möglichkeiten im Wiki oder in der Dev Specific help würde die Sache brauchbar machen. Ich bin neu hier. Ist es evtl. gar nicht gewollt, dass die breite Masse dieses System verwendet?
Natürlich ist es arbeitsintensiv, etwas zu beschreiben. Aber statt immer neue undokumentierte Dinge zu kreieren, sollte man evtl. das vorhandene dokumentieren.

Auszug aus: https://www.meintechblog.de/2015/07/rudolf-koenig-im-interview-der-erfinder-von-fhem-zum-thema-smart-home/
ZitatInsgesamt sehe ich ein großes Potenzial in Open-Source-Software, wenngleich FHEM eigentlich nicht für den "Massenmarkt" konzipiert wurde. Es setzt Programmierkenntnisse in Perl voraus und war eben genau auf meine damaligen Befürnisse als Programmierer hin ausgerichtet. So ist gerade auch der Einstieg für viele Anfänger schwierig, wobei ich es derzeitig auch nicht forciere, dass FHEM großartig wächst. Werbung machen wir keine, wir haben ja auch nichts davon.

Laser

#41
Hallo,
ich erwarte auch kein Plug and Play System.
Es macht mir auch nichts aus, tagelang ein Problem zu verfolgen...Möchte auch niemanden mit Anfänger- Fragen nerven. Werde schon noch in das System reinkommen.
übrigens: set on-for-timer funktioniert jetzt bei mir in Shelly-Switch! Danke nochmal für den Tip mit den useSet Extensions!

Laser

Jetzt, nach einiger Zeit mit FHEM, muß ich sagen, es steht schon sehr, sehr viel geschrieben. Der Einstieg ist aber etwas unübersichtlich. Aber man freut sich, wenn wieder etwas geht. In FHEM steckt ja sehr viel Entwicklungsarbeit.

Damian

Zitat von: Laser am 29 September 2020, 11:33:14
Jetzt, nach einiger Zeit mit FHEM, muß ich sagen, es steht schon sehr, sehr viel geschrieben. Der Einstieg ist aber etwas unübersichtlich. Aber man freut sich, wenn wieder etwas geht. In FHEM steckt ja sehr viel Entwicklungsarbeit.

So ist es, nach ein paar Jahren, weiß man die Vielfalt und dich Mächtigkeit des Systems und seiner Module zu schätzen. Man darf am Anfang nur nicht zu schnell aufgeben.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF