RandomTimer - neues Modul

[holle75]

Hallo Ihr, vielleicht liest hier ja noch jemand mit.... seit gestern mit RandomTimer zur Anwesenheitssimulation/Licht ein bißchen rumgespielt. Was ich mich noch frage: welches Reading zeigt mir den aktuellen Status des zu schaltenden Devices on/off auf?

active scheint mir die Aktivität des RandomTimers anzuzeigen, aber nicht den Status des Devices?

Und noch eine Frage wo mich die Handhabung noch irritiert: Bei obengenannter Aufgabenstellung möchte man gerne wenn die Anwesenheit von einem selbst eintritt den/die RandomTimer(s) stoppen/disablen. Gerade mache ich das über

attr Ghost1 disableCond (ReadingsVal("AnwesenheitHaupt","state","absent") eq "present")
attr Ghost1 disableCondCmd none

und in einem DOIF (reduziert, da hats noch viel anderes mit drin)
DOIF ([AnwesenheitHaupt:state] eq "present")
(set Ghost.* execNow)
DOELSESIF  ([AnwesenheitHaupt:state] eq "absent")
(set Ghost.* execNow)

dies zum AB und ANschalten aller RandomTimers. Gibt es eine mehr lesbare Möglichkeit jegliche Ausführung von RandomTimer, ohne weitere StatusVeränderung, mit einem set zu unterbinden? Mich stört, dass ich die Bedingung in die RandomTimers schreiben muss.

Wenn ich es richtig verstehe, schaltet ein active/inactive setzen noch den letzten Zustand (in meinem Falle Licht off, was ich als Zwischenschritt, wenn man Abends nach Hause kommt vermeiden möchte)

Danke und Gruss
H.

[Beta-User]

welches Reading zeigt mir den aktuellen Status des zu schaltenden Devices on/off auf

Wieso erwartest du, dass das als Reading am RandomTimer "gedoppelt" wird?

Wenn ich es richtig verstehe, schaltet ein active/inactive setzen noch den letzten Zustand (in meinem Falle Licht off, was ich als Zwischenschritt, wenn man Abends nach Hause kommt vermeiden möchte)

Hmmm, nach einem kurzen Blick in den Code würde ich annehmen, dass in allen "deaktivierten" Fällen disableCondCmd beachtet wird - ganz egal, ob das via "set xx inactive", "execNow" (mit nun anderem Ergebnis der Prüfung der disableCond) oder z.B. disableForIntervals passiert.
Und wenn man gar keine Reaktion haben will, braucht man imo den RT auch nicht aktiv umschalten, sondern einfach nur den disableCondCmd auf none stellen. Das führt dann halt erst später (zum nächsten (Zwischen-) Timer) zu einem update des RT.

Kurz: Im Moment verstehe ich das Problem noch nicht (außer der "fehlenden Lesbarkeit" (?!?)).

[holle75]

Wieso erwartest du, dass das als Reading am RandomTimer "gedoppelt" wird?

Ich erwarte es nicht, vermisse es nur. Was meinst du mit "gedoppelt"? Dass das zu schaltende Device schon einen Status hat? Dann weiß ich nicht, ob es sonstwie an/ausgeschaltet wurde oder RT das veranlasst hat. Mich würde schon interessieren, was das Modul gerade macht und nicht nur, ob es selbst gerade aktiv ist.
Als Grund: mit einem

Code Auswählen Erweitern

define AktiveGhosts_DOIF DOIF ([$SELF:aktivierteGhosts] > 0) \
    ({Log 1, "AktiveGhosts_DOIF - Anzahl Licht an: ".ReadingsVal("AktiveGhosts_DOIF", "aktivierteGhosts", "Na");;}) \
DOELSEIF ([$SELF:aktivierteGhosts] == 0) \
    ({Log 1, "AktiveGhosts_DOIF - alle Licht aus";;})
attr AktiveGhosts_DOIF DOIF_Readings aktivierteGhosts:[#"^AlleRandomTimerModule":WievieleStehenGeradeAufAn:"^on$"]
könnte ich mir zB schön den Status (wieviele Lampen sind gerade wirklich an) anzeigen, oder ins Log schreiben lassen. Im Moment habe ich keine Ahnung, was (vom Modul gesteuert) gerade geschieht.

Hmmm, nach einem kurzen Blick in den Code würde ich annehmen, dass in allen "deaktivierten" Fällen disableCondCmd beachtet wird - ganz egal, ob das via "set xx inactive", "execNow" (mit nun anderem Ergebnis der Prüfung der disableCond) oder z.B. disableForIntervals passiert.

Das werde ich probieren! Guter Ansatz. Hatte ich so nicht verstanden. Danke

[Beta-User]

Im Moment habe ich keine Ahnung, was (vom Modul gesteuert) gerade geschieht.

Na ja, ehrlich gesagt interessiert mich in der Regel nicht, warum irgendeine Lampe an oder aus ist, sondern nur, ob der Zustand "richtig" ist.
Wenn es dann ans debugging geht, wäre verbose mein Kandidat, wobei das bei RandomTimer auch nur zum Teil aussagefähig ist, weil ja "relativ zufällig" ist, was (effektiv) geschieht ...
(Allerdings bin ich nicht sicher, ob ein höherer verbose-Level aufgrund des Codings im Modul was besonders aufschlussreiches zu Tage fördert).

Jedenfalls habe ich derzeit keine Pläne, zusätzliche Datenpunkte oder Events zu erzeugen.

[holle75]

.... und eben (scheinbar vorher komplett blind, oder das Reading war noch nicht gesetzt) ist mir noch "LastCommand" als Reading aufgefallen, was eigentlich genau das macht was ich brauche.

mit zB

Code Auswählen Erweitern

define AktiveGhosts_DOIF DOIF ([$SELF:aktivierteGhosts] > 0) \
    ({Log 1, "AktiveGhosts_DOIF - Anzahl Licht-Steckdosen an: ".ReadingsVal("AktiveGhosts_DOIF", "aktivierteGhosts", "Na");;}) \
DOELSEIF ([$SELF:aktivierteGhosts] == 0) \
    ({Log 1, "AktiveGhosts_DOIF - alle Licht-Steckdosen aus";;})
attr AktiveGhosts_DOIF DOIF_Readings aktivierteGhosts:[#"^RT_Ghost":LastCommand:"on"]
attr AktiveGhosts_DOIF devStateIcon disabled:general_aus@red:initialize initialize:general_an@yellow:disable initialized:general_an@yellow:disable cmd_1:general_an@green:disable cmd_2:general_an@yellow:disable
attr AktiveGhosts_DOIF do always
kann man sich die Anzahl aktiver Devices, zumindest wenn ausschließlich von RT gesteuert, ins Log schreiben lassen. Davon ausgehend, dass alle RT Devices zB RT_Ghost1, RT_Ghost2, ... heißen.

Das meintest du wahrscheinlich mit "doppelt"

[Beta-User]

Das meintest du wahrscheinlich mit "doppelt"

Nope...

Gemeint war eher sowas:
(Mindestens) Seit ich das Modul betreue - erster Commit von mir

Code Auswählen Erweitern

# $Id: 98_RandomTimer.pm 19272 2019-04-28 05:43:23Z Beta-User $hat keiner Bedarf für "sowas" angemeldet. Jetzt ohne Not wieder tiefer in den Code einzusteigen und ggf. zusätzliche Events oder Readings zu erzeugen erschien mir schlicht unverhältnismäßig.

Aber ok, wenn es die Funktionalität bereits gibt, baue ich das auch nicht wieder aus, störte ja offensichtlich bisher auch keinen .