DOIF - disable / enable und longpoll

[Elektrolurch]

Hallo,

Problem: Nach einem

Code Auswählen Erweitern


set Az_Klima_doif disable

wird sowohl die state - Anzeige, als auch der "mode" per longpoll aktualisiert (siehe unten die Def. der entsprechenden readingsGroup).
Bei einem "enable" - Befehl nur der "mode", aber nicht der "state" auf dem Bildschirm.
Listet man das reading "state" nach dem enablen auf, so steht dort der letzte Zustand (offen) korekterweise.
Auf dem Bildschirm kommt dies erst nach F5 (Refresh) zur Anzeige.
Der "set Az_Klima_doif enable" - Befehl scheint kein longpoll für den "state" zu erzeugen.

Hier mein Objekt (Az_Klima_doif=:

Code Auswählen Erweitern


Attributes:
   MaxTemperature 30
   alias      (Az) Klima
   cmdState   Sonnenschutz|offen
   comment    Schliesst die Rolladen auf Straßenseite, wenn draußen zu warm
   devStateIcon (initialized|offen):fts_shutter_alldown:Sonnenschutz Sonnenschutz:fts_shutter_allup:offen disabled:general.off@red:enable
   disable    0
   event-on-change-reading .*
   genericDeviceType switch
   group      Klima,Rolladen
   homebridgeMapping clear On=state,valueOn=Sonnenschutz,valueOff=offen,cmdOn=Sonnenschutz,cmdOff=offen
   setList    state:initialized,disable,Sonnenschutz,offen
   timestamp-on-change-reading .*
   userattr   MaxTemperature:25,26,27,28,29,30,31,32
   verbose    1


Zur Anzeige wird das Az_Klima_doif - Objekt über eine readingsGroup gebracht:

Code Auswählen Erweitern


   DEF        Az_Thermostat:<Thermostat>,mode,desired-temp,battery Az_Fenster:Window,<{ReadingsTime($DEVICE,'Previous')}@state>,<>,Battery  <Rolladen> Az_FRolladen:<Fenster>,state,position Az_FRolladen:!UP,!DOWN,!STOP <Sonnenschutz>  Az_Klima_doif:<Status>,state,<{ReadingsTime($DEVICE,'state')}@state>  Az_Klima_doif:<automatisch>,mode,?MaxTemperature

Attribute der rg:
     commands   {...'state.offen' => 'set $DEVICE Sonnenschutz', 'state.Sonnenschutz' => 'set $DEVICE offen', 'state.initialized' => 'set $DEVICE Sonnenschutz', 'mode.enabled' => 'set $DEVICE disable', 'mode.disabled' => 'set $DEVICE enable', 'MaxTemperature' => 'MaxTemperature:'}
     
valueIcon  {.... 'Az_Klima_doif.state' => '{MakeIconwithLabel2($DEVICE,"%devStateIcon","")}', 'mode.enabled' => '{MakeIconwithLabel("general.on",$VALUE,"aktiv")}', 'mode.disabled' => '{MakeIconwithLabel("general.off",$VALUE,"deaktiviert")}'}

     valueSuffix {...  'MaxTemperature' => ' °C' }


Elektrolurch

[Damian]

Das Problem wird wohl sein, dass zum Zeitpunkt des Aktivierens (enable) das Modul ja im Zustand disabled ist und daher keine Events kommen. Muss ich mir aber noch genauer anschauen.

[Elektrolurch]

Hmm.
Der "set Az_Klima_doif enable" Befehl "enabled" das Objekt.
Danach geht ja der state auf den richtigen Wert, wie man am internen Listing sieht, d.h. da sollte doch für "state" ein "readingsBulkUpdate" seitens des doif-Objektes ausgelöst werden, was dann auch zur Aktualisierung des screen per longpoll führen sollte.
Tut mir leid, ist ja nur eine Kleinigkeit...
Ich hatte zu erst die readingsGroup in Verdacht, wenn in der Definition ein erzwungener Zeilenwechsel (<hr>) ist, daran liegt es aber nicht.


Elektrolurch

[Damian]

Ich habe mir jetzt den Code angeschaut.

Es wird ja bei enable der letzte Zustand vor disable in state gespeichert. Das ist dann meistens cmd..., oder sonst etwas über Attribut State selbst definiertes. Wenn ich nun mit einem Event den Status zurücksetzen würde, dann würde z. B. cmd_1 im state wieder landen, allerdings ohne, dass cmd_1 ausgeführt wird. Und das gäbe Ärger bei allen, die auf den Status des DOIF-Device triggern.

Daher hatte ich bewusst nur beim Reading mode einen Trigger sowohl bei disable, als auch bei enable zugelassen.

[Elektrolurch]

Hallo Damian,

ok, z.T. kann ich das nachvollziehen.
Wenn ich aber auf die Ausführung eines Komandos triggern möchte, würde ich eher das reading "cmd" verwenden, als den state.
Beim Übergang von disabled auf enabled ändert sich dies nämlich nicht.

Wie könnte man das lösen?
a) ein zusätzliches userreading: Welches sich aus state ableitet und durch state und mode  getriggert wird?
Hätte den Nachteil, dass ich dies für jedes DOIF anlegen müsste und in den darstellenden readingsGroup für das Icon von state nicht mehr elegant auf defStateIcon verweisen kann.
b) Ein Attribut in DOIF, welches besagt: TriggerStateonEnable = 1 => Dann bekäme man auch mit, wenn state von "disabled" auf den letzten Wert von state sich ändert.

