fhem.save bei configDB anzeigen lassen

[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} }