fhem.save bei configDB anzeigen lassen

Begonnen von Amenophis86, 17 Februar 2018, 20:36:50

Vorheriges Thema - Nächstes Thema

Amenophis86

Ich habe bei jedem neustarte den Fehler:
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:
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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

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.

Zitat von: Amenophis86 am 17 Februar 2018, 20:36:50
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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:

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?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

betateilchen

#3
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:


  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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Amenophis86

#4
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 attr global configfile configDB und speicherst, damit du wieder mit der DB arbeiten kannst. Klappt nicht, lässt fhem abstürzen :D 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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

betateilchen

Schau mal ins Logfile, warum FHEM abstürzt.

Zitat von: Amenophis86 am 18 Februar 2018, 13:38:23
Dann dachte ich mir ok, änderst du wieder das statefile in configDB mittels 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!
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.

Zitat von: Amenophis86 am 18 Februar 2018, 13:38:23
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Amenophis86

#7
Mmmmh wenn ich das mit der Umgebungsvariable mache, dann kommt als Ausgabe auf der Console:
looking for table: fhembinfilesave
testing: #2
table not found


schätze das soll so sein. Komischerweise kommt beim starten von FHEM mittels 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 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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

betateilchen

Hatte das device dann überhaupt keine readings?

Das wäre ein Sonderfall, den man durchaus abfangen könnte.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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 :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

rudolfkoenig

ZitatWas 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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

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.

Zitat von: Amenophis86 am 19 Februar 2018, 06:18:43
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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Amenophis86

Also im Vorliegendenfall war es so, dass ein MQTT Device (SO_Drucker) in der DB hinterlegt war mit 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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...