userreading's verschwinden von allein [Gelöst]

[Guzzi-Charlie]

Wenn ich deinen Code richtig gelesen habe, dann sollen die userReadings auf dem Notify angelegt werden. Habe ich bisher noch nicht gesehen.
Und das hat auch einen Grund. userReadings werden angelegt/aktualisiert wenn sich auf dem Gerät wo es angelegt ist ein Reading ändert und einen Event erzeugt. Das ist bei einem Notify äußerst selten.

Ja, genau so war es gedacht. Werte ändern sich in den Geräten welche das notify triggern. Nach meinen Test funktioniert das auch. Vielleicht ist das auch keine gut Idee und ich muß das doch auslagern, aber das war ja eigentlich nicht das Problem. Trotzdem Danke für den Hinweis.

Ansonsten, bei der Verwendung von geschweiften Klammern bist du wirklich sehr großzügig.

Das war halt copy&paste aus anderen notify's von mir. Geht bestimmt besser, aber ich bin eben nicht der Perl-Programmierer. Mein Wissen ist da nur sehr rudimentär.

Und mach dich mal mit "elsif" vertraut. Das würde die vielen "if " sehr vereinfachen.

elsif kenne ich natürlich auch, aber die "vielen" if-Zeilen waren einfacher und schneller, da die alle fast gleich sind. Ich war ja erstmal froh das es überhaupt funktioniert. Diese ganze "Klammeritis" treibt mich sowieso oft in den Wahnsinn. Einmal fehlt eine Klammer, dann eine zuviel, dann an der falschen Stelle, etc. aber egal muß ich mit leben wenn ich FHEM verwenden will.

[DetlefR]

Ja, genau so war es gedacht. Werte ändern sich in den Geräten welche das notify triggern.

Das ist auch richtig. Das trifft aber nur für die Berechnung innerhalb des Notify zu.
userReadings werden auch getriggert. Aber nur wenn sich auf dem Device an dem sie angelegt sind, ein Reading ändert. Das ist in deinem Fall das Notify. Gibt es da ein Reading das sich ändert?
Leg die userReadings auf einem der anderen drei Geräte an. Dort, wo sich am meisten etwas ändert. Damit sie auch einigermaßen aktuell sind.

[MadMax-FHEM]

Da kann ich DetlefR nur zustimmen (und ja, darum dachte ich nicht mal daran, dass da unten im Code tatsächlich noch userReadings kommen) und es gibt ja sehr wohl weitere Devices, die hier in Zusammenhang stehen und davon gibt es eben keine lists...

userReadings an einem notify sind schon eher "nutzlos" wurde aber ja schon genannt...

Gruß, Joachim

[Beta-User]

Ein notify hat in der Regel schon Readings, von daher kann es schon sein, dass userReadings zwar ungewohnt sind, aber funktionieren.

ABER - im Ausführungscode findet sich:

Code Auswählen Erweitern

{fhem("set n_goE_charging AnzPha 1")}}Und in userReadings:

Code Auswählen Erweitern

AnzPha {3}

Mal abgesehen davon, dass die obere Zeile überhaupt nicht funktionieren dürfte: Was denn nun...

Ganz allgemein würde mich weiter interessieren, was im Log steht, wenn das Ding getriggert wird!

Noch ein Hinweis: fhem.pl erwartet "Klartext" (Perl-Data-Type SCALAR) für Reading-Werte. Weiß noch nicht, was passiert, wenn man versehentlich einen HASH oder ein ARRAY übergibt (=> zu viele Klammern?). Würde tippen, dass dann was im Log steht.

Wenn man mit der Klammersetzung auf Kriegsfuß steht, ist das verständlich, manche Editoren könnten helfen (angefangen beim Stichwort codemirror), aber zu viel ist zu viel (und unübersichtlich)!

Und wenn die statefile nicht mehr sauber geschrieben wird (?), ist das ein ganz anderes Problem (SD-Karte?).

[Guzzi-Charlie]

Das

Code Auswählen Erweitern

