[Erledigt: byDesign]States nehmen falschen Datentyp an wenn State manuell in IObroker bearbeitet wird

coffee-junk

Hallo,

habe ein etwas seltsames verhalten festgestellt.

Wird in JavaScript ein neuer State erstellt vom Typ 'number' und wird dieser mit GetState ausgelesen, erhält man eine Variable vom Typ 'number'

Wird dieser State jetzt in der Admin Oberfläche bearbeite, sagen wie mal ich trage den Wert 100.00 ein, wird in den state nicht eine 'number' geschrieben sondern ioBroker macht daraus einen 'string', soll heissen, wenn nach der manuellen Änderung der state mit getState ausgelesen wird, bekommt man plötzlich eine Variable vom typ 'string' zurück geliefert. Ist das normal??

Suche seit Tagen in meinen Scripten ominöse Fehler, die, wie ich jetzt herrausgefunden habe, mit diesem Problem zusammen hängen.

Muss ich jetzt wirklich jeden State nach dem lesen mit getState auf den richtigen Datentyp prüfen, oder ist das ein "Fehler" von der Adminoberfläche???

Wenn ich in der Oberfläche bei dem state auf den 'Bleistift' tippe, wird als Datentyp 'number' angezeigt.

    createState('test', {
        name:   'testState',
        type:   'number',
        def:    0.0,
        unit:   "m3",
        role:   "value"
    });

apollon77

Hast Du wirklich im Admin "100.000" als 100000 eingegeben?

coffee-junk

~~@apollon77:~~

Hast Du wirklich im Admin "100.000" als 100000 eingegeben? `

Nein, das ist ein Dezimalpunkt also in deutscher Schreibweise 100,00

…. oder ist evt. der "." das Problem?

apollon77

Versuch doch mal :-)

Ich würde ohne Komma mal testen. Also, kommt eine 100 als Zahl an oder als String. Wenn Zahl dann mit "." Als dezimaltrenner

paul53

~~@coffee-junk:~~

…oder ist evt. der "." das Problem? `
Nein. Jede Eingabe ist erst einmal ein String. Eingaben mit n.0 n.00 usw. werden offenbar nicht als Zahl erkannt und nicht in den Typ number umgeformt. Das sollte sicherlich (irgendwann) korrigiert werden. Die Eingabe von Werten mit nur Nullen nach dem Dezimalpunkt kommt wahrscheinlich selten vor, weshalb ist der Fehler noch nicht aufgefallen ist. Die Eingabe von z.B. 100.001 liefert den Typ number.

apollon77

Interessant. Mal dumme Frage: was ist in den iobroker Einstellungen als dezimaltrenner eingestellt? Komma oder Punkt? Falls Komma: tut es dann?

coffee-junk

> Interessant. Mal dumme Frage: was ist in den iobroker Einstellungen als dezimaltrenner eingestellt? Komma oder Punkt? Falls Komma: tut es dann?
Als Dezimaltrennzeichen ist in ioBroker das "Komma" eingestellt, seltsamer Weise wird aber bei allen Ausgaben, auch auf der Adminoberfläche der "Dezimalpunkt" ausgegeben.

> Versuch doch mal :-)
Habe ich, gestern war es doch ein bisschen spät :roll: und zudem war nach der ganzen Sucherei, was genau den Fehler verursacht, mein Hirn zum Schluss ziemlich angematscht :(

Ich komme von "C/C++" und da passiert soetwas eingentlich nicht, dass sich der Datentyp so mal ab und zu ändert. An diese "FehlerQuelle" von Java, muss ich mich erst mal dran gewöhnen

Bin bei meinen Scripten bis jetzt einfach davon ausgegangen, dass wenn ein state vom Typ "number" erstellt wird, dieser auch nie etwas anders zurückliefert als ne "number".

Jetzt muss ich meine ganzen Scripts durchflöhen, für den Fall, dass ich irgendwann mal einen state manuell ändere und dabei aus nem Float einen String mache oder umgekehrt.

Hier das Ergebnis:

4    => number
4.0  => string
4,1  => string
4.01 => number
4,01 => string

Und als Ergebnis lese ich States die einen Float zurückgeben nur noch so aus:

function getFloat(name) {
  var s = getState(name).val;
  if (typeof(s) != 'number') {
    s = parseFloat(s);
  }
  return s;
}

Da hat paul53 wohl genau den Nagel auf den Kopf getroffen!

apollon77

Habs mal als bug ins trello gepackt. Man sollte sich drauf verlassen können …

paul53

Man kann Zahlenwerte auch so eingeben wie sie dargestellt werden - also ohne angehängte Null(en). Dann funktioniert es.

Bluefox

~~@paul53:~~

Man kann Zahlenwerte auch so eingeben wie sie dargestellt werden - also ohne angehängte Null(en). Dann funktioniert es. `
Ja. Da steht so was

if (parseFloat(input).toString() === input) then number

parseFloat('4.0').toString() == 4 und 4 != 4.0

Man kann natürlich Statetyp anschauen….

coffee-junk

Hallo,

ich mach das jetzt so, dass ich die getState ersetzt habe durch folgende Funktion, damit der Float sichergestellt ist.

Und sollte irgendwo etwas nicht stimmen, wird das im LOG vermerkt, damit mir das auffällt.

Erst gestern ist es mir wieder passiert, obwohl ich mir über die Eingabeart bewusst bin, dass sich wieder so ein Lump von 'string' in einem State verirrt hat und da dieser Wert bei weiteren Berechnungen einbezogen wird, ruckzuck gigantische strings in der Datenbank entstehen, wenn dieser Wert auf andere Werte Addiert wird.

So verhindere ich das jetzt wirkungsvoll:

// Liest ein Wert aus der Datenbank und liefert den Float Wert zurück
function getFloat(name) {
  var s = getState(name).val;
  if (typeof(s) != 'number') {
    s = parseFloat(s);
    log("Falscher Datentyp von STATE '" + name + "' Wert wurde in Float konvertiert!",'warn');
  }
  if(isNaN(s)) {
    log("Wert von STATE '" + name + " 'ist ungültig! Muss eine Zahl sein!",'error');
  }
  return s;
}

Bluefox

~~@coffee-junk:~~

Hallo,

ich mach das jetzt so, dass ich die getState ersetzt habe durch folgende Funktion, damit der Float sichergestellt ist.

Und sollte irgendwo etwas nicht stimmen, wird das im LOG vermerkt, damit mir das auffällt.

Erst gestern ist es mir wieder passiert, obwohl ich mir über die Eingabeart bewusst bin, dass sich wieder so ein Lump von 'string' in einem State verirrt hat und da dieser Wert bei weiteren Berechnungen einbezogen wird, ruckzuck gigantische strings in der Datenbank entstehen, wenn dieser Wert auf andere Werte Addiert wird.

So verhindere ich das jetzt wirkungsvoll:
// Liest ein Wert aus der Datenbank und liefert den Float Wert zurück
function getFloat(name) {
  var s = getState(name).val;
  if (typeof(s) != 'number') {
    s = parseFloat(s);
    log("Falscher Datentyp von STATE '" + name + "' Wert wurde in Float konvertiert!",'warn');
  }
  if(isNaN(s)) {
    log("Wert von STATE '" + name + " 'ist ungültig! Muss eine Zahl sein!",'error');
  }
  return s;
}
```` `  

Wird verbessert: https://github.com/ioBroker/ioBroker.ad … d4f09dR645

Community Forum

NEWS

[Erledigt: byDesign]States nehmen falschen Datentyp an wenn State manuell in IObroker bearbeitet wird

Support us

861

32.4k

81.4k

1.3m