neue Features: checkall: timer|event|all, timertrigger, timerintervall

[Damian]

Die neuen Features des DOIF ...

Welches Features genau meinst du denn?

[Ellert]

ja, wenn es FHEM-Ebene sein soll, dann wäre eine Lösung interessant, die intuitiv funktioniert ohne in der Commandref jedes mal nachzuschlagen. Ich würde einfach die bisherige Syntax erweitern:

[device:reading]++
[device:reading]--

[device:reading]=irgendeine Rechnung mit Readingangaben in DOIF-Syntax in eckigen Klammern

evtl. noch
[device:reading]+=...
[device:reading]-=...
[device:reading]*=...
[device:reading]/=...

Die Frage stellt sich dann nur noch: Was funktioniert dann nicht mehr, was bisher noch lief

Edit:

Und wenn man schon dabei ist, dann könnte man auch gleich das set Kommando für Stati realisieren:

[Device]=...

Ja, das wäre ein großer Wurf, ich wollte eigentlich nur kurz und bündig einen Zähler erhöhen und ggf. auf 0 setzen. Den Umfang und Aufwand, den wir jetzt besprechen halte ich für zu groß, um eine schon funktionierende Methode (setreading name reading {(...)} zu ersetzen.

Es gibt allerdings noch eine Fragestellung im Zusammenhang mit der Beschriftung und Darstellung der Readings, s. https://forum.fhem.de/index.php/topic,63375.msg546664.html#msg546664

Man könnte die Definition einer ReadingsGroup über einen Get-Befehl zur Verfügung stellen, das wäre dann schon eine Basis fürs Frontend, wie es aussieht, habe ich angehängt.

Wäre das wünschenswert?

[Damian]

Ja, das wäre ein großer Wurf, ich wollte eigentlich nur kurz und bündig einen Zähler erhöhen und ggf. auf 0 setzen. Den Umfang und Aufwand, den wir jetzt besprechen halte ich für zu groß, um eine schon funktionierende Methode (setreading name reading {(...)} zu ersetzen.

Daher, lass uns etwas Zeit, bis wir eine einheitliche Lösung finden, bevor mehrere Lösungen das Gleiche leisten.

Es gibt allerdings noch eine Fragestellung im Zusammenhang mit der Beschriftung und Darstellung der Readings, s. https://forum.fhem.de/index.php/topic,63375.msg546664.html#msg546664

Man könnte die Definition einer ReadingsGroup über einen Get-Befehl zur Verfügung stellen, das wäre dann schon eine Basis fürs Frontend, wie es aussieht, habe ich angehängt.

Wäre das wünschenswert?

Die Frage ist, ob man alles in dieses eine Modul packt (es muss ja schließlich geladen werden), wenn man es auch im Wiki erklären kann, gerade wenn die Funktionalität außerhalb des Moduls ist und der User ohnehin Hand anlegen muss (auch wenn es für ihn einfacher wäre). Ich würde die Sachen lieber trennen.

[Garbsen]

Hallo

Wie löse ich folgende Aufgabe:

Ich habe in einem DOIF vier readings (Modus,SollAktuell,Tag,Nacht), immer wenn sich ein Reading ändert, soll an ein anderes Device ein set Befehl gegeben werden und zwar genau für das identische Reading und mit dem geänderten Wert.

Derzeit habe ich folgendes definiert:

Code Auswählen Erweitern

##CMD1
(["$SELF:.*"])


({fhem ("set FBSetBad Modus ".[$SELF:Modus])})
({fhem ("set FBSetBad SollAktuell ".[$SELF:SollAktuell])})
({fhem ("set FBSetBad Nacht ".[$SELF:Nacht])})
({fhem ("set FBSetBad Tag ".[$SELF:Tag])})


Das führt aber dazu, dass immer für alle vier readings der set befehlt ausgeführt wird. Das ist nicht erwünscht. Es soll beim FBSetBad immer nur das Reading neu gesetzt werden, dass sich im DOIF geändert hat.
Beim FBSetBad handelt es sich um ein httpmod, dass dann die Fußbodenheizung befüllt. Das lässt sich daher nicht direkt im DOIF abbilden.

Klar ich könnte im DOIF für jedes Reading ein eigenen DOELSEIF Zweig anlegen, finde das anders aber eigentlich schlanker, wenn es denn geht.
Ich habe bereits mit $EVTPART "gespielt" bekomme es ber nicht hin
Danke
K-H

[Ellert]

Daher, lass uns etwas Zeit, bis wir eine einheitliche Lösung finden, bevor mehrere Lösungen das Gleiche leisten.

Die Frage ist, ob man alles in dieses eine Modul packt (es muss ja schließlich geladen werden), wenn man es auch im Wiki erklären kann, gerade wenn die Funktionalität außerhalb des Moduls ist und der User ohnehin Hand anlegen muss (auch wenn es für ihn einfacher wäre). Ich würde die Sachen lieber trennen.

Ja, die Lösung sollte reifen.

Die set-Befehle tragen nicht erheblich zur Funktionalität bei, das könnte vielleicht als Tools ins Wiki, mal sehen.

[Per]

Mit do always würde es auch gehen

Code Auswählen Erweitern

di DOIF ([18:30])
  (
  IF ([mydummy] eq "1") (set bla 1),
  IF ([mydummy] eq "2") (set bla 2),
  IF ([mydummy] eq "3") (set bla 3)
  )
attr di do always

Aber cmdState würde an dieser Aufgabe scheitern

Ich habe auch eine Menge Dummys eingespart und damit es in der Statistik:List of total used modules (with definitions)... sichtbar wird führe ich nach größeren Änderungen

Code Auswählen Erweitern

fheminfo send

aus.

Problem: je besser ich DOIF verstehe und je mächtiger es wird, umso weniger wird es genutzt. Zumindest lt. Statistik, weil ich statt 4 nur noch 3 DOIF-Konstrukte brauche .

Wie löse ich folgende Aufgabe:

Sollte diese Frage wirklich HIER erscheinen?

Ich habe bereits mit $EVTPART "gespielt" bekomme es ber nicht hin

Sicher, dass es im DOIF $EVTPART gibt?!

[Garbsen]

Sollte diese Frage wirklich HIER erscheinen?
Sicher, dass es im DOIF $EVTPART gibt?!

Nun, ich habe es hier veröffentlicht, weil es ja um die neue Möglichkeit der readings im DOIF geht und wie ich dies für mich optimal nutze.
Ob es $EVTPART im DOIF gibt? Keine Ahnung, daher ja auch meine Frage
gibt es eine andere Möglichkeit für eine Lösung?

[Ellert]

@Damian: Mir ist aufgefallen, dass bei Zeiten mit Wochentagbeschränkung das Datum nicht mit dem voraussichtlich nächsten Triggerzeitpunkt übereinstimmt.

Soll das erstmal so bleiben? Wenn ja, würde ich das userReadings für den nextTimer mit ins Wiki aufnehmen.

[Damian]

@Damian: Mir ist aufgefallen, dass bei Zeiten mit Wochentagbeschränkung das Datum nicht mit dem voraussichtlich nächsten Triggerzeitpunkt übereinstimmt.

Soll das erstmal so bleiben? Wenn ja, würde ich das userReadings für den nextTimer mit ins Wiki aufnehmen.

Ja, das muss so bleiben, denn intern wird das Modul um diese Zeit geweckt, um zu prüfen, ob was zu tun ist. Bei indirekten Wochentagangaben könnte jemand kurz zuvor den Wochentag ändern und damit die Gültigkeit des Triggers verändern.

[Damian]

Version 0.3

Fehlerkorrektur: das Attribut initialize führte zum Initilialisieren des Moduls beim Neustart, obwohl das Attribut disable gesetzt war.

Dokuanpassung

[Ellert]

Anbei eine kleine optische Verbesserung (Basis V 0.3):

Das Eingabefeld für set disable,initialize,enable ist unnötig. Es kann mit disable:noArg initialize:noArg enable:noArg unterdrückt werden.

[Damian]

Anbei eine kleine optische Verbesserung (Basis V 0.3):

Das Eingabefeld für set disable,initialize,enable ist unnötig. Es kann mit disable:noArg initialize:noArg enable:noArg unterdrückt werden.

ich habe es übernommen, so dann testen wir noch bisschen, dann werde ich diese Version erst mal einchecken.

[Damian]

aktuelle Version wurde eingecheckt, sie ist ab morgen per Update verfügbar.

[Ellert]

Die neuen Möglichkeiten in den DOIF sind wirklich gut!
Frage: gibt es eine Möglichkwit die webCmd zu "beschriften"?
Derzeit werden mir in FHEM nur die jeweiligen Buttons Dropdowns oder knobs angezeigt, aber nicht welche readings damit gesteuert werden. Es wäre toll, wenn man da Beschriftungen zufügen könnte.
Geht das?
Danke

Die Widgets sollten mit dem morgigen Update den Readingnamen als Tooltip anzeigen, siehe https://forum.fhem.de/index.php/topic,70007.0.html

[oli_bru]

Hallo zusammen,

auf der Suche nach einer Lösung für mein gepostetes Problem (https://forum.fhem.de/index.php/topic,88278.0.html) bin ich auch über diesen Thread "gestolpert".
Dabei hat mich Ellert auf die falsche Fährte gelockt - daher möchte ich diese Erkenntnis gerne kund tun.

Weiter oben hatte Ellert gepostet:

Mit do always würde es auch gehen

Das ist aus meiner Sicht so aber nicht korrekt. Ich habe jetzt mal mit dummys und doifs rumgespielt:
Ein do always prüft immer nur die Bedingungen, welche auch die entsprechenden Events enthalten.
Ein checkall hingegen prüft alle Bedingungen, auch wenn für die in der Prüfung enthaltenen Elemente keine Events ausgelöst wurden.

Beispiel:

Code Auswählen Erweitern

([d_dummytest1] eq "on" and [d_dummytest2] eq "on") ({Log 1,"Test 1"}) DOELSEIF ([d_dummytest2] eq "on") ({Log 1,"Test 2"}) DOELSE ({Log 1, "Test 3"})

Zunächst setze ich dummytest1 und dummytest auf "on" -> ich lande im cmd_1

bei do_always:
ich setze d_dummytest1 auf "off" -> ich lande im cmd_3

bei check all:
ich setze d_dummytest1 auf "off" -> ich lande im cmd_2