Hallo zusammen,
mein DOIF reagiert ungewollt auf folgende Meldung:
2023-11-16 13:14:46 dummy Alarm_status disarmed << addLog
Das << addlog dient nur zur Vermeidung von Plotabrissen
Das DOIF soll nur auf ein ...dummy Alarm_status disarmed reagieren.
Mein DOIF:
([SolvisBen:Zirkulationstemperatur] < 30 and
[Alarm_status] eq "disarmed" and
[?SolvisBen:Speicher_oben]+12 >= [SolvisBen:WWSollTemp])
( set HZ.Zirkulation ON )
Die HZ.Zirkulation soll ON gehen, wenn die Zirkulationstemperatur < 30 Grad ist, und
der Alarm_status disarmed ist. Alarm_status soll eben auch triggern ..
Habe schon einiges probiert:
["Alarm_status:^disarmed$"]
[Alarm_status] eq "^disarmed\$"
Mit beiden Varianten geht die HZ.Zirkulation gar nicht mehr an ..
Wäre für einen Tipp dankbar...
VG Klaus
Hallo Klaus, vielleicht reicht es, ein
and [?Alarm_status:state] !~ m/addLog$/
hinzuzufügen?
//edit: oder, wie von dir vorgeschlagen, nur anders notiert
[Alarm_status] =~ m/^disarmed$/
Hallo FHEMAN,
danke für den Hinweis.
Habe das gerade mal getestet, leider triggert noch immer addLog.., habe beide Varianten probiert..
Schade
VG
Klaus
Ist event-on-change-reading .* (und nicht event-on-update-reading) bei Alarm_status konfiguriert?
weder noch ..
Internals:
FUUID 5c489c0e-f33f-b6d9-9191-66683cc54e70cd40
NAME Alarm_status
NR 182
STATE disarmed
TYPE dummy
eventCount 226
READINGS:
2023-11-21 05:10:45 state disarmed
Attributes:
alias Alarm Status
devStateIcon armed:status_locked@green armedext:status_locked@green wait:status_locked@yellow disarmed:status_open .*:status_open@red
group Schalter
icon control_home
room Alarm
setList armed armedext disarmed wait
sortby 3
webCmd armed:armedext:disarmed:wait
Spricht was dagegen, es zu setzen? Evtl. eliminierst du damit die Events ausserhalb des Loggings. Bin mir aber auch nicht ganz sicher.
Habe jetzt mal event-on-change-reading state gesetzt.
Leider auch ohne erfolg ...
Das AddLog feuert immer noch.
Wie hast Du denn das addLog umgesetzt?
Mir sieht das nach einer ziemlich alten Variante aus.
Inzwischen bieten sowohl FileLog als auch DbLog addLog Varianten an, die sehr viel komfortabler funktionieren.
Naja, habe einen stündlichen Timer in dem ich das hier absetze:
{
....
addLog("WF.keymatic","state") ;;
addLog("Alarm_status","state") ;;
addLog("HZ.zt","Lueftung") ;;
.....
}
AddLog selbst habe ich in meiner 99_myUtils.pm definiert:
....
sub
addLog($$)
{
my ($logdevice, $reading) = @_; # device and reading to be used
my $logentry = ReadingsVal($logdevice,$reading,"addLog: invalid reading");
#if ($reading =~ m,state,i)
if ($reading =~ m,state,i || $reading =~ m,status,i)
{fhem "trigger $logdevice $logentry << addLog";}
else {fhem "trigger $logdevice $reading: $logentry << addLog";}
}
....
VG Klaus
Genau das hatte ich befürchtet.
Die eigene Funktion in der 99_myUtils.pm ist schon lange (mindestens 4 Jahre) nicht mehr notwendig.
Du rufst in der Funktion ja expliziert "trigger" auf und wunderst Dich allen Ernstes darüber, dass dann Events erzeugt werden? Warum heißt der Befehl wohl "trigger"?
Verwende die in den Logging-Modulen implementierten Umsetzungen für addLog, das sollte Deine Probleme lösen.
Das es mittlerweile auch ein Addlog beim Filelog gibt war mir neu - DANKE
Zitat von: FHEMAN am 19 November 2023, 14:30:13Hallo Klaus, vielleicht reicht es, ein
and [?Alarm_status:state] !~ m/addLog$/
hinzuzufügen?
//edit: oder, wie von dir vorgeschlagen, nur anders notiert
[Alarm_status] =~ m/^disarmed$/
Wundert mich, dass das nicht funktionierte.
Komme noch nicht so richtig klar mit dem Attribute addlog beim Filelog...
Habe mal das
attr FileLog_Alarm addlog Alarm_status:state:120angelegt.
Jetzt wird alle 120 Sekunden diese Zeile eingefügt:
2023-11-21_14:40:35 Alarm_status state: disarmed
Bei einem set Alarm_status disarmed wird dies eingefügt: (ohne state:)
2023-11-21_14:42:35 Alarm_status disarmed
Richtig nützlich wäre es, wenn der command (set ALarm_state disarmed) zum gleichen logeintrag führen würde, wie das addlog statement.
Geht das ?
Zitat von: FHEMAN am 21 November 2023, 16:33:52Zitat von: FHEMAN am 19 November 2023, 14:30:13Hallo Klaus, vielleicht reicht es, ein
and [?Alarm_status:state] !~ m/addLog$/
hinzuzufügen?
//edit: oder, wie von dir vorgeschlagen, nur anders notiert
[Alarm_status] =~ m/^disarmed$/
Wundert mich, dass das nicht funktionierte.
Gebe ich Dir recht, vielleicht hängt es mit dem status zusammen, weil dieser ja nicht explizit im Event monitor auftaucht.
Es erscheint ein:
dummy Alarm_status disarmed
und nicht
dummy Alarm_status state: disarmed
Bei Geräteten mit state wird prinzipiell nicht state: geschrieben ..
Die Verwendung solcher karierter Maiglöckchen im Zusammenhang mit "state" ist immer schwierig, weil state eben kein "normales" reading ist.
Nur der Vollständigkeit halber: [?Alarm_status:state] beim DOIF wertet das state Reading aus und triggert auch nur bei dessen Änderung/Update. Das müsste unabhängig von der Notation im Event sein.
Jetzt wäre evtl. addStateEvent der nächste Versuch, aber dann trägt es wirklich Blüten, die vermutlich nicht notwendig sind eigentlich.