Ansonsten: Hier mal mein nachdrückliches Lob. Ich stelle gerade meinen perl-Code auf DOIF um, weil man damit die Parameter für Automatisierungen viel besser darstellen kann, weil sie näher an der "Regel" liegen und nicht in iregendwelchen 99_myUtils... verschwinden.
Elektrolurch

[Damian]

Alternativ könntest du statt das Reading state, den Status des DOIF-Device anzeigen, dann klappt es auch mit der Aktualisierung des Status bei enable.

[Elektrolurch]

Hallo Damian,

meinst Du den Internal Wert "STATE"?

Leider triggrt die readingsGroup nicht auf die Änderung von internen Werten.

Code Auswählen Erweitern


define  Sol_Betrieb_rg Pufferschutz_doif:<Pufferschutz>,+STATE,<{ReadingsTime($DEVICE,"state")}@state>


Dann ändrt sich die Anzeige für +STATE überhaupt nicht mehr, wenn man disable / enable hin- und her schaltet.
Erst nach F5 im Browser steht wieder der korrekte Wert da.
Oder hast Du etwas anderes  gemeint?

Elektrolurch

[Damian]

Hallo Damian,

meinst Du den Internal Wert "STATE"?

Leider triggrt die readingsGroup nicht auf die Änderung von internen Werten.

Code Auswählen Erweitern


define  Sol_Betrieb_rg Pufferschutz_doif:<Pufferschutz>,+STATE,<{ReadingsTime($DEVICE,"state")}@state>


Dann ändrt sich die Anzeige für +STATE überhaupt nicht mehr, wenn man disable / enable hin- und her schaltet.
Erst nach F5 im Browser steht wieder der korrekte Wert da.
Oder hast Du etwas anderes  gemeint?

Elektrolurch

OK. Ich benutze Readingsgroup nicht, aber beim normalen Device und in uiTable funktioniert das, da der STATUS ja bei jedem Event des eignen Device aktualisiert wird.

[Elektrolurch]

Hallo Damian,

habe mal folgendes als Monitor definiert:

Code Auswählen Erweitern


   define         Pufferschutz_not notify Pufferschutz_doif.* {Log(1,"$NAME: $EVENT")}

Dann habe ich nach einander das device Pufferschutz_doif disabled und dann wieder enabled:

Code Auswählen Erweitern


# set Pufferschutz_doif disable
2022.07.08 23:51:02 1: Pufferschutz_doif: last_cmd: aus
# event auf STATE
2022.07.08 23:51:02 1: Pufferschutz_doif: disabled
2022.07.08 23:51:02 1: Pufferschutz_doif: mode: disabled
# set Pufferschutz_doif enable
2022.07.08 23:52:28 1: Pufferschutz_doif: mode: enabled


Definitiv wird auch kein Event auf STATE vom DOIF-Modul gesendet.
Warum sollte dies auch geschehen, wenn kein event auf "state" gesendet wird.

Das Problem hat also erst einmal nichts mit der readingsGroup zu tun, sondern mit DOIF, da "set device disable" und "set device enable" bzgl. der events auf state de facto unterschiedlich erzeugt werden.

Entweder für "disable" und "enable" auf state in beiden Fälllen kein Event erzeugen oder dies über, wie oben vorgeschlagen (wegen Kompatiblität) per Attribut einschaltbar machen (event-on-state-enable wäre ev. sinnvoll).

Ich habe für einige DOIF-Regeln einen Knopf für das deaktivieren/aktivieren, wobei der angezeigte "state" nur beim Deaktivieren korekt (automatisch per Event) angezeigt wird, beim Aktivieren jedoch nicht.

Aus der DOIF_set:

Code Auswählen Erweitern


elsif ($arg eq "enable" ) {
      #delete ($defs{$hash->{NAME}}{READINGS}{mode});
      if ($hash->{MODEL} ne "Perl") {
        readingsSingleUpdate ($hash,"state",ReadingsVal($pn,"last_cmd",""),0) if (ReadingsVal($pn,"last_cmd","") ne "");
   
Bei dem Aufruf von "readingsSingleUpdate" die "0" durch "AttrVal($name,"event-on-state-enable",0)" ersetzen.

Elektrolurch

[Damian]

Definitiv wird auch kein Event auf STATE vom DOIF-Modul gesendet.

Das habe ich auch nicht behauptet. Ich habe lediglich gesagt, dass der STATUS (nicht das Reading state) bei jedem Event des des Devices, also auch "mode enable" im FHEM-Web aktualisiert wird.