Guten Abend
ich wollte ein falsch angelegtes userreading mit deletereading <device> reading (deletereading Ofen HZ) löschen.
Nach einem Neustart ist das Reading wieder da.
Nur wenn ich fhem.save lösche ist es weg. Das kann und will ich aber nicht löschen denn dort sind ja die Werte HourCounter gespeichert.
Gibts da einen Workaround oder mach ich was falsch?
Danke
Nice eve Helmut
Sichern (save), vor dem Neustart ?
servus
Nein, leider nützt auch nix.
Helmut
Hast du vor dem Neustart das verantwortliche Attribut userReadings gelöscht oder nur das Reading, das von dem Attribut angelegt wird, selbst ?
Hallo Helmut,
ZitatNach einem Neustart ist das Reading wieder da.
Nur wenn ich fhem.save lösche ist es weg.
Dann war es aber kein "sauberer" shutdown, oder ?
Ich speichere die fhem.save periodisch, damit ich im Falle eines Absturzes etc. immer halbwegs aktuelle Daten beim restart habe.
Grüße Markus
@TomLee
Das ist das merkwürdige - das attr userReadings ist nicht mehr vorhanden. Nur mehr dasReading......
@KölnSolar
ich mache einen Neustart immer über die Konsole mit
sudo systemctl stop fhem
und
sudo reboot
Gruß
Helmut
Dann ist das attribut userreading immer noch da und erzeugt nach jedem Neustart das reading wieder neu.
Also erst das verantwortliche attribut userreading loeschen, dann als 2-tes das userreading selber. Sonst wird das userreading ja imme wieder neu generiert.
Schuss ins Blaue...
Hattest du nicht in deinem Ofen-device
extractAllJSON 1
gesetzt?
Dann werden doch alle readings bei Triggerung des devices wieder angelegt oder?
VG
Andreas
Hallo Jamo - du bist ja überall helfend zur Seite 8)
Leider nein - das attr ist nicht mehr vorhanden. Habe es trotzdem nochmals gelöscht und dann das Reading gelöscht.
Nach einem Neustart ist es wieder da. Es generiert sich immer wieder.
Das ganze ist bei "meinem Ofen" (den du ja schon kennst)
Ich werde den Ofen nochmals neu auf meinem Testsystem aufsetzen da schon ziemlich viel Mist durch das HTTPMOD extractAllJSON daherkommt.
@Vize
Ja das dürfte es sein
Danke und nice eve
Helmut
Zitat von: Helmi55 am 20 Oktober 2021, 18:22:17
Hallo Jamo - du bist ja überall helfend zur Seite 8)
Man tut was man kann! :)
Das Problem ist vermutlich ein ganz anderes gewesen:
Zitat von: Helmi55 am 20 Oktober 2021, 17:53:22
Beim Hochfahren habe ich folgende Meldungen im log
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
[/code]
Hallo und sorry für die späte Antwort.
fhem hatte keine Berechtigung auf die fhem.save. Wieso auch immer? Ich habe in den letzten Wochen keine Änderungen im System vorgenommen????
Danke an MadMax-FHEM
pi@homebridge:~ $ ls -la /opt/fhem/log/fhem.save
-rw-r--r-- 1 pi pi 261452 Okt 20 15:20 /opt/fhem/log/fhem.save
pi@homebridge:~ $
Habe das jetzt wieder gerade gebogen und nun sind keine Auffälligkeiten im log -Danke
@Beta-User
das deletereading funktioniert trotzdem nicht. Dürfte wie Vize schon vermutet hat durch
extractAllJSON 1
immer wieder nachgeladen werden.
Danke für eure Unterstützung
Gruß
Helmut
Zitat von: Helmi55 am 21 Oktober 2021, 12:59:33
das deletereading funktioniert trotzdem nicht. Dürfte wie Vize schon vermutet hat durch
extractAllJSON 1
immer wieder nachgeladen werden.
Jein. deletereading funktioniert vermutlich schon, was aber nur begrenzt wirkt, wenn es wieder angelegt wird - sei es durch obiges Attribut oder das ehemalige userReadings-Attribut.
Aber wenn es wirklich (soweit wie möglich) gelöst ist, ist ja alles fein :) .