HomeMatic-Forum / FHZ-Forum

Ist bestimmt schon bekannt, aber mich hat es das eine und andere Mal stolpern lassen.

Ob eine Systemvariable leer ist, prüft man in Scripten am besten mittels einfachem boolschen Ausdruck und nicht einem Leerstring Vergleich. Wenn nämlich die Systemvariable nicht gesetzt ist, dann ist deren Inhalt nicht mit einem leeren String identisch (anders als in allen Programmiersprachen die ich kenne).

deine Ausführung ist.... falsch

string sysvar = dom.GetObject("Systemvar");

das da weist sysvar ein object zu mit der referenz auf sysvar zu. existiert sysvar nicht, ist das null

sysvar selber enthält KEINEN string, auf den Inhalt von Sysvar kommt du erst mit der methode .State ().

Black

Black hat geschrieben: ↑

16.08.2019, 10:14

deine Ausführung ist.... falsch
string sysvar = dom.GetObject("Systemvar");
das da weist sysvar ein object zu mit der referenz auf sysvar zu. existiert sysvar nicht, ist das null

Ich hatte ".Value()" vergessen. Habe meinen ursprünglichen Code angepasst.
Die Grundproblematik bleibt die selbe. Undefinierte Systemvariablen vom Typ Zeichenkette sind nicht identisch mit einer leeren Zeichenkette.

richtig, uninitialisierte String Systemvariablen haben den Wert ???

siehe hier:
Wenn man die in einem Script selber anlegt, sollte man da auch die Startwerte mitgeben.

und boolscher vergleich auf eien String angewand ergbit:
Leerstring (Bool = falsch)
irgendwas drin (Bool=true)

Black

Das kuriose ist aber eben, dass uninitalisierte Systemvars über WriteLine zwar einen Leerstring ausgeben (und nicht etwa ???)
Im boolschen Vergleich sind jedoch ein leerer String und ein unitialisierte Systemvariable gleich.
Daher sollte man diese immer nur mit einem boolschen Vergleich überprüfen (da man nie sicher sein kann, ob sie initialisiert wurde).

die sysvar die ich eben gepostet habe, hatte ich grad mal 20 sekunden vorher angelegt...

mach mal spasseshalber, leg ne neue sysvar Typ String an und sag dann mal was du da siehst... solten die "drei Fragezeichen" sein

Ja das ist korrekt. Habe es gerade mal probiert. Warum sollte dieses Verhalten von Systemvariablen eigentlich sinnvoll sein?

pke hat geschrieben: ↑

16.08.2019, 23:55

Warum sollte dieses Verhalten von Systemvariablen eigentlich sinnvoll sein?

Wieso stellt sich diese Frage überhaupt? Wird eine Systemvariable erstmalig angelegt, dann hat sie den Status "???". Ist sie erstmalig beschrieben und anschließend geleert, ist sie eben leer und weist "nie" wieder den Status "???" auf. Insofern ist dieses Verhalten in der Praxis absolut irrelevant und braucht eigentlich nicht betrachtet zu werden.

Gruß Xel66

Für die, die es genau wissen wollen hat Badenpower im FHEM Forum einen entsprechenden Post hinterlassen.

Siehe:
https://forum.fhem.de/index.php/topic,1 ... #msg967616

Ich finde es immer noch Schade dass er hier "verbannt" wurde ..... sein Wissen fehlt hier einfach !

den fhem Artikel mal inhaltlich nicht kommentiert aber:

hier redete man von dem normalen Weg des Anlegens über die WebUI. Ich weiss dann schon dass das die 3 fragezeichen ergibt.

Und wenn ich über dom.CreateObject () eine Sysvar anlege, weiss ich auch ,dass dann jegliche einstellung selber gemacht werden muss. (das macht schliesslich die Restore Funktion des SDV auch).

in soweit ein schönes WE, Black

(eine der Lösungen ,dass nicht initialisiert heist nicht zugewiesen, wurde, ist auch in der Hardcopy vom SDV zu erkennen --> LastTimeStamp, so man mit State () schreibt)

sollte es sich dabei allerdings um eine via CreateObject() via Script angelegte Systembariable handeln, ist dort TimeStamp nach dem iniialen Anlegen und vor der ersten Verwendung von State () "1970-01-01 01:00:00" ... wobei mir die ganze Problematik nicht klar ist: Wenn man die selber via Script anlegt,kann man die ja wohl auch selber initialisieren. Für eine String Sysvar musst du eh mindestens die Zeilen
svObj.ValueType(ivtString);
svObj.ValueSubType(istChar8859);
schreiben. da ist die Zeile svObj.State (""); für nen Leerstring ja nicht mehr die grosse Schwierigkeit. Is nur meine Meinung ^^