Ich habe mal einen Punkt meiner todo-Liste eben umgesetzt, bisher ohne Doku.
Es gibt jetzt das Attribut disablecondition. Damit kann man eine Bedingung definierten, die das Modul bei Erfüllung deaktiviert.
Bsp.
attr di_test disablecondition [mydisabledummy] eq "on"
Zeiteinschränkungen durch Angabe eines Zeitintervalls funktionieren z. Zt. nicht.
Gruß
Damian
Juchu. Ein Wunsch geht in Erfüllung. Danke dir.
Nachtrag: Ich probiere das morgen mal aus. Ich nehme an, dass hier das Triggern des Dummys das DOIF reagiert, oder?
Zitat von: FunkOdyssey am 19 Juli 2016, 21:31:39
Juchu. Ein Wunsch geht in Erfüllung. Danke dir.
Nachtrag: Ich probiere das morgen mal aus. Ich nehme an, dass hier das Triggern des Dummys das DOIF reagiert, oder?
Nein, es wird nur abgefragt. Diese Abfrage findet aber immer statt und wenn sie wahr ist, verhält sich das Modul wie im Modus disable - es macht einfach nichts, die Timer werden allerdings intern weiterhin aktualisiert, damit bleibt das Modul im Takt, falls die Bedingung wieder unwahr wird.
Gruß
Damian
So, ich habe ein wenig rumgespielt. Ich freue mich über das Feature - hätte aber noch ein paar Fragen:
- könnte man bei der Änderung eines Dummy das DOIF evtl. triggern und direkt disablen?
- geht vielleicht sogar echtes deaktivieren (analog Attribut disable), so dass das DOIF keine Ressourcen schluckt (auch wenn nur wenig)?
- Kann man das "disabled sein" zukünftig auch irgendwie erkennen? Die DOIF-Bedingung traf ein und die disablecondition war true. Jedoch konnte man nicht erkennen, ob das DOIF reagiert hat oder nicht. Es blieb einfach beim alten Zustand.
Das sind nur Wunschvorstellungen. Ich frage nur, ob das zukünftig möglich ist. Genieße lieber das gute Wetter. :-)
Zitat von: FunkOdyssey am 20 Juli 2016, 13:27:58
So, ich habe ein wenig rumgespielt. Ich freue mich über das Feature - hätte aber noch ein paar Fragen:
- könnte man bei der Änderung eines Dummy das DOIF evtl. triggern und direkt disablen?
- geht vielleicht sogar echtes deaktivieren (analog Attribut disable), so dass das DOIF keine Ressourcen schluckt (auch wenn nur wenig)?
- Kann man das "disabled sein" zukünftig auch irgendwie erkennen? Die DOIF-Bedingung traf ein und die disablecondition war true. Jedoch konnte man nicht erkennen, ob das DOIF reagiert hat oder nicht. Es blieb einfach beim alten Zustand.
Das sind nur Wunschvorstellungen. Ich frage nur, ob das zukünftig möglich ist. Genieße lieber das gute Wetter. :-)
Die Idee war, die Dummy-Abfragen in der Bedingung zum Deaktivieren des Moduls eleganter zu lösen und genau dafür war es die Lösung.
Beim kompletten Deaktivieren des Moduls würde das Modul sich anders verhalten, da alle Informationen insb. der Zustand des Moduls gelöscht wird.
Eine Information bei einer Verhinderung der Abarbeitung durch disablecondition könnte man irgendwo aufnehmen, es sollte aber nicht der Status sein, denn der wird oft als Zustand ausgewertet.
Über Performance-Einbußen würde ich mir keine Sorgen machen, wenn man allerdings ein Modul für ein halbes Jahr deaktivieren möchte, dann würde ich es tatsächlich über das disable-Attribut komplett abschalten.
Gruß
Damian
Ich habe die Beta-Version im ersten Post um ein weiteres Feature ergänzt:
https://forum.fhem.de/index.php/topic,56008.msg476113.html#msg476113
Gruß
Damian
Zitat von: Damian am 20 Juli 2016, 19:07:22
Die Idee war, die Dummy-Abfragen in der Bedingung zum Deaktivieren des Moduls eleganter zu lösen und genau dafür war es die Lösung.
Beim kompletten Deaktivieren des Moduls würde das Modul sich anders verhalten, da alle Informationen insb. der Zustand des Moduls gelöscht wird.
Eine Information bei einer Verhinderung der Abarbeitung durch disablecondition könnte man irgendwo aufnehmen, es sollte aber nicht der Status sein, denn der wird oft als Zustand ausgewertet.
Über Performance-Einbußen würde ich mir keine Sorgen machen, wenn man allerdings ein Modul für ein halbes Jahr deaktivieren möchte, dann würde ich es tatsächlich über das disable-Attribut komplett abschalten.
Damian, ich hatte nun ein wenig Zeit mit dem Feature herumzuspielen. Ich freue mich ja, dass du es eingebaut hast. Aber wenn du es NUR für mich eingebaut haben solltest, dann kannst du das gerne wieder entfernen. In der jetzigen Implementierung spare ich ja "nur" einen Dummy-Vergleich. Sonst ändert sich nichts. Außer, dass es nun wenig übersichtlich ist, da man nun auch noch die Attribute prüfen muss. Ich selbst deaktiviere meine DOIFs vollständig, wenn diese nicht benötigt werden. Sonst reagieren alle DOIFs auf viel zu viele Trigger. Wenn es schon nicht wegen der Performance ist und ich mir darüber keine Gedanken muss; dann aber wegen der schlechteren Nachvollziehbarkeit.
Ich habe einen Dummy, der - je nach Auswahl - verschiedene DOIFs aktiviert:
Modus der Tischleuchten- Dämmerung (di_tischleuchten1)
- Zufall-wenn-abwesend (di_tischleuchten2)
- Zufall-wenn-abwesend-und-dunkel (di_tischleuchten3)
- Zufall-wenn-scharf (di_tischleuchten3)
- Zufall-wenn-scharf-und-dunkel (di_tischleuchten4)
Unabhängig von den einzelnen DOIFs (di_tischleuchten1-5) habe ich folgendes DOIF anlegen müssen, welches die nicht benötigten DOIFs deaktiviert:
## cmd1
(
[du_mode_tischleuchten] eq "Aus"
)
(
attr rand_lampe1 disable 1,
attr rand_lampe2 disable 1,
attr rand_lampe3 disable 1,
attr rand_lampe4 disable 1,
attr di_tischleuchten1 disable 1,
attr di_tischleuchten2 disable 1,
attr di_tischleuchten3 disable 1,
attr di_tischleuchten4 disable 1,
attr di_tischleuchten5 disable 1
)
## cmd2
DOELSEIF
(
[du_mode_tischleuchten] eq "Dämmerung"
)
(
attr di_tischleuchten1 disable 0,
attr di_tischleuchten2 disable 1,
attr di_tischleuchten3 disable 1,
attr di_tischleuchten4 disable 1,
attr di_tischleuchten5 disable 1,
attr rand_lampe1 disable 1,
attr rand_lampe2 disable 1,
attr rand_lampe3 disable 1,
attr rand_lampe4 disable 1
)
## cmd3
DOELSEIF
(
[du_mode_tischleuchten] eq "Zufall-wenn-abwesend"
)
(
attr di_tischleuchten2 disable 0,
attr di_tischleuchten1 disable 1,
attr di_tischleuchten3 disable 1,
attr di_tischleuchten4 disable 1,
attr di_tischleuchten5 disable 1,
attr rand_lampe1 disable 1,
attr rand_lampe2 disable 1,
attr rand_lampe3 disable 1,
attr rand_lampe4 disable 1
)
## cmd4
DOELSEIF
(
[du_mode_tischleuchten] eq "Zufall-wenn-abwesend-und-dunkel"
)
(
attr di_tischleuchten3 disable 0,
attr di_tischleuchten1 disable 1,
attr di_tischleuchten2 disable 1,
attr di_tischleuchten4 disable 1,
attr di_tischleuchten5 disable 1,
attr rand_lampe1 disable 1,
attr rand_lampe2 disable 1,
attr rand_lampe3 disable 1,
attr rand_lampe4 disable 1
)
## cmd5
DOELSEIF
(
[du_mode_tischleuchten] eq "Zufall-wenn-scharf"
)
(
attr di_tischleuchten4 disable 0,
attr di_tischleuchten1 disable 1,
attr di_tischleuchten2 disable 1,
attr di_tischleuchten3 disable 1,
attr di_tischleuchten5 disable 1,
attr rand_lampe1 disable 1,
attr rand_lampe2 disable 1,
attr rand_lampe3 disable 1,
attr rand_lampe4 disable 1
)
## cmd6
DOELSEIF
(
[du_mode_tischleuchten] eq "Zufall-wenn-scharf-und-dunkel"
)
(
attr di_tischleuchten5 disable 0,
attr di_tischleuchten1 disable 1,
attr di_tischleuchten2 disable 1,
attr di_tischleuchten3 disable 1,
attr di_tischleuchten4 disable 1,
attr rand_lampe1 disable 1,
attr rand_lampe2 disable 1,
attr rand_lampe3 disable 1,
attr rand_lampe4 disable 1
)
## cmd7
DOELSEIF
(
[du_mode_tischleuchten] eq "Zufall"
)
(
attr di_tischleuchten1 disable 1,
attr di_tischleuchten2 disable 1,
attr di_tischleuchten3 disable 1,
attr di_tischleuchten4 disable 1,
attr di_tischleuchten5 disable 1,
attr rand_lampe1 disable 0,
attr rand_lampe2 disable 0,
attr rand_lampe3 disable 0,
attr rand_lampe4 disable 0
)
In jedem DOIF "di_tischleuchten1-5" gibt es zu jedem cmd1 (Prüfung auf Helligkeit, etc.) nur ein DOELSE.
Mit deinem neuem Feature würden alle DOIFs im DOELSE-Part verbleiben und sich gegenseitig stören.
Würde ich aus dem DOELSE ein DOELSEIF machen, um so den Modus-Dummy auch zu überprüfen, dann müsste ich auch alle Bedingung aus cmd1 wiederholen. Ich bräuchte dann im DOELSEIF jedesmal das Gegenteil der Bedingungen aus cmd1.
Wahrscheinlich ist meine Situation recht individuell. Ich habe auch lange überlegt, ob 1x DOIF oder 6xDOIF. Der Code ist oft zwischen verschiedenen DOIFs hin und her gewandert. Schlussendlich ist das Splitten und Deaktivieren des nicht benötigten Codes doch übersichtlicher. Auch wenn ich dafür eine Zwischenebene reinziehen musste, die den Dummy überwacht.
Am Rande: Es wäre ein bißchen einfacher, wenn ich nicht noch das RandomTimer-Modul für den Zufallsmodus hätte. Aber mir ist der dortige Zufallsmechachnismus transparenter als die verschiedenen rand()-Varianten im DOIF-Modul.
Es ist kompliziert (zu erklären). Betreibe also bitte keinen großen Aufwand für nur meinen individuellen Wunsch. Danke.
Zitat von: FunkOdyssey am 01 August 2016, 18:22:57
Damian, ich hatte nun ein wenig Zeit mit dem Feature herumzuspielen. Ich freue mich ja, dass du es eingebaut hast. Aber wenn du es NUR für mich eingebaut haben solltest, dann kannst du das gerne wieder entfernen. In der jetzigen Implementierung spare ich ja "nur" einen Dummy-Vergleich. Sonst ändert sich nichts. Außer, dass es nun wenig übersichtlich ist, da man nun auch noch die Attribute prüfen muss. Ich selbst deaktiviere meine DOIFs vollständig, wenn diese nicht benötigt werden. Sonst reagieren alle DOIFs auf viel zu viele Trigger. Wenn es schon nicht wegen der Performance ist und ich mir darüber keine Gedanken muss; dann aber wegen der schlechteren Nachvollziehbarkeit.
Ok, es war ein schneller Hack, den ich einfach umsetzen konnte. Was mir aber nicht gefällt, ist die Tatsache, dass man keine Zeitintervalle angeben kann. Desweiteren wäre ein Deaktivieren (abgesehen von Performance) besser gewesen, da man nach dem Aktivieren eher eine Aktion erwartet, als im letzten Zustand zu verbleiben, der ohnehin nicht mehr aktuell wäre.
Ich denke auch, dass man besser mit einem separaten DOIF das Aktivieren bzw. Deaktivieren vornimmt, denn hier stehen alle Optionen offen, die ein DOIF-Modul bietet.
Dann werde ich nur das zweite Feature (Stati, Readings in Zeitfunktionen) einchecken.
Gruß
Damian
Hallo,
ich finde das DOIF echt klasse und arbeite gerne damit, aber an einer Stelle komme ich jetzt nicht weiter.
Dank der Hilfe in einem anderen Threat und der Ansage:
Zitat von: Damian am 27 Juli 2016, 07:13:36
Ich habe die Beta-Version im ersten Post um ein weiteres Feature ergänzt:
https://forum.fhem.de/index.php/topic,56008.msg476113.html#msg476113
Gruß
Damian
bin ich ein ganzes Stück weiter gekommen.
Allerdings bin ich jetzt von sunset/sunrise auf das Twilight-Modul umgeschwenkt und habe versucht das auch mit dem DOIF zu erschlagen.
Ich habe z.B. folgenden Code:
define di_wz_Rolladen_auto DOIF
(
[{twilight("Twilight","ss_civil","14:00","[du_Rolladen_Zeit_wz_ru]")}] and
[du_Rolladen_wz_sunset] eq "an" and
[du_Rolladen_wz_auto] eq "an"
)
(
set wz_Rolladen_haupt Zu,
set azi_Rolladen Zu
)
DOELSE
attr di_wz_Rolladen_auto do always
File Rev Last Change
# $Id: 98_DOIF.pm 0.2 $
Der Sunset, also die Zeit, bleibt aber leider immer die Gleiche, bis man das DOIF mal neu geladen hat... Etwas über def gemacht o.ä. Es wird irgendwie immer nur einmal die Zeit abgeholt, danach nie wieder. Ich habe mal zwei Tage abgewartet. Obwohl sich Twilight ja morgens oder nachts neu berechnet, ändert sich an den Schaltzeiten des DOIF nix.
Funktioniert das tatsächlich "nur" mit sunset und sunrise?
Gibt es dafür einen Trick, oder ist der code falsch? Kann das jemand nachvollziehen?
Danke und bis denn
SouzA
Zitat von: SouzA am 27 August 2016, 16:59:42
Hallo,
ich finde das DOIF echt klasse und arbeite gerne damit, aber an einer Stelle komme ich jetzt nicht weiter.
Dank der Hilfe in einem anderen Threat und der Ansage:
bin ich ein ganzes Stück weiter gekommen.
Allerdings bin ich jetzt von sunset/sunrise auf das Twilight-Modul umgeschwenkt und habe versucht das auch mit dem DOIF zu erschlagen.
Ich habe z.B. folgenden Code:
define di_wz_Rolladen_auto DOIF
(
[{twilight("Twilight","ss_civil","14:00","[du_Rolladen_Zeit_wz_ru]")}] and
[du_Rolladen_wz_sunset] eq "an" and
[du_Rolladen_wz_auto] eq "an"
)
(
set wz_Rolladen_haupt Zu,
set azi_Rolladen Zu
)
DOELSE
attr di_wz_Rolladen_auto do always
File Rev Last Change
# $Id: 98_DOIF.pm 0.2 $
Der Sunset, also die Zeit, bleibt aber leider immer die Gleiche, bis man das DOIF mal neu geladen hat... Etwas über def gemacht o.ä. Es wird irgendwie immer nur einmal die Zeit abgeholt, danach nie wieder. Ich habe mal zwei Tage abgewartet. Obwohl sich Twilight ja morgens oder nachts neu berechnet, ändert sich an den Schaltzeiten des DOIF nix.
Funktioniert das tatsächlich "nur" mit sunset und sunrise?
Gibt es dafür einen Trick, oder ist der code falsch? Kann das jemand nachvollziehen?
Danke und bis denn
SouzA
Die Zeitfunktion wird ausgewertet, wenn der Timer auslöst. Bei ss_civil ist die Zeit zu diesem Zeitpunkt (ca. 21:00 Uhr) noch die gleiche. Das Reading wird nämlich im Twighlight-Modul erst nach Mitternacht aktualisiert, damit ändert sich die Zeit im DOIF-Modul verzögert erst am Folgetag beim nächsten Timertrigger .
Gruß
Damian
Hallo,
Vielen Dank für Deine Antwort.
Ok, das war mir jetzt nicht aufgefallen. Werde nochmal nen paar Tage laufen lassen...
Aber gibt es eine Möglichkeit, das aktuell zu halten?
Danke und bis denn
SouzA
Zitat von: SouzA am 28 August 2016, 13:59:09
Hallo,
Vielen Dank für Deine Antwort.
Ok, das war mir jetzt nicht aufgefallen. Werde nochmal nen paar Tage laufen lassen...
Aber gibt es eine Möglichkeit, das aktuell zu halten?
Danke und bis denn
SouzA
Es gibt diverse Möglichkeiten, bei denen die Zeit bei jeder Änderung sofort aktualisiert wird.
z. B. ohne min-, max-Einschränkung:
([[Twilight:ss_civil]]) (....)oder z. B. mit maximaler und minimaler Einschränkung:
([{max("14:00:00",min("[Twilight:ss_civil]","[du_Rolladen_Zeit_wz_ru]"))}]) (...und jeweils das Attribut checkReadingEvent setzen, damit nicht alle paar Minuten die Zeit aktualisiert wird, siehe:
http://fhem.de/commandref_DE.html#DOIF_checkReadingEvent
Gruß
Damian