{fhem("set n_goE_charging AnzPha 1")}}
ist tatsächlich falsch. Das müßte natürlich statt "set..." "setreading..." heißen. Den Pfad habe ich bisher nicht benutzt, da mein aktuelles E-Auto 3-phasig lädt.

Code Auswählen Erweitern

AnzPha {3}
soll der Initialzustand für das Reading sein.

Wenn man mit der Klammersetzung auf Kriegsfuß steht, ist das verständlich

Das einem Profi da die Augen tränen kann ich mir schon vorstellen, aber wie gesagt, ich weiß es halt nicht besser und es funktioniert.

Und wenn die statefile nicht mehr sauber geschrieben wird (?)...

DAS ist das Hauptproblem. Ohne diesen Fehler wären die Readings auch nicht verschwunden (möglicherweise durch einen Neustart verursacht). Der statefile wird ja "sauber" geschrieben, aber nicht durch "Save config" Damit wird er sogar explizit "gelöscht". Wie kann das sein, bzw. warum ist das so. Falls Jemand dazu eine Idee hat, dann immer her damit.

Fazit:
Das Problem liegt NICHT an meinem "gewöhnungsbedürftigen" notify, sondern ganz wo anders, also beim Nichtschreiben/Löschen des statefiles durch "Save config". Damit sind natürlich nach einem Neustart alle Werte/Variablen verloren. Kann man dieses Verhalten evtl. irgendwo einstellen?

[Beta-User]

Das wäre das afaik erste Mal, dass "save" (ohne config!) das statefile leert!

Vermutete Ursache war genannt, aber ich glaube noch nicht daran, dass es das ist, bevor hier nicht endlich ein Log-Auszug erscheint!

Das mit dem "Initialwert" klappt so auch nicht, weil bei jedem (!) passenden (=hier: ALLE!) Trigger dieses Reading aktualisiert werden sollte (falls die Syntax nicht an anderer Stelle kaputt ist).

Und wenn es mit den Klammern nicht klappt, könntest du ja mal darüber nachdenken, ob es nicht sinnvoll wäre, eines nach dem anderen mit möglichst wenigen (!!!) Klammern zu machen.

Die Kaskade ist übrigens auch verbesserungsfähig, warum nicht:
Wenn kleiner 6 => 0, sonst Ganzzahl von "durch 2" oä., aber jedenfalls so, dass der erste "ist ok"-Treffer den Rest nicht mehr durchlaufen läßt...

[Guzzi-Charlie]

Das wäre das afaik erste Mal, dass "save" (ohne config!) das statefile leert!

Das ist aber leider definitiv so. Ob ich nun in der FHEM-Oberfläche den "Button" "Save config" betätige oder direkt in die Befehlszeile nur "save" eingebe ist dabei egal. Jedesmal wird das statefile geleert!

Auszug aus Dateimanager vor "save"-Befehl:

Code Auswählen Erweitern

fhem.save 576840 Sep 3 10:30

nach "save"-Befehl ist das statefile leer (bis auf das Datum in der ersten Zeile):

Code Auswählen Erweitern

fhem.save 26 Sep 3 10:36

nach anschließendem {WriteStatefile()} ist das statefile wieder gefüllt:

Code Auswählen Erweitern

fhem.save 576810 Sep 3 10:37

Im Log steht dazu im Moment nichts da verbose auf "0" steht, weil ich gerade noch ein anderes Problem mit der virtuellen piccu3 habe (FHEM sieht den HmIP USB-Stick nicht) und mir das das Log zumüllt. Werde ich aber Heute in Ordnung bringen und dann schalte ich den verbose-Wert auch wieder hoch.

Das mit dem "Initialwert" klappt so auch nicht

D.h. es wäre sinnvoller das userReading nur "leer" anzulegen also "AnzPha {}" und es dann nur durch die Logik füllen zu lassen?

Um die Vereinfachung/Verbesserung des Codes werde ich mich sicher auch noch kümmern, aber das ist ja hier erstmal nicht das Problem.

[Beta-User]

[OT]

FHEM sieht den HmIP USB-Stick nicht

