fhem.save bei configDB anzeigen lassen

[Amenophis86]

Ich habe bei jedem neustarte den Fehler:

Code Auswählen Erweitern

2018.02.17 20:10:06 1: configDB: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.

Ich finde aber das Problem nicht. Bei einem Start mit Verbose 5 kommt davor und danach:

Code Auswählen Erweitern

2018.02.17 20:02:08 5: Cmd: >setstate test on<
2018.02.17 20:02:08 5: Cmd: >setstate test 2018-01-20 15:13:11 state on<
2018.02.17 20:02:08 1: configDB: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.


2018.02.17 20:02:08 5: Starting notify loop for global, 1 event(s), first is INITIALIZED
aber ein löschen von test hat nichts gebracht. Daher würde ich mir gerne die Datei fhem.save ansehen, die vermutlich in der DB liegt, oder? Ich gehe mal davon aus, denn die fhem.save Datei im Ordern /opt/fhem/log ist doch wesentlich ältern.

Was ich mir davon verspreche darein zu schauen? Ich würde gerne nach diese Anleitung https://forum.fhem.de/index.php/topic,52187.msg439861.html#msg439861 vorgehen können um den Fehler zu finden. Eine andere Idee habe ich nicht.

Oder ist es so, dass es die Datei bei configDB nicht gibt und alles in der Datenbank selbst gespeichert wird? Dann würde ich mich freuen, wenn mir jemand sagen könnte, wie ich bei meiner SQLite Datenbank nach dem Fehler suchen kann.

[betateilchen]

Es gibt keinen Grund in der Datenbank nach dem Fehler zu suchen, der Fehler kommt nicht aus der Datenbank.
Der gleiche Fehler würde auch auftreten, wenn Du mit fhem.cfg arbeiten würdest.

Was passiert, ist eigentlich einfach erklärt.

Zu dem Zeitpunkt, als das Statefile zum letzten Mal geschrieben wurde, (regelmäßig passiert das bei einem "save config") gab es in Deiner FHEM Installation ein device namens "test" dessen state gesichert wurde.

Nach dem Neustart wird versucht, diesen state wiederherzustellen. Wenn es das device nun nicht mehr gibt, kommt es zu dieser Fehlermeldung.

aber ein löschen von test hat nichts gebracht.

Hast Du nach dem Löschen des device ein "save config" ausgeführt, damit ein neues statefile geschrieben wird? Dann sollte nach einem Neustart keine dieser Meldungen mehr auftauchen.

[Amenophis86]

Ja, habe ich gemacht. Habe auch gerade nochmal ein save gedrückt (vorher auf Verbose 5 gestellt) und neugestartet. Nun ist vor der Zeile folgendes zu lesen:

Code Auswählen Erweitern

2018.02.18 13:19:05 5: Cmd: >setstate rr_Etienne 2018-02-17 13:45:03 presence present<
2018.02.18 13:19:05 5: Cmd: >setstate rr_Etienne 2018-02-17 13:45:03 state home<
2018.02.18 13:19:05 5: Cmd: >setstate rr_Etienne 2017-04-02 11:13:50 wayhome 0<
2018.02.18 13:19:05 1: configDB: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.


2018.02.18 13:19:05 5: Starting notify loop for global, 1 event(s), first is INITIALIZED
2018.02.18 13:19:05 5: createNotifyHash

Das heißt ich denke nicht, dass es an einem Device liegt, sondern doch eher in der DB etwas falsch abgespeichert wurde. Oder hast du noch eine Idee wie ich den Fehler finden kann? Würde mich ja wundern, wenn es erst das Device test gewesen sein soll und nun rr_Etienne. Normal müsste der Fehler doch auch das Device benennen, welches den Fehler verursacht und nicht nur <name> schreiben, oder?

[betateilchen]

