statefile/setstate und Leerzeichen

Begonnen von jmike, 27 November 2016, 20:00:29

Vorheriges Thema - Nächstes Thema

jmike

Hi.

Wollte das nicht gleich als Patch kennzeichnen aber ich habe immer wieder mal "statefile: Usage: setstate <name> <state>" im Log und nun herausgefunden dass die Ursache Devices mit State " " sind.

Das Leerzeichen kommt von einem concat zweier Variablen, wo es offensichtlich ab und zu dazu kommt dass beide leer sind (allá $state = $var1." ".$var2;).
Auch wenn das explizit eine Modulsache ist, könnte GetAllReadings das ja alternativ auch handeln.

Habe meinen "fix" mal als Patch angehängt, hauptsächlich zur Verdeutlichung.
Eventuell ist es ja fhem.pl würdig ;)

lg

rudolfkoenig

Bin nich unsicher, ob das gefixt werden soll, ein leeres state sagt dem Benutzer ja nichts.
Ja, eigentlich muesste das beim Setzen abgefangen werden, und nicht erst beim Einlesen aus der statefile.
Andere Meinungen?

Dr. Boris Neubert

ceterum censeo...

Inhalte der fhem.save-Datei perl-kodieren  ;) mit einem extra für \040.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

Zitat von: jmike am 27 November 2016, 20:00:29
Auch wenn das explizit eine Modulsache ist,

Ich sehe das auch eher als Aufgabe für das "verursachende" Modul.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Wenn wir Cato mal ausser Acht lassen: was soll der Benutzer (bzw. notify/FileLog/SVG/etc) mit einem leeren Status anfangen?

Ich haette gerne sichtbare Status, und einzeilige, lesbare Events. Bin noch unsicher, ob das FHEM Framework allerlei Unsinn abfangen soll, nur damit es (auf Kosten von Performance und Komplexitaet) die Haende in Unschuld waschen darf, und das Problem auf nachfolgende Module und dem Benutzer verschiebt.

Vielleicht habe ich aber was verpasst, und jemand kann mir erklaeren, dass sowas in bestimmten Faellen sinnvoll ist.

Dr. Boris Neubert

Hallo,

zum einen stimme ich zu, dass im state ein aussagekräftiger Wert stehen sollte und ein Leerzeichen erfüllt das nicht.

Zum anderen bin ich der Auffassung, dass FHEM als Framework den Modulen keinerlei Einschränkungen bzgl. der Zeichen in Readings, Attributen, Defines, Kommandos etc. auferlegen sollte.

Performancerelevant sind ja nur häufig wiederkehrende Aktionen. Attribute setzen, Geräte definieren, Kommandos absetzen, Konfiguration laden und speichern sind m.E. nicht performancerelevant. Readings setzen und Log schreiben schon.

Beim Reading setzen muss das Modul den Wert vorgeben, eine Intervention von FHEM ist störend, also keine Maskerade nötig. Beim expliziten Log schreiben verlangen wir, dass das Modul die kritischen Passagen maskiert - das meiste ist ja eh Plaintext. Bleibt noch das implizite Logging in fhem.pl. Da hast Du nebenan auf den verbose-Level geprüft, um überflüssige Wandlungen zu ersparen - ich denke, dass sich das in den Griff bekommen lässt.

Diskussion sollten wir m.E. nebenan fortführen.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

justme1968

ein leerer STATE ist manchmal sinnvoll. siehe den thread mit dem range slider.

aber STATE mit leerzeichen ist nicht das gleiche wie ein leerer state.

das problem oben könnte man lösen in dem man statt " " "&nbsp;" beim aneinanderhängen der strings verwendet. das wäre aber fhemweb spezifisch.

ich bin der meinung fhem sollte keine einschränkungen hinsichtlich der erlaubten zeichen machen und auch leerzeichen erlauben. d.h. beim laden, speichern, loggen,... sollte es kein (sonder)zeichen geben das nicht erlaubt ist.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

es gibt auch (Media)Module, die als Value ein Leerzeichen oder gar ein leeres Value setzen (nicht zu verwechseln mit undef), da bei der Anzeige der Values davon ausgegangen wird, dass es aus optischen Gründen für den Benutzer ansprechender ist. Ein gutes Beispiel dafür ist das SONOS Modul, aber ich habe das auch in einige Media-Module übernommen, in denen zuvor sonst in solchen Fällen ein "-" angezeigt wurde (beispielsweise beim Rewrite des ONKYO_AVR Moduls). Ich würde es daher begrüßen, wenn leere Readings auch als "Platzhalter" erhalten bleiben würden, auch nach einem Neustart. Nichts ist ärgerlicher, als sich ständig löschende Readings. Ihr sagt ja immer so schön Attribute gehörten dem User, ich sehe es bei einmal angelegten Readings ähnlich (sofern sie vom Modul verwendet und/oder "irgendwann" auch befüllt werden).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

Leeres STATE wird nicht geschrieben, verursacht also keine Fehlermeldung (ob das korrekt ist, ist eine andere Geschichte).

Ich habe fhem.pl erweitert, dass beim save STATE Werte, die nur space und tab enthalten, als \040 und \011 geschrieben werden. Falls die setstate Anweisung fuer State (also ohne Datum) nur diese Zeichen enthaelt, wird das zu space und tab zurueckkonvertiert.

Falls jemand Probleme sieht, oder eine bessere Loesung, her damit.