Hallo Rudi,
dieser Logeintrag taucht für verschiedene Geräte nach einem Neustart auf.
Nach längerem Rätseln stelle ich fest, daß es bei stateFormat zu einer Komplikation kommt. Da ich nicht sicher bin, ob es ein FHEMWEB oder fhem.pl Problem ist, stelle ich es mal hier ein.
Das Verhalten taucht auf, wenn in stateFormat eine Zeichenkette mit einem Leerzeichen beginnt (Abstandhalter zum Wert davor).
Beispiel:
define testReadings dummy
attr testReadings stateFormat {ReadingsTimestamp($name,"state",undef). " Wert: ".ReadingsVal($name,"state",0)}
set testReadings <irgendein Wert>
shutdown restart
list testReadings
Internals:
FUUID 60740fc6-f33f-15e6-c2a9-e486e4651cc6a0ec
NAME testReadings
NR 198
STATE ???
TYPE dummy
READINGS:
2021-04-12 11:24:37 Wert: 30.56
2021-04-12 11:24:37 state 30.56
Attributes:
stateFormat {ReadingsTimestamp($name,"state",undef).
" Wert: ".ReadingsVal($name,"state",0)}
Logeintrag
2021.04.12 11:55:40 3: testReadings: bad reading name 'Wert:' (allowed chars: A-Za-z/\d_\.-)
Lösche ich das fehlerhafte Reading mit
deletereading testReadings Wert:
bleibt es bis zum nächsten Neustart weg, alles andere funktioniert normal. Nehme ich das Leerzeichen vor Wert: weg, tritt das Phänomen nicht auf, dann gibt es allerdings auch keinen Abstand zwischen Zeitstempel und Wert:
mimue
Hi,
ich meine: wenn Du anstatt undef "Neustart" verwendest taucht kein Problem auf.
Gruß Otto
Die Ursache ist, dass setstate missbraucht wird, um (diese neumodischen) Readings in statefile zu speichern.
Es wird ein Reading "erkannt", wenn der Wert mit einem Zeitstempel beginnt. Damit ist es de-facto unmoeglich solche STATE Werte nach dem Neustart einzulesen: entweder landet der Wert in einem falschen Reading, oder es wird die o.g. Fehlermeldung ausgegeben.
@Rudi.
Das Problem scheint weniger der Zeitstempel zu sein, als das direkt angehängte Leerzeichen. Lasse ich es weg, tritt auch der Effekt nicht auf.
Ich habe es jetzt für mich durch zwischenschalten eines Kommas abgestellt.
Allerdings bleibt (für mich) die Frage offen, warum stateFormat unzulässige Operationen nicht von vornherein blockiert. Wäre im Text nicht zufällig der Doppelpunkt aufgetaucht, hätte es keinen Logeintrag gegeben, und die ungewollten Readings wären vermutlich spät oder gar nicht aufgefallen.
@Otto
Danke für den Tip, probiere ich gern mal aus.
mimue
ZitatDas Problem scheint weniger der Zeitstempel zu sein, als das direkt angehängte Leerzeichen.
Ich kann auch ein Regexp liefern, ich wollte es aber fuer Menschen verstaendlich formulieren. Leider ist diese Formulierung nicht immer ausreichend exakt.
ZitatAllerdings bleibt (für mich) die Frage offen, warum stateFormat unzulässige Operationen nicht von vornherein blockiert.
Weil ich vor 12 Jahren nicht so gut in die Zukunft sehen konnte, das hat sich bis heute nicht verbessert.
Und nach ca 30 Minuten gruebeln bin ich zum Schluss gekommen, dass ich lieber diesen Sonderfall falsch behandele, als das ich das Problem fixe, und damit ein Kompatibilitaetsbruch mit all den Folgeproblemen einhandele.
Zitat von: mimue am 14 April 2021, 08:42:10
@Otto
Danke für den Tip, probiere ich gern mal aus.
mimue
der Begriff von mir war völlig ohne Zusammenhang gewählt, Du kannst auch Willi hinschreiben. Ich meine ja das Problem tritt auf weil stateFormat den Anfang des Textes der durch den Perlcode erzeugt wird als Fehler interpretiert wenn da ein Leerzeichen steht?
Wenn undef - also nix zurückkommt sieht der String so aus > Wert: 0< Wenn ein Timestamp zurückkommt sieht er so aus >2019-10-16 21:12:46 Wert: 0<
Es geht ja gar nicht um den Namen eines Readings, es geht um Inhalt im STATE.
Ich meine: undef als default Wert in ReadingsDingens() zu verwenden ist meistens eine schlechte Idee!
Gruß Otto