Wie sollte FHEM den erkennen? Der taugt afaik nur (idirekt) als IO für HMCCU.*. Falls du also irgendwas anderes versuchst, bist du auch da an der falschen Stelle unterwegs, und ansonsten sollte es reichen, einfach nur den verbose-Level des IO-Device passend einzustellen, dann würden wir hier nicht den Blindflug gemacht haben.

PS: Eine direkte Rückmeldung zur Anfrage nach dem Log wäre ggf. auch geeignet gewesen, den "beratungsresistent"-Eindruck etwas zu mildern...

[Guzzi-Charlie]

So, der HmIp USB-Stick funktioniert wieder. Es lag am USB-Hub.

Warum soll ich ein Log posten in dem nichts drin steht?

Ich werde jetzt den verbose-Wert hochstellen und dann sende ich auch ein log-Auszug (nach dem Mittagessen).

[Guzzi-Charlie]

So, das ist der ein Auszug des aus dem fhem.log mit verbose=5 am notify. Dieser Block wiederholt sich dann ständig alle paar Sekunden. Ich nehme an immer wenn ein Event von den involvierten Devices erzeugt wird. Fehlermeldungen sehe ich da keine.

Code Auswählen Erweitern

2022.09.03 13:20:33.732 5: Triggering n_goE_charging
2022.09.03 13:20:33.733 4: n_goE_charging exec {
my $AnzPha= (ReadingsNum("n_goE_charging","AnzPha",0));;;;
my $AmpereMax= (ReadingsNum("n_goE_charging","AmpereMax",0)/$AnzPha);;;;
my $AmpereSoll= (ReadingsNum("n_goE_charging","AmpereMax",0));;;;
{if (($AmpereMax) >16) {$AmpereSoll =16}}
{if ((($AmpereMax) >14) && ($AmpereMax) <16) {$AmpereSoll =14}}
{if ((($AmpereMax) >12) && ($AmpereMax) <14) {$AmpereSoll =12}}
{if ((($AmpereMax) >10) && ($AmpereMax) <12) {$AmpereSoll =10}}
{if ((($AmpereMax) >8) && ($AmpereMax) <10) {$AmpereSoll =8}}
{if ((($AmpereMax) >6) && ($AmpereMax) <8) {$AmpereSoll =6}}
{if ((($AmpereMax) >0) && ($AmpereMax) <6) {$AmpereMax =0}}
{if (ReadingsNum("MQTT2_go_eCharger","powerL2_W",0)>0)
   {fhem("setreading n_goE_charging AnzPha 3")}
  else
   {fhem("setreading n_goE_charging AnzPha 1")}}
{if ((($AmpereMax) >0) && (ReadingsNum("MQTT2_go_eCharger", "car", 0) > 0) && (ReadingsNum("Fenecon", "Batterie_Ladestand", 0) > 90))
   {{fhem("set MQTT2_go_eCharger Activation 1")}
    {fhem("setreading n_goE_charging Ampere $AmpereSoll")}
    {fhem("set MQTT2_go_eCharger Ampere $AmpereSoll")}}
else
    {fhem("set MQTT2_go_eCharger Activation 0")}}
}

Aber wie schon festgestellt. Das Problem liegt ja offensichtlich wo anders, nämlich in dem NICHT Schreiben des statefiles durch save. Das ursprüngliche Thema ist damit eigentlich gar keins. Allerdings weiß ich trotzdem im Moment nicht wo ich nach dem eigentlichen Problem suchen soll.

Deshalb nochmal die Frage: Kann das Verhalten des Nichtschreibens des statefile ein Einstellung als Ursache haben?

[DetlefR]

Deaktiviere mal das Notify und sieh mal ob bei

Code Auswählen Erweitern

save irgendwas im Log erscheint

[Beta-User]

Deshalb nochmal die Frage: Kann das Verhalten des Nichtschreibens des statefile ein Einstellung als Ursache haben?

Das bedingt durchaus, dass (erst mal!) keine Reading-Werte bekannt sind, aber im laufenden Betrieb sollten die dann schon kommen - wenn keine Fehler auftreten, die verhindern, dass was geschrieben wird...

D.h. es wäre sinnvoller das userReading nur "leer" anzulegen also "AnzPha {}" und es dann nur durch die Logik füllen zu lassen?

