Warum wird in die Raw definition für readings ein setstate genereriert?
Wenn ich den Wert im setstate dann ändere und ausführe, bewirkt das nichts, erst wenn ich aus dem setstate ein setreading mache.
Ein Beispiel:
define testSetStateSetReading dummy
# CFGFN
# DEF
# FUUID 64ea0739-f33f-9021-d03a-f74d00e95c646a6d
# NAME testSetStateSetReading
# NR 7842
# STATE ???
# TYPE dummy
# eventCount 1
# READINGS:
# 2023-08-26 16:08:22 dummy 123
#
setstate testSetStateSetReading 2023-08-26 16:08:22 dummy 123
Raw Definition:
defmod testSetStateSetReading dummy
setstate testSetStateSetReading 2023-08-26 16:08:22 dummy 124
Ausführen von "setstate testSetStateSetReading 2023-08-26 16:08:22 dummy 124" ändert den Wert des Readings nicht, erst ein setreading testSetStateSetReading dummy 124
In den Backups der Statefiles war das früher (~2019) auch so mit setreading, erst später sind dort setstate.
Ist das Absicht? Sollte in der Raw Defition nicht besser ein setreading stehen?
Das ist schon alle ok so, keine Sorge.
setstate wird verwendet, weil damit beim Start von FHEM der vor dem Neustart bestehende Zustand der readings inkl. deren altem Timestamp wiederhergestellt wird.
Beim Start klarerweise ok, da hatte ich ohnehin keine Sorgen ;-)
Aber in der Raw Definition ist es schon überraschend, wenn "Execute commands" wirkungslos ist, weil dort ein setstate statt setreading ist.
Es ist nicht überraschend. Die raw definition ist exakt das, was bei einem "save config" abgespeichert würde.
Das setstate funktioniert sehr wohl. Du kannst das sehr einfach testen: kopiere die gesamte raw definition, lösche danach das device und führe dann die raw definition neu aus.
Rein interessehalber: was spricht denn dagegen, in der Raw Definition setreading zu verwenden?
Setreading generiert ein Event, setstate tut dies nicht.
Zitat von: fichtennadel am 26 August 2023, 22:55:08Rein interessehalber: was spricht denn dagegen, in der Raw Definition setreading zu verwenden?
setreading und setstate sind in der cmdref dokumentiert.