Wenn sich der Datentyp einer Variablen ändert (z.B. von string mit „true“/„false“ nach boolean mit true/false) dann wird die existierende Statusvariable ohne Nachfrage gelöscht und eine neue mit einer neuen ID angelegt.
Das ist sehr unschön, da dadurch die aufgebauten Referenzen (Links, Programmcode, Events, Archiv etc) kaputt gehen.
In meinem Fall habe ich gerade durch eine Umkonfiguration auf der Senderseite dadurch zahlreiche Variablen verloren
Stattdessen fände ich es wesentlich eleganter, wenn bei sich änderndem Datentyp die alte Variable nicht gelöscht, sondern nur der Ident umbenannt würde. Das würde die Handhabung wesentlich vereinfachen.
So ist es. Entschuldige, das habe ich vergessen zu erwähnen.
Aber es passiert auch, wenn man den Datentyp festgelegt hat und später ändert. Da ist es sicherlich nicht so gravierend, da es sich ja nur um eine einzelne Variable handelt. Aber so schön ist es auch nicht.
Vor allem weil Default „String“ ist. Fachlich ist das ja korrekt.
Aber für unsere Zwecke wird wäre Float oder Integer als Default besser.
Hab mich da auch schon oft geärgert. → Variabel angelegt → umbenannt → verlinkt → Archiv eingschaltet → konfiguriert um dann irgendwann dann später festzustellen das ich beim erstellen vergessen habe „Float“ auszuwählen. Alles von vorne …
Ich habe leider gerade schon wieder einen unangenehmen Fall, wo einfach eine Statusvariable gelöscht und eine neue angelegt wird.
Ich binde über ESPAltherma eine Daikin Heizung ein, was auch wunderbar funktioniert. Bis heute morgen die Außentemperatur negativ wurde.
Bislang war die Statusvarariable „Au__entemp_“ vom Typ Float, da die Werte mit z.B. "
"Außenlufttemp.":10.5
hereinkommen. Heute morgen war die Variable plötzlich gelöscht und eine neue Variable ist angelegt. Die ist aber nun vom Typ String.
Die negative Werte kommen eigentlich korrekt:
"Außenlufttemp.":"-1.5"
oder
"Außenlufttemp.":"-1"
Ist das noch ein Fehler?
Burkhard
Ergänzung: Auf dem System ist noch 6.2
Ergänzung 2: Inzwischen kam der Wert
"Außenlufttemp.":0
Nun ist es ein Integer. Ich vermute, gleich kommt 0.5, dann wird es wieder ein Float sein
Inzwischen habe ich aber verstanden, dass die Ursache in ESPAltherma liegt, da negative Werte offensichtlich als String gesendet werden.
Sehr unangenehm bleibt aber, dass die Variablen immer gelöscht und mit neuem Typ angelegt werden … Das macht auch die Fehlersuche sehr aufwändig.
Das Problem ist, dass der JSON Dekoder irgendeine Logik haben muss, wie er die Daten anzeigt. Und wenn der Typ nicht stimmt, müssen wir wir diesen ja anpassen - ansonsten können wir die Daten nicht wirklich anzeigen.
Das einzige, was ich meiner Meinung nach sinnvoll machen kann, ist ein Flag einzubauen, dass keine Änderungen vorgenommen werden. D.h. es gibt Fehlermeldungen, wenn der Typ nicht stimmt im Log, aber ihr verliert die Daten nicht.
Ein String, der eine Zahl REPRÄSENTIERT könnte imho auch weiterhin versucht werden in den Typ konvertiert zu werden. Klar, ggf. verschwinden Nachkommastellen, aber besser als nichts.
Fehlermeldung zusätzlich wäre natürlich sinnvoll.
Irgendeine Logik bräuchte es dann, in der ich den Datentyp auch vorauswählen kann (z.B: aktuell kommen nur ganze Zahlen → int wird erkannt, ich weiß aber, dass auch float möglich wäre). Bevor dann irgendwann nach vielen gesammelten Daten und verwendeten IDs die Umstellung passiert, wäre es sinnvoll das am Anfang per Hand umzustellen).
Da fällt mir generell ein: Gibt es einen dringenden technischen Grund, wesshalb ich den Variablentyp in den alllgemeinen Variableneinstellungen nachträglich nicht ändern kann? Ich bin mir um die Nebenwirkungen durchaus bewusst. Kleiner Warnhinweis nach dem Ändern: Sind sie sich dieses schwerwiegenden Eingriffs bewusst, wäre vielleicht eine Möglichkeit?
Im Vordergrund sollte stehen, dass Variablen auf keinen Fall gelöscht werden. Denn das ist wirklich unangenehm, da man ja bei gelöschten Variablen ID’s nicht mehr nach Referenzen suchen kann.
Ich würde mir wünschen, dass statt Löschen und Neuanlegen lediglich der Ident der Variablen geleert wird und dann eine neue Variable angelegt wird. Wenn das dann noch mit einer Fehlermeldung verbunden wäre, dann könnte man leicht dem Fehler nachgehen und hätte auch noch alle Referenzen auf die alte Variable zur Verfügung.
Ich möchte das Thema mal wieder hochholen, da es mich gerade wieder Arbeit gekostet hat.
Unbemerkt wurde wieder eine Variable gelöscht. Dieses mal ist es erst nach ein paar Wochen aufgefallen. Das ist wirklich unangenehm, da man in alten Settings wühlen muss um herauszufinden, wie denn die alte Variable mit welchem Namen/Profil/Archivierung etc. existiert hat.
Im zweiten Schritt muss man dann versuchen, manuell die Referenzen zu finden. Nicht so cool.
Wenn du das Symbol ONEVAL_ONETOPIC definierst, hast du pro Wert ein Topic und kein JSON.
Oder du fixt sein sprintf hier, so dass immer eine xy.0 rauskommt bei Float
Man kann tatsächlich JSON beibringen Float und int zu unterscheiden, Symcon kann das auch. Habe ich selber schon beim Datenaustausch mit Systemen erlebt, welche zwingend Float brauchen.
Michael
In meinem mittlerweile obsoleten MQTT-Brokerskript war es m.E. so gelöst, dass er bei existierender Variable immer zunächst versucht hat, auf deren Datentyp zu casten und wenn das Ergebnis (zurückgecastet auf empf. Datentyp) ungleich empf. Wert war, wurde zusätzlich eine Variable des zuletzt empfangenen Datentyps angelegt. Ident war jeweils der gleiche, aber mit Suffix für den Datentyp. Und bei empfangenen Daten wurden immer alle existierenden Variablen beschrieben, d.h. falls an einer Position mehrere für den gleichen Eintrag, aber mit verschiedenen Datentypen existierte, wurde (mit nötigenfalls Cast auf Variablendatentyp) jede davon parallel geupdated. Sicherlich etwas aufwendig…
@Nall-chan
Eine Anpassung des converters wäre eine Möglichkeit und würde ich vielleicht auch machen, wenn es mein eigenes Gerät wäre. Das ist es aber nicht und somit kann ich es nur mit großem Aufwand ändern und auch nicht vernünftig testen. Und da das Thema auch bei anderen Geräten auftritt, sollte es meines Erachtens in Symcon gelöst werden.
Im jetzigen Fall wurde eine Float Variable gelöscht und neu angelegt. Was dazu geführt hat, kann ich nicht sagen, aber ich vermute mal es war ein kurzzeitiger string oder bool Wert.
Wie ist denn da der Ansatz?
@sokkederheld
der Lösungsvorschlag, bei abweichenden Datentypen eine zusätzliche Variable mit gleichem Ident + Suffix anzulegen und zu füllen fände ich super. Dann geht nichts verloren und man kann auch Ursachenforschung betreiben.
Ich werde zur 7.0 ein Checkbox einbauen, indem ihr einen „Schreibschutz“ aktivieren könnt. Dann werden keine Variablen erstellt oder gelöscht und es gibt stattdessen Fehlermeldungen im Meldungsfenster. Die gibt es dann für den JSON Dekoder und die MQTT Instanz.
Indem halt immer der Wert als Float reinkommt, also mit Punkt. Auch wenn er zufällig keinen Bruch enthält.
Bei PHP geht das mit JSON_PRESERVE_ZERO_FRACTION.
Das Problem bei dem Code des converters ist halt, dass das json dort selbst irgendwie generiert wird, anstatt dafür spezielle Klassen wie AJson (Arduino) oder cJson ( rein C) zu nutzen.
Die könnten auch Float richtig.
Michael
Das ist aber kein Problem. Der JSON Dekoder packt Integer auch in einen Float. Dafür gibt es eine Ausnahme. Es muss schon ein Bool oder String übertragen worden sein, damit die Variable gekillt wird. (Null, Object, Array wird ignoriert)
Dann sollte bei @bumaas aber schon netzt keine Variable mehr gelöscht und ersetzt werden.
Habe es so verstanden, das sobald eine Ganzzahl kommt die Float gelöscht wird.
Michael
Das kann nicht sein. Das passiert exakt ein mal, wenn initial der Wert als INT kam und dann plötzlich FLOAT wurde. Wenn danach wieder INT kommt, wird es schön in die FLOAT Variable geschrieben.
Es muss also ein Bool oder String empfangen werden.
Ich habe bei der Außentemperatur folgendes beobachtet:
Beim Temperaturwechsel von 0.1 auf 0 auf ‚-0.1‘ auf 0 auf 0.1 wechselt die Variable von float zu string zu int zu float
Dafür führe ich inzwischen eine eigene Variable (32886).
<?php
// ESP Altherma liefert negative Werte leider als String. Als Folge werden in Symcon die Statusvariablen beim Typwechsel gelöscht und neu angelegt. Daher wird eine eigene Variable geführt und aktuell gehalten
$id = IPS_GetObjectIDByIdent('Au__enlufttemp_', 12108);
$value_new = (float) GetValue($id);
if ($value_new !== GetValueFloat(32886)){
SetValueFloat(32886, $value_new);
}
Dass negative Werte von ESPAltherma als String geliefert werden ist natürlich besonders übel dabei.
@Nall-chan
kannst du das im aktuellen ESPAltherma Code noch verifizieren? Ich meine, mal eine Fehlermeldung geschrieben zu haben. Vielleicht ist das inzwischen weg.
Im letzten Fall geht es um die Durchflussmenge, die ja eigentlich nicht negativ werden kann. Da weiß ich nicht, was passiert ist.
Das Problem ist eigentlich mehr die aufwändige Suche nach einem Fehler, wenn Variablen ohne weiteren Hinweis gelöscht und neu angelegt werden.
Das muss definitiv der Entwickler korrigieren. Denn mein „Locked“ Modus wird nur das Problem lösen, dass die Variable verschwindet. Am Ende wirst du dann aber Fehlermeldungen im Log bekommen, dass da Mist empfangen wurde.