Da steht ein völlig falsches Verständnis dahinter, wie userReadings "ticken": Es gibt keine Initialwerte (die kann man mit "setreading" setzen), und eine (implizite) "undef"-Rückgabe aus dem auszuführenden Code bewirkt schlicht NICHTS, also keine Änderung des vorhandenen (oder eben nicht vorhandenen) Werts.

So, das ist der ein Auszug des aus dem fhem.log mit verbose=5 am notify. Dieser Block wiederholt sich dann ständig alle paar Sekunden. Ich nehme an immer wenn ein Event von den involvierten Devices erzeugt wird.

Genau. Wenn kein NOTIFYDEF gesetzt wäre (ein "list" hätte gezeigt, ob der Teil geklappt hat), wäre das noch deutlich häufiger.

(OT zum atmosphärischen: Es käst mich an, wenn man mehrfach nach Selbstverständlichkeiten fragen muss, es hätte mir direkt gereicht, wenn die Info gekommen wäre, dass (noch) nichts vorhanden ist, weil deaktiviert).

Fehlermeldungen sehe ich da keine.

OK, wenn das alles ist. Damit stellt sich wieder die Frage, was da
- beim exec passiert (kann man ggf. in diesen Fall mehr rauskriegen, wenn man es "so" in die Kommandozeile wirft),
- und warum zu den userReadings nichts zu finden ist; die sollten nämlich auch mitgetriggert werden...

Schlage nochmal vor:

Und wenn es mit den Klammern nicht klappt, könntest du ja mal darüber nachdenken, ob es nicht sinnvoll wäre, eines nach dem anderen mit möglichst wenigen (!!!) Klammern zu machen.

Hilfsmittel: das "trigger"-FHEM-Kommando.

[Guzzi-Charlie]

Das bedingt durchaus, dass (erst mal!) keine Reading-Werte bekannt sind, aber im laufenden Betrieb sollten die dann schon kommen

Hier hast Du mich wohl falsch verstanden. Es geht nicht darum das die Reading-Werte des notify nicht geschrieben werden. Das werden sie sehr wohl. Es geht darum das das statefile mit Absetzten des "save" Befehls geleert wird, obwohl es lt. CommandRef mit save aktuallisiert/geschrieben werden müßte. Vorher war das statefile ca. 600k groß, nach dem save leer. Mit dem manuellen Schreiben mit {WriteStatefile()} wird es wieder gefüllt.

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. In meinem Beispiel sind dei Readings ja voneinander abhängig und ich hatte den Eindruck daß es erst funktionierte nachdem ich mindestens ein Reading per setreading erzeugt hatte.

- beim exec passiert (kann man ggf. in diesen Fall mehr rauskriegen, wenn man es "so" in die Kommandozeile wirft),

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

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.

[Guzzi-Charlie]

Ich habe inzwischen weiter gesucht wegen den "löschen" des statefile nach einem save.

Es gibt folgende Fehlermeldung im Log:

Code Auswählen Erweitern

copy %L/fhem.save ./restoreDir/save/2022-09-03/%L/fhem.save failed:No such file or directory
Da scheint irgendetwas mit den Pfadzuweisungen nicht zu stimmen.

Hier das List vom Global-Device:

Code Auswählen Erweitern

attr global userattr alarmDevice:Actor,Sensor alarmSettings cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global autosave 0
attr global exclude_from_update 98_ModbusSDM220M.pm 99_UtilsHourCounter.pm
attr global language DE
attr global latitude 49,8647
attr global logdir /opt/fhem/log
attr global logfile %L/fhem-%Y-%m.log
attr global longitude 8,62546
attr global modpath .
attr global motd SecurityCheck:\
  telnetPort is not password protected\
  MQTT2_FHEM_Server is not password protected\
\
Protect this FHEM installation by configuring the allowed device allowed_WEB\
You can disable this message with attr global motd none
attr global mseclog 1
attr global room System
attr global stacktrace 0
attr global statefile %L/fhem.save
attr global verbose 1

setstate global no definition



[betateilchen]

Code Auswählen Erweitern

  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.