Hallo,
ich glaube ich brauche mal etwas grundsätzliche Hilfe. Irgendwie habe ich das userreading wohl grundsätzlich nicht verstanden.
Ich habe folgendes notify angelegt um meinen goe-charger zu steuern und den Ladestrom in Abhängigkeit von der PV-Leistung einzustellen:
defmod n_goE_charging notify Fenecon:.*|MQTT2_D1Mini_1F4628:.*|dy_pCounterValues:.* \
{\
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("set n_goE_charging AnzPha 3")}\
else\
{fhem("set 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")}}\
}
attr n_goE_charging disable 0
attr n_goE_charging room 1
attr n_goE_charging userReadings AmpereMax {(round(((ReadingsNum("MQTT2_D1Mini_1F4628","SENSOR_ABB_Active_power_Total",0))\
+(ReadingsNum("Fenecon","EnergieerzeugungDC_W",0))\
-(ReadingsNum("dy_pCounterValues","pNotstromOutL1",0))\
-(ReadingsNum("dy_pCounterValues","pNotstromOutL2",0))\
-(ReadingsNum("dy_pCounterValues","pNotstromOutL3",0)))/\
((ReadingsNum("MQTT2_D1Mini_1F4628","SENSOR_ABB_Voltage_L1",0)+\
ReadingsNum("MQTT2_D1Mini_1F4628","SENSOR_ABB_Voltage_L2",0)+\
ReadingsNum("MQTT2_D1Mini_1F4628","SENSOR_ABB_Voltage_L3",0))/3),0))},\
LadeLeistSoll {(round(((ReadingsNum("MQTT2_D1Mini_1F4628","SENSOR_ABB_Active_power_Total",0))\
+(ReadingsNum("Fenecon","EnergieerzeugungDC_W",0))\
-(ReadingsNum("dy_pCounterValues","pNotstromOutL1",0))\
-(ReadingsNum("dy_pCounterValues","pNotstromOutL2",0))\
-(ReadingsNum("dy_pCounterValues","pNotstromOutL3",0))),0))},\
AnzPha {3}
Das notify funktioniert soweit auch, aber die Readings der "userreadings" verschwinden irgendwann von allein und dann funktioniert das ganze Konstrukt nicht mehr. Wieso verschwinden die Reading denn von allein? Wenn ich die Readings manuell per set-Befehl wieder aktiviere, dann funktioniert es wieder.
Was mache ich denn falsch, bzw. geht das überhaupt so wie ich es gebaut habe?
Du hast auf jeden Fall gefühlt 728 geschweifte Klammern völlig sinnlos verwendet.
Sehr hilfreiche Antwort. :(
Naja, die Antwort war wirklich ernst gemeint. Fang doch mal an, auszumisten und eine korrekte perl-Syntax zu verwenden. Vielleicht löst das schon Dein Problem.
Dein Code-Gefrickel ist sowas von unübersichtlich und chaotisch, dass ich mir das erstmal in einen ordentlichen Editor kopieren müsste, um zu verstehen, was Du da eigentlich tun willst. Und dazu habe ich im Moment weder die Zeit noch die technische Möglichkeit, weil ich gerade unterwegs bin.
sind die readings nach fhem restart weg?
sind sie im file fhem.save?
hast du sie gespeichert?
Die Readings werden ja durch den Eintrag der userreadings, bzw. durch mein setreading... angelegt und durch die Formeln im notify mit Werten gefüllt. Die Config ist natürlich immer gespeichert. Mit einem FHEM Restart hat das nichts zu tun. Wie ich das sehe verschwinden die einfach im laufenden Betrieb. Das file fhem.save ist leer. Das enthält nur eine Zeile, das Datum von Gestern.
#Thu Sep 1 23:59:59 2022
Ich hab da nicht genau hingeschaut, aber das notify hat normal gearbeitet, den goe-charger gesteuert und das Auto (fertig) geladen. Irgendwann danach sind die Readings dann wohl verschwunden. Ob das einen Zusammenhang hat weiß ich nicht. Einen Neustart gab es nicht.
Wie gesagt verstehe ich, glaube ich, den Zusammenhang zwischen dem Anlegen der Readings (per userreading) und dem "Füllen" derselben wohl nicht richtig. Wenn ich ein Reading manuell mit setreading... anlege und es als userreading definiert ist, dann sollte es doch Bestand haben, oder nicht. Wie kann das einfach verschwinden?
Zitat von: Guzzi-Charlie am 02 September 2022, 20:01:26
Die Config ist natürlich immer gespeichert. Mit einem FHEM Restart hat das nichts zu tun. Wie ich das sehe verschwinden die einfach im laufenden Betrieb. Das file fhem.save ist leer. Das enthält nur eine Zeile, das Datum von Gestern.
Wenn Du ein reading (egal wie) erzeugst und mit einem Wert füllst, dann existiert das reading erstmal ausschließlich in der laufenden FHEM Instanz (im Speicher).
Erst durch das Abspeichern (save config) wird das statefile geschrieben, dann werden auch alle zu diesem Zeitpunkt vorhandenen readings dauerhaft gespeichert.
Zitat von: Guzzi-Charlie am 02 September 2022, 20:01:26
Wie ich das sehe verschwinden die einfach im laufenden Betrieb.
Readings verschwinden nicht einfach im laufenden Betrieb. Entweder, das Gerätemodul löscht in den den von ihm angelegten devices alle readings, um selbst neue readings zu schreiben, oder im laufenden Betrieb ist ein restart passiert und das statefile mit den readings war noch nicht abgespeichert.
Zitat... dann werden auch alle zu diesem Zeitpunkt vorhandenen readings dauerhaft gespeichert.
Offensichtlich nicht. Save config mache ich IMMER direkt nach Änderungen. Einen unbemerkten Neustart kann ich zwar nicht ausschließen, aber der sollte ja keine Auswirkungen haben wenn es schon gespeichert war, oder?
Wo kann ich denn nachschauen ob die Readings tatsächlich gespeichert sind?
Wird ein Reading eigentlich überhaupt allein durch das Setzen eines userreadings angelegt, bzw. funktionieren die Formeln (z.B. die in meinem notify) überhaupt wenn die Readings nicht da sind? Ich hatte den Eindruck, daß das ganze notify erst anfing zu arbeiten nachdem ich die Readings manuell per "setreading..." (wieder) angelegt hatte.
Ich werde die Readings nun nochmal manuell anlegen und schauen was passiert.
setreading ist kein userReadings ! Es steht nicht in der config, sondern nur im state(save)-file.
Edit: nur nach WriteStatefile oder sauberem shutdown
Sollte man nicht Popcorn machen?
Per userReading erzeugt man erst Code, der bei einem passenden (! so man trigger verwendet!) Event ausgeführt wird. Steht da (im auszuführenden Code) "Mist" drin, müßte eigentlich (nach einem passenden Event) was im Log zu finden sein, und ich würde stark darauf tippen, dass wir dann wieder bei der Klammersetzung landen...
Diese Beratungsresistenz ist unglaublich...
Ich bin hier raus. Ohne Popcorn.
Entschuldigung daß ich unter "Anfängerfragen" dumme Fragen gestellt habe und mir Hilfe erhofft hatte, aber die FHEM-Gurus scheinen ihr Wissen lieber für sich zu behalten.
Und auf blöde Kommentare kann ich auch gerne verzichten!
Falls sich doch noch Jemand berufen fühlen sollte mir konstruktiv zu helfen, dann gerne. Ansonsten (falls hier ein Mod zufällig den Beitrag ließt) kann der Beitrag komplett gelöscht werden. Danke.
Du hast es vielleicht nicht verstanden/verstehen wollen (trifft es wohl eher) aber dir wurde doch bereits geholfen (in Bezug auf deine gelieferten Infos).
Du frägst nach Problemen mit userReadings aber es ist nichts an Infos zu userReadings zu finden.
Daher der korrekte Hinweis, dass das was du gezeigt hast eben NICHTS mit userReadings zu tun hat.
Und an dem was du gezeigt hast eben einiges "schräg" ist bzw. verbessert werden kann...
Statt das anzunehmen, hast du rumgetönt ;)
Das hier beachtet: https://forum.fhem.de/index.php/topic,71806.0.html
Wo sind z.B. lists der beteiligten Devices? Also dort wo die Readings (vermeintliche userReadings) drin sein sollen und dann einfach verschwinden?
Logauszüge, um vielleicht doch unerwartete Neustarts zu sehen oder andere Auffälligkeiten...
Wenn im state-file NICHTS drin steht, dann ist doch u.U. generell was faul?
Oder hast du KEINE Devices mit Werten/Readings?
Also einfach mal ein wenig die Antworten beachten und "aufräumen", mal bei userReadings nachlesen und v.a. weitere Infos liefern...
...oder halt dann doch lassen.
Gruß, Joachim
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.
Berechne doch "AmpereMax" und "LadeLeistSoll" im Notify und speichere es mit "fhem("setreading ...") in einem der drei Geräte oder zur Not in einem separatem Dummy.
Ansonsten, bei der Verwendung von geschweiften Klammern bist du wirklich sehr großzügig. ;)
Und mach dich mal mit "elsif" vertraut. Das würde die vielen "if " sehr vereinfachen.
Ich habe natürlich schon intensiv (Heute den halben Tag) im Forum und vielen Beiträgen nach möglichen Ursachen gesucht bevor ich den Beitrag verfaßt habe. Ich hatte aber leider nichts gefunden.
...aber dir wurde doch bereits geholfen (in Bezug auf deine gelieferten Infos).
womit wurde mir geholfen?
ZitatDu frägst nach Problemen mit userReadings aber es ist nichts an Infos zu userReadings zu finden.
Daher der korrekte Hinweis, dass das was du gezeigt hast eben NICHTS mit userReadings zu tun hat.
Ich habe doch das komplette Listing des notifys um das es geht gepostet. Es geht genau um die userReadings dieses notify's. Verstehe den Einwand nicht.
ZitatUnd an dem was du gezeigt hast eben einiges "schräg" ist bzw. verbessert werden kann...
Das mag ja sein, aber Niemand sagt was da (wenn überhaupt) falsch sein soll. Vielleicht sind da ein paar Klammern zuviel und man könnte das viel schöner machen, aber es funktioniert. Ich weiß es halt nicht besser.
ZitatStatt das anzunehmen, hast du rumgetönt
Im Gegensatz zu einigen Antworten waren meine Fragen immer höflich, bis auf die letzte natürlich. Wozu frage ich denn nach Hilfe, wenn es am Ende nur dumme Sprüche gibt.
ZitatWo sind z.B. lists der beteiligten Devices? Also dort wo die Readings (vermeintliche userReadings) drin sein sollen und dann einfach verschwinden?
Wie oben schon geschrieben habe ich das list des betroffenen devices (notify) schon mit der Eröffnung des Beitrages gepostet.
ZitatWenn im state-file NICHTS drin steht, dann ist doch u.U. generell was faul?
Das hat mich natürlich auch stutzig gemacht. Da hab ich noch nie reingeschaut. Dazu habe ich aber jetzt etwas festgestellt was eigentlich nicht so sein sollte, denke ich.
Wenn ich in der FHEM-Oberfläche "Save config" anstoße, dann wird das statefile "fhem.save" bis auf die erste Zeile mit dem Datum geleert.
Wenn ich das statefile mit {WriteStatefile()} manuell schreibe, dann wird die Datei gefüllt (auch die userReadings um die es hier geht werden mit gesichert, nachdem ich sie aber vorher per "setreading" wieder angelegt hatte).
In der CommandRef zu "save" steht:
ZitatSichert zuerst das statefile und dann das configfile.
Warum das nicht so ist weiß ich noch nicht.
Wenn mit Save config das statefile nicht nur nicht geschrieben, sondern sogar "gelöscht" wird, dann kann natürlich auch kein Reading/keine Variable überleben. Warum das so ist habe ich noch nicht herausgefunden.
ZitatOder hast du KEINE Devices mit Werten/Readings?
Natürlich habe ich devices, sehr viele sogar, über 200, aber es geht ja nur um das o.g. notify.
ZitatAlso einfach mal ein wenig die Antworten beachten und "aufräumen"
Welche Antworten soll ich denn beachten und was soll ich denn "aufräumen"? Es gab dazu keinerlei konkrete Hinweise.
Ich hätte mir halt konkrete Hilfestellungen, bzw. Hinweise gewünscht wo ich suchen soll und nicht nur blöde Kommentare. Darauf kann ich wirklich verzichten. Wenn Jemand nicht helfen will, oder sich für was Besseres hält, dann soll Derjenige doch einfach die Finger von den Tasten lassen.
ZitatWenn 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.
ZitatAnsonsten, 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.
ZitatUnd 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.
ZitatJa, 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.
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
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:
{fhem("set n_goE_charging AnzPha 1")}}
Und in userReadings:
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?).
Das
{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.
AnzPha {3}
soll der Initialzustand für das Reading sein.
ZitatWenn 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.
ZitatUnd 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?
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...
ZitatDas 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:
fhem.save 576840 Sep 3 10:30
nach "save"-Befehl ist das statefile leer (bis auf das Datum in der ersten Zeile):
fhem.save 26 Sep 3 10:36
nach anschließendem {WriteStatefile()} ist das statefile wieder gefüllt:
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.
ZitatDas 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.
[OT]
ZitatFHEM 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...
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).
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.
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?
Deaktiviere mal das Notify und sieh mal ob bei save
irgendwas im Log erscheint
Zitat von: Guzzi-Charlie am 03 September 2022, 13:32:55
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...
Zitat von: Guzzi-Charlie am 03 September 2022, 10:51:57
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.
Zitat von: Guzzi-Charlie am 03 September 2022, 13:32:55
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).
Zitat
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:
Zitat von: Beta-User am 03 September 2022, 10:22:36
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.
ZitatDas 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.
Zitat- 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.
Ich habe inzwischen weiter gesucht wegen den "löschen" des statefile nach einem save.
Es gibt folgende Fehlermeldung im Log:
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:
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
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.
Nachdem das mit der kaputten statefile klarer ist, nochmal zum Rest:
Zitat
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.
Zitat
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...).
Zitatwie meinst Du das? Was soll ich direkt über die Kommandozeile eingeben/ausführen?
Den auszuführenden Code, den du im notify angegeben hast?!?
Zitat
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....
ZitatBzgl. 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.
Zitatich 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.
ZitattriggeredByDev 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 (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.
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.
ZitatrestoreDir_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.
Zitat von: Guzzi-Charlie am 03 September 2022, 17:28:36
Ich habe jetzt den Standardwert (log/fhem.save) im Global-Device wieder eingesetzt
das ist nicht der Standardwert. Der Standardwert ist
attr global statefile ./log/fhem.save
Zitat von: Guzzi-Charlie am 03 September 2022, 17:28:36
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?
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. :-\
Sorry, der default-Wert war schon richtig eingetragen. Ich hatte wohl nicht alles kopiert.
ZitatEs 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?
ZitatDas 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.
Zitat von: DetlefR am 03 September 2022, 18:14:19
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.
Zitat von: Guzzi-Charlie am 03 September 2022, 18:17:36
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.
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).
/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?
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?