In der Datenbank wird nichts falsch abgespeichert. Es wird das abgespeichert, was die FHEM-eigene Funktion "WriteStateFile" in Deinem FHEM findet. Die Fehlermeldung, die Du da siehst, wird nicht von configDB erzeugt, sondern von fhem.pl. configDB schreibt die Meldung nur ins Log.

Du kannst folgendes tun:

• attr global configfile fhem.cfg
• attr global statefile ./log/fhem.save
• save
• attr global configfile configDB

Danach hast Du das fhem.save Deines aktuell laufenden FHEM in ./log/fhem.save und kannst dort schauen, ob Dir etwas ungewöhnliches auffällt. Eventuell gibt es eine nicht vollständige Zeile (Name oder Wert fehlt)

Die Fehlermeldung wird nur ausgegeben, wenn die Zeile unvollständig ist:

Code Auswählen Erweitern


  my @a = split(" ", $param, 2);
  return "Usage: setstate <name> <state>\n$namedef" if(@a != 2);


Dabei wird nicht unterschieden, ob der Name oder der Wert fehlt.

Die fhem.save enthält grundsätzlich den gleichen Inhalt, der auch in der Datenbank geschrieben wird.

[Amenophis86]

Das es nicht an der DB selbst liegt hatte ich verstanden, mir ging es darum, wie ich quasi in die DB schauen kann bzw wo ich da suche muss um die Werte zu finden, welche normal im Savefile liegen würden. Da es das defakto bei der DB Nutzung in diesem Sinne nicht gibt. Und damit ich genau diese Schritte gehen kann

Ich danke für die Anleitung und werde so heute Abend mal vorgehen und schauen, ob ich was finde.

Edit:
Mmmmh auf die Schnell nix auffälliges gefunden. Aber die letzte Zeile ist eine komplette leere Zeile. Kann hier der Fehler liegen?

Edit:
Also ich habe in fhem.save die Leerzeile gelöscht und dann Fhem mit der cfg gestartet. Der Fehler war weg. Dann dachte ich mir ok, änderst du wieder das statefile in configDB mittels

Code Auswählen Erweitern

attr global configfile configDB und speicherst, damit du wieder mit der DB arbeiten kannst. Klappt nicht, lässt fhem abstürzen Jetzt muss ich mal schauen, wie ich nun hinbekomme den aktuellen Stand in configDB zu bringen und ob dann der Fehler weg ist.

Danke schon mal für die Hilfe.

[betateilchen]

Schau mal ins Logfile, warum FHEM abstürzt.

Dann dachte ich mir ok, änderst du wieder das statefile in configDB mittels

Code Auswählen Erweitern

attr global configfile configDB

Damit änderst Du nicht das Speichern der statefile. Und dieses Attribut selbst wird nie mit abgespeichert. Ob FHEM mit fhem.cfg oder configDB gestartet wird entscheidet sich beim Starten von FHEM selbst, je nachdem wie man FHEM aufruft.

Es gibt für Notfälle eine Rescue-Option für configDB, mit der man FHEM starten kann, ohne das statefile auszuführen.

• Systemvariable setzen: "export cfgDB_nostate=1"
• fhem von der Systemkonsole starten: "perl fhem.pl configDB"

Danach sollte Dein FHEM erstmal wieder laufen und beim nächsten "save config" wird ein neues statefile geschrieben.

Nicht vergessen: danach FHEM wieder beenden und die Umgebungsvariable mit "unset cfgDB_nostate" wieder löschen!

[betateilchen]

Aber mal ganz grundsätzlich:

Die Meldung im Log ist nichts, worüber man sich wirklich Gedanken machen  Es ist eben ein Hinweis, dass bei der Abarbeitung des statefiles eine Zeile nicht verarbeitet werden konnte. Deshalb ist aber die Funktion von FHEM oder der definierten devices in keinster Weise negativ beeinflusst.

Aber die letzte Zeile ist eine komplette leere Zeile. Kann hier der Fehler liegen?

Dann sollte die Meldung ja in jeder Installation auftauchen - was aber nicht der Fall ist.

[Amenophis86]

Mmmmh wenn ich das mit der Umgebungsvariable mache, dann kommt als Ausgabe auf der Console:

Code Auswählen Erweitern

looking for table: fhembinfilesave
testing: #2
table not found


schätze das soll so sein. Komischerweise kommt beim starten von FHEM mittels

Code Auswählen Erweitern

sudo perl fhem.pl configDB trotzdem weiterhin die Warnung von setstate, als ob er doch mit einem "statefile" startet. Ich habe auch nochmal gecheckt, ob die Variable gesetzt ist mit

Code Auswählen Erweitern

echo $cfgDB_nostate und es kommt 1 als Antwort.

Edit:
Das mit der Leerenzeile war nur ein Vermutung, daher die Frage, ob das normal ist
Klar ist es nix schlimmes, aber es nervt mich und etwas ist ja nicht so, wie es sein soll

Edit:
Ok, ich habe keinen Plan woran es liegt. Ich habe inzwischen sogar die configDB Dateien gelöscht und configDB neu angelegt. Sobald ich nach migrate mit configDB neustarte kommt der Fehler wieder. Das gibt es doch nicht.

Edit:
Du magst mich gerne für blöd halten, aber der Fehler kommt wirklich nur noch, wenn ich mit configDB starte und nicht mehr, wenn ich mit fhem.cfg starte. Und das egal, ob es mit einer neu angelegt DB, oder meiner alten ist.

[Amenophis86]

Scheiß die Wand an. Ich habe den Fehler gefunden. Ich habe mittels eines Programms die SQLLite Datenbank angeschaut und das Device gefunden, welches kein state hatte. Habe ein state gesetzt und jetzt ist der Fehler weg. Warum auch immer alles andere vorher nicht geklappt hat. Egal, jetzt habe ich es.

Ich danke dir für die Hilfe Udo.

[betateilchen]

Hatte das device dann überhaupt keine readings?

Das wäre ein Sonderfall, den man durchaus abfangen könnte.

[Amenophis86]

Das Device hatte Readings. Nur das Reading state und das Internal STATE war leer. Warum es allerdings in der DB immer leer geblieben ist und bei einem Schreiben des statefile nicht erschließt sich mir einfach nicht. Wenn ich Zeit habe werde ich das auf meinem Test System nochmal angehen.

Was allerdings hilfreich wäre, wenn der Fehlermeldung den Namen des Device ausgeben würde, welches dem Fehler verursacht. Das würde viel Suchen sparen

[rudolfkoenig]

Was allerdings hilfreich wäre, wenn der Fehlermeldung den Namen des Device ausgeben würde, welches dem Fehler verursacht.

Normalerweise werden solche Fehler gemeldet, wenn der Benutzer was Falsches in der Eingabezeile tippt. Und da weiss er noch, was er gerade eingegeben hat, eine Wiederholung der Eingabe schaut merkwuerdig aus. Bin nicht sicher, ob eine "haessliche" Ausgabe im Normalfall es Wert ist, die Suche in Spezialfaellen zu beschleunigen.

Aber falls noch Andere der Ansicht sind, dass ich die Eingabe in der Fehlermeldung wiederholen soll, dann werde ich das einbauen.

[Amenophis86]

Verstehe nicht ganz was du mit "hässliche Ausgabe" meinst. Aktuell sieht der Fehler bei einem Statefile-Fehler so aus, dass nicht <name> an der entsprechenden Stelle steht, sondern ein doppeltes Leerzeichen. Man könnte jetzt natürlich die Abfrage anpassen, welche tested, ob initialized schon durch ist. Wenn ich es richtig sehe, dann passiert das erst danach. Sollte dies der Fall sein, dann könnte man den Namen des Device mit ausgeben und ansonsten den "normalen" Fehler Text anzeigen.

Ich habe das Problem im Forum natürlich gesucht gehabt und es hatte schon ab und an mal jemand gehabt und konnte damit nix anfangen, wenn es nach dem Start gekommen ist. Und es bleibt einem dann auch nix anderes übrig, als sich das statefile anzuschauen, oder die DB zu öffnen und jedes einzelne Device durch zu suchen um zu finden wo ein Wert fehlt. Das war schon wirklich nervig. Daher mein Vorschlag entweder wie oben, oder z.B. eine Suchfunktion dafür? Überlege gerade ob ich das mit list und nem Filter gefunden hätte, weiß nur noch nicht welche regex ich nutzen müsste um ein Reading zu finden, welches leer ist. Es ist ja nicht mal ein Leerzeichen eingetragen gewesen.

[betateilchen]

Lasst mich das bitte erstmal genauer anschauen, bevor Rudi wieder irgendeinen Schnellschuss macht, der am Ende doch nichts hilft, wenn configDB im Einsatz ist. Offenbar tritt das Problem ja nur dann auf.

Was allerdings hilfreich wäre, wenn der Fehlermeldung den Namen des Device ausgeben würde

Wenn das Problem aber schon beim Schreiben des statefile auftritt und der Name dadurch überhaupt nicht im statefile steht, kann er später auch beim "setstate" nicht ausgegeben werden.

[Amenophis86]

Also im Vorliegendenfall war es so, dass ein MQTT Device (SO_Drucker) in der DB hinterlegt war mit

Code Auswählen Erweitern

setstate SO_Drucker dies hat dazugeführt, dass immer wieder der Fehler kam. Dazu kommt, dass bei verbose 5 der Fehler immer erst am Ende aller setstate Befehle geschrieben wurde und nicht in dem Moment, wo quasi diese Zeile dran war.

Ob der Fehler nur bei configDB kommt würde ich aktuell nicht beschwören. Das hat mich die ganze Zeit gewundert und ich kann aktuell noch nicht erklären, warum es bei configDB so war und beim statefile nicht. Ich glaube noch, dass das setzen der Umgebungsvariable nicht wirklich funktioniert hat und daher das statefile nie neu geschrieben wurde.

[betateilchen]

Nochmal:

Lasst mich das bitte erstmal genauer anschauen

Ich glaube noch, dass das setzen der Umgebungsvariable nicht wirklich funktioniert hat und daher das statefile nie neu geschrieben wurde.

Du hast ja auch nicht das gemacht, was ich Dir geschrieben hatte, da brauchst Du Dich nicht wundern, wenn nicht das passiert, was passieren soll.

[Amenophis86]

Du hast ja auch nicht das gemacht, was ich Dir geschrieben hatte, da brauchst Du Dich nicht wundern, wenn nicht das passiert, was passieren soll.

Was habe ich denn falsch gemacht?

[rudolfkoenig]

Man könnte jetzt natürlich die Abfrage anpassen, welche tested, ob initialized schon durch ist. Wenn ich es richtig sehe, dann passiert das erst danach. Sollte dies der Fall sein, dann könnte man den Namen des Device mit ausgeben und ansonsten den "normalen" Fehler Text anzeigen.

Habe diesen Vorschlag eingebaut. Falls im fhem.cfg "setstate bla" steht, dann ist die Fehlermeldung:

2018.02.20 10:03:41.657 1: configfile: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by comma (,) or a regexp. See the devspec section in the commandref.html for details.
Bogus command was: setstate bla

[Amenophis86]

Top, dank dir.

[betateilchen]

Falls im fhem.cfg "setstate bla" steht, dann ist die Fehlermeldung:

Wenn im fhem.cfg "setstate bla" steht, haben wir ein ganz anderes Problem.

Meines Erachtens wäre es sehr viel sinnvoller gewesen, das Problem schon beim Schreiben des statefile abzufangen, damit so ein Müll dort gar nicht erst landet. Aber da hier ohnehin jeder macht, was er will, ist mir das jetzt auch wurscht.

[Amenophis86]

Nochmal Udo, du darfst mir gerne sagen was ich falsch gemacht habe, aber bis dato kam leider noch keine Antwort von dir. Natürlich bin ich auch froh, wenn der Fehler verhindert und nicht nur ausgegeben wird.

[betateilchen]

Du hattest einfach den Zusammenhang zwischen den Umgebungsvariablen, den gesetzten Attributen und dem Verhalten von FHEM nicht verstanden und etwas vor Dich hingewurschtelt, wovon in meinem Hilfeversuch nicht die Rede war.

Egal, Dein Problem ist ja gelöst. Trotzdem frustriert mich das jetzige Ergebnis einmal mehr - denn genau das, was Rudi jetzt gemacht hat, wollte ich eigentlich vermeiden. Das Einzige, worum ich gebeten hatte, war etwas Zeit, damit ich das Verhalten nachstellen kann. Aber nichtmal mehr DAS ist inzwischen noch möglich.

[betateilchen]

Für configDB habe ich jetzt die URSACHE des Problems behoben. Es sollten nun keine Einträge mehr in das statefile geschrieben werden, die nicht der gültigen Syntax für "setstate <name> <data>" entsprechen.

[Amenophis86]

Ich bin gerne bereit unabhängig des Problems nochmal mit dir alles richtig durchzugehen um zu verstehen, was ich scheinbar noch nicht verstanden hatte. Mir war nicht ganz klar was ich falsch gemacht hatte und warum insbesondere der Teil mit der Umgebungsvariable nicht funktioniert hat.

Zu der Sache mit Rudi halte ich mich raus. Ich bin für meinen Teil froh, dass du das Problem an der Wurzel gepackt hast um den Fehler zu verhindern und bis dahin war ich froh, dasss Rudi es ermöglicht, dass zumindest das Device angegeben wird und weder ich noch andere eine ewig lange Liste durchgehen müssen um es per Hand zu finden.

[betateilchen]

dass zumindest das Device angegeben wird und weder ich noch andere eine ewig lange Liste durchgehen müssen um es per Hand zu finden.

Naja, aber das löst doch überhaupt nicht das eigentliche Problem.

Die Tatsache, dass ein device kein Internal STATE hat (nur dann konnte es überhaupt zu der Meldung kommen) ist an sich ja überhaupt kein Fehler, sondern vollständig FHEM-konform. Nirgends steht geschrieben, dass dieses Internal verpflichtend vorhanden sein muss. Mit Deinem manuellen Setzen dieses Wertes wird zwar die Meldung vermieden, aber ob das die Lösung ist, die sich ein Entwickler bei diesem device gedacht hat, steht auf einem völlig anderen Blatt.

[Amenophis86]

Ich weiß gerade nicht, ob ich das mal geschrieben habe. Das Device war ein MQTT Device und der Grund warum das INTERNAL leer geblieben ist lag vermutlich daran, dass das JSON nicht richtig aufgelöstwerden konnte, oder ich damals das attr für stateformat geändert hatte auf das falsche Reading. Kann ich nicht mehr genau sagen.

[rudolfkoenig]

Meines Erachtens wäre es sehr viel sinnvoller gewesen, das Problem schon beim Schreiben des statefile abzufangen, damit so ein Müll dort gar nicht erst landet.

In WriteStateFile/GetAllReadings wird seit laengerem relativ viel Muehe darauf verwendet, dieses Problem zu vermeiden:
- es wird kein Geraet geschrieben, was nicht existiert
- es wird kein STATE geschrieben, wenn es nicht gesetzt ist
- falls STATE nur Leerzeichen und Tabs enthaelt, dann wird das zu Oktalnotation (\040) konvertiert, und beim Einlesen wieder zurueck.

Ich kann z.Zt. keinen Fall vorstellen, eine kaputte setstate Zeile per FHEM generieren zu lassen, es sei denn man verwendet unfaere Methoden wie

Code Auswählen Erweitern

{ $defs{" "} = $defs{dummy} }