userreading's verschwinden von allein [Gelöst]

[Beta-User]

Nachdem das mit der kaputten statefile klarer ist, nochmal zum Rest:

Bzgl. der userreadings:
Muß man ein per "userreading" definiertes (ohne Werte) Reading zusätzlich per setreading "aktivieren" oder kommt das von allein wenn der Code Werte dafür erzeugt.

Man muss nichts aktivieren, wenn der Code ausgeführt wird und Werte zurückgibt, wird das Reading angelegt bzw. mit dem Wert versehen, fertig die Laube.

ich hatte den Eindruck daß es erst funktionierte nachdem ich mindestens ein Reading per setreading erzeugt hatte.

Das kann schon sein, wobei das hieße, dass der Teil von "$readingFnAttributes" hier nicht ginge. Kommt mir seltsam vor. Jedenfalls macht es generell einen Unterschied, ob man innerhalb einer laufenden Eventverarbeitungsroutine ist (getriggertes notify) ist oder außerhalb (manuell ausgeführtes setreading). Kann man zuhauf finden, wenn man nach setreading iVm. userReadings sucht (Antwort immer: fhem-sleep hilft, meist ist die Konstruktion dahinter nicht optimal...).

wie meinst Du das? Was soll ich direkt über die Kommandozeile eingeben/ausführen?

Den auszuführenden Code, den du im notify angegeben hast?!?

Warum von den userReadings nichts im Log steht, das weiß ich natürlich auch nicht, aber das notify funktioniert ja. Es berechnet die A-Werte und sendet diese auch an die Wallbox.

OK, es wird also irgendwas ausgeführt, aber möglicherweise nicht alles, oder das setreading (auf das notify selbst) muss verzögert werden...

=> Kommandozeilen-Test....

[DetlefR]

Bzgl. der userreadings:
Muß man ein per "userreading" definiertes (ohne Werte) Reading zusätzlich per setreading "aktivieren" oder kommt das von allein wenn der Code Werte dafür erzeugt.

Wie schon gesagt. Ein UserReading wird angelegt/aktualisiert, wenn sich auf dem eigenen Device (in diesem Fall dem Notify) ein Reading ändert und dabei einen Event erzeugt. Das ist bei einem Notify normalerweise nur dann der Fall, wenn die Definition geändert wird (state) oder eben manuell ein anderes Reading angelegt wird.

ich hatte den Eindruck daß es erst funktionierte nachdem ich mindestens ein Reading per setreading erzeugt hatte.

triggeredByDev und triggeredByEvent triggern keinen Event. Darum macht userReading in einem Notify nicht viel Sinn.

[frank]

triggeredByDev und triggeredByEvent triggern keinen Event. Darum macht userReading in einem Notify nicht viel Sinn.

wenn readings von haus aus keine events erzeugen, weil intern abgeschaltet, gibt es einen workaround.
suche nach "attr forceEvents".
kurzeinführung siehe https://forum.fhem.de/index.php/topic,112825.msg1184583.html#msg1184583

edit: der workaround ist natürlich mit vorsicht zu geniessen.
er könnte auch unangenehme nebeneffekte auslösen.

[Guzzi-Charlie]

Hallo Leute,

ihr müßt Euch jetzt nicht an vermeintlichen Problemen abarbeiten. Das notify funktioniert ja. Die Events der beteiligten Geräte kommen ja durch und triggern das notify. OK, ich hatte ein paar Verständnisprobleme mit der Anwendung der userReadings, aber das hatte ja nichts mit der Funktion des notifys zu tun.

Das ursprüngliche "vermeintliche" Problem existiert ja nicht, also ist dieses Thema eigentlich erledigt.

Das Problem liegt an ganz anderer Stelle.

restoreDir_saveFile($restoreDir, $attr{global}{statefile}) if(!configDBUsed());

Bedeutet: im globalen Attribut statefile wird %L beim Schreiben der Sicherungsdatei nicht aufgelöst.
Das ist ein Bug in fhem.pl, den man an geeigneter Stelle und in korrekter Form dem entsprechenden Autor melden sollte.

Setze das Attribut auf seinen Standardwert zurück, das sollte helfen.

Ich habe jetzt den Standardwert (log/fhem.save) im Global-Device wieder eingesetzt, aber leider hat sich das Verhalten nicht geändert. Das statefile wird durch save nicht geschrieben, sondern im Gegenteil immer noch geleert. Ich suche weiter.

[betateilchen]

Ich habe jetzt den Standardwert (log/fhem.save) im Global-Device wieder eingesetzt

das ist nicht der Standardwert. Der Standardwert ist

Code Auswählen Erweitern

attr global statefile ./log/fhem.save

Das statefile wird durch save nicht geschrieben, sondern im Gegenteil immer noch geleert.

Es gibt keine Stelle im FHEM Code, an dem das statefile geleert wird.
Es wird im Regelfall einfach geschrieben und ersetzt dabei das vorhandene statefile.

Was hast Du denn jetzt für eine Fehlermeldung im Logfile, wenn Du ein save durchführst?

[DetlefR]

Das Problem ist auch nicht das %L. Wäre auch komisch da es nur eine Routine zum Schreiben des statefile gibt.

Die Datei wird ja angelegt. Also wird auch der Path gefunden. Es steht leider nur die erste Zeile drin.
Nachdem die gebildet ist, kommt im Programm ein Loop durch alle %defs.  Die Frage ist, warum sind die einmal da und einmal nicht.

[Guzzi-Charlie]

Sorry, der default-Wert war schon richtig eingetragen. Ich hatte wohl nicht alles kopiert.

Es gibt keine Stelle im FHEM Code, an dem das statefile geleert wird.

Was soll ich sagen? Es ist aber so. Nach einem save ist das statefile leer. Auch mit der default-Einstellung für das statefile. Fehlermeldungen sehe ich im log keine mehr nach dem save.

Das Logfile schreibt er richtig und auch an die richtige Stelle.

Ich habe gerade was gefunden. Ob das richtig ist? Es gibt drei Pfade wo ich eine fhem.save finde:

   
• /opt/fhem/log
  ==> hier wird die Datei nach save geleert und mit (manuell) {WriteStatefile()} wieder geschrieben/gefüllt
• /opt/fhem/restoreDir/save/2022-09-03/log
  ==> wird nach save offensichtlich neu geschrieben
• /opt/fhem/restoreDir/save/2022-09-03/opt/fhem/log
  ==> wird nach save offensichtlich auch neu geschrieben

Irgendwo muß da doch was mit den Pfadzuweisungen nicht passen, oder?

[Guzzi-Charlie]

Das Problem ist auch nicht das %L.

Mit dem %L gabs ja eine Fehlermeldung im log. Mit den Default-Wert gibt es die ja nicht mehr, aber funktionieren tut es trotzdem nicht.

[betateilchen]

Das Problem ist auch nicht das %L. Wäre auch komisch da es nur eine Routine zum Schreiben des statefile gibt.

Noch so ein S2x1Z3NjaGVpw59lcg== der hier mit seinem Halbwissen um sich schmeißt.
Ist denn eigentlich schon wieder Vollmond?

WriteStatefile() war bezüglich %L nicht das Problem, da wurde das korrekt aufgelöst.
Aber CommandSave() kam bisher mit %L beim statefile nicht zurecht.
Dort wird nämlich vor dem Schreiben eines neuen statefile das bisherige statefile weggesichert und im dazu verwendeten copy Befehl wurde %L nicht aufgelöst, was zu den hier im Thread zitierten Fehlermeldungen beim save führten.

Das Problem ist inzwischen behoben, das entsprechende update der fhem.pl kommt morgen per update.

Ich habe gerade was gefunden. Ob das richtig ist? Es gibt drei Pfade wo ich eine fhem.save finde:

Lösche mal alle drei Dateien und mache danach ein "save".
Dann schau nach, ob/wo eine Datei fhem.save neu angelegt wurde und was da drinsteht.

[Guzzi-Charlie]

OK, habe alle drei Dateien gelöscht, eine kleine Änderung gemacht und ein Save config angestoßen.

Jetzt hat er die Datei unter

   
• /opt/fhem/log
  
  und unter
  
• /opt/fhem/restoreDir/save/2022-09-03/log

angelegt. Beide scheinen gleich zu sein, obwohl die Größe minimal variiert (1=586.874Byte und 2= 586.798Byte).

[betateilchen]

/opt/fhem/restoreDir/save/2022-09-03/log => Da liegt die automatisch gesicherte Vorher-Version (vor Deiner "kleinen Änderung")

/opt/fhem/log => Da liegt die aktuelle Version (inklusive Deiner "kleinen Änderung")

Dann funktioniert das doch jetzt wie es soll?

[Guzzi-Charlie]

So, nochmal kleine Änderung gemacht und wieder ein Save config angestoßen und funktioniert. D.h. FHEM hat jetzt tatsächlich den alten statefile mit dem Neuen überschrieben.

Das Löschen hat also irgendetwas bewirkt, daß es jetzt funktioniert.

Wenn das Update eingespielt ist könnte man also das %L wieder verwenden, oder? Ich brauche das zwar im Moment nicht mehr weil inzwischen alles auf einer M2-SSD liegt und nicht mehr getrennt wie vorher (OS und Programme waren auf der SD-Karte und die Logs auf einem USB-Stick). Aber gut zu wissen, daß mein "nicht vorhandenes Problem" letztendlich zu etwas gut war.

Trotz des etwas holprigen Starts bei diesem Thema bedanke ich mich bei Allen für die letztendlich erfolgreiche Unterstützung.

Soll ich das Thema dann noch auf "Gelöst" setzen?