Hallo,
Problem: Nach einem
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=:
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:
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
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.
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
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.
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
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.
Hallo Damian,
meinst Du den Internal Wert "STATE"?
Leider triggrt die readingsGroup nicht auf die Änderung von internen Werten.
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
Zitat von: Elektrolurch am 08 Juli 2022, 18:30:41
Hallo Damian,
meinst Du den Internal Wert "STATE"?
Leider triggrt die readingsGroup nicht auf die Änderung von internen Werten.
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.
Hallo Damian,
habe mal folgendes als Monitor definiert:
define Pufferschutz_not notify Pufferschutz_doif.* {Log(1,"$NAME: $EVENT")}
Dann habe ich nach einander das device Pufferschutz_doif disabled und dann wieder enabled:
# 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:
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
ZitatDefinitiv 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.