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

[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