Unerklärlicher Typkonflikt

[Thisoft]

Hallo zusammen,

ein Script von mir wirft stur den folgenden Fehler im Log:

You are assigning a string to the state "javascript.1.Regenwasser.Literaktuell" which expects a number. Please fix your code to use a number or change the state type to string. This warning might become an error in future versions

Ist ja eigentlich selbstredend aber ich sehe in diesem Fall einfach keinen Grund dafür. Mein Script:

function fuell_berechnen(){
    var kurve=JSON.parse(require('fs').readFileSync('/opt/iobroker/iobroker-data/private/FuellkurveRegen.json').toString());
    var level=getState('javascript.1.Regenwasser.RegentankDuino.LevelRaw').val;
    if (level<RawValMax){level=RawValMax};
    var prozFuell = Math.round(100-(level-RawValMax)*100/(RawValMin-RawValMax));
    var liter = 0
    while(kurve.length>0){
        var Tupel=kurve.pop();
        var TpFuell = Tupel.Fuellhoehe
        if(TpFuell==prozFuell){
            liter=Tupel.Fuellmenge;
        }
    }
    prozFuell = Math.round(liter/MaxFuellmenge*100)
    log('Regenwasser: RawLevel=' + level.toString() + ' / Korr Proz:'+prozFuell.toString()+'%' + ' / Liter:'+ liter.toString());
    setState('javascript.1.Regenwasser.Literaktuell',liter);
    setState('javascript.1.Regenwasser.ProzKorrigiert',prozFuell);
}

wenn ich mit dem Cursor über "liter" gehe wird mir angezeigt dass die Variable vom Typ "number" ist!

Und hier die Definition des angemeckerten States:

{
  "common": {
    "type": "number",
    "def": 0,
    "name": "javascript.1.Regenwasser.Literaktuell",
    "role": "state"
  },
  "native": {},
  "type": "number",
  "from": "system.adapter.javascript.1",
  "user": "system.user.admin",
  "ts": 1564881176288,
  "_id": "javascript.1.Regenwasser.Literaktuell",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Irgendwie komm ich mir veräppelt vor

[BananaJoe]

@thisoft das hatte ich vor eine Weile auch schon in einem meiner Skripts.
Geholfen hat das ich bei Strings und Nummern diese vorher explizit "umwandle" :

setState(s_state_FullPath + ".Version", String(obj.Info1.Version), true);
setState(s_state_FullPath + ".Energy-Total", Number(obj.ENERGY.Total), true);

Boolean, Zeiten schreiben etc. funktioniert ohne Probleme.

Könnte auch sein das es am Schreiben unterhalb von javascript.x liegt, ob das Problem bei 0_userdata.0. noch auftritt habe ich nie getestet ... da ich ja nun im Skript immer explizit vor dem Schreiben den Typ setze

[Asgothian]

@thisoft

du hast 'liter' zwar als zahl vordefiniert, es ist aber nicht klar ob du es mit einer Zahl nachträglich beschreibst. Ich würde

liter=Tupel.Fuellmenge;

gegen

liter=parseInt(Tupel.Fuellmenge);

ersetzen (ggf. parseFloat)

A.

[BananaJoe]

@thisoft sagte in Unerklärlicher Typkonflikt:

var prozFuell = Math.round(100-(level-RawValMax)*100/(RawValMin-RawValMax));
var liter = 0
while(kurve.length>0){

und bei dir fehlen mehrere ; im Skript, z.B. hinter der Zuweisung von liter und der Berechnung von prozFuell
Eventuell ist das schon der ganze Grund (und war es bei mir damals)

[paul53]

@bananajoe sagte: Eventuell ist das schon der ganze Grund

Es funktioniert auch ohne Semikolon durch die Zeilenschaltung. Man sollte aber immer ein Semikolon setzen.

[OliverIO]

@thisoft sagte in Unerklärlicher Typkonflikt:

Tupel.Fuellhoehe

wahrscheinlich ist
Tupel.Fuellhoehe
ein String

javascript führt adhoc typumwandlung durch
die rechnungen funktionieren trotzdem da du nicht addiert hast.
das plus zeichen ist auch ein operator zum strings verketten
daher ergibt
"12" / 4 = 3 aber
"12" +4 = "124"
es ist relativ egal, das man mal eine variable mit einer Number initialisiert hat. sobald was neues kommt, wird der typ angenommen
das ist einer der gründe warum typescript erfunden wurde

semicolons sind zwar nicht immer notwendig (manchmal schon), aber es ist einfach
jeden befehl damit abzuschließen um misinterpretationen zu vermeiden

[Thisoft]

@paul53

Am Semikolon lag's nicht!

Geholfen hat "Number(liter)". Ja, dieser elendige untypisierte Mist - so toll und mächtig wie Javascript ansonsten ist, aber sowas ist doch... naja ich bin ja schon dabei und mache neue Sachen eigentlich immer in Typescript...

Vielen Dank euch allen.

[OliverIO]

@thisoft
ja, fehleranfällig
aber das problem lag ja an dem einen attribut im datenpunkt
Tupel.Fuellhoehe
wenn du es selbst erstellt hast, hast da nicht sauber gearbeitet.
wenn du es nicht erstellt hast, dann kennst du nun eine auswirkung, das fremden daten nie vertraut werden darf und diese erst angeglichen und überprüft werden müssen.

[Thisoft]

@oliverio ja ich hab das selbst erstellt! Sauber gearbeitet naja - wenn man's von der Warte sieht dass man das was JS bei der impliziten Konvertierung verwurstet selbst korrigieren muss hast du ja Recht. Aber wenn man's von keiner anderen Sprache gewohnt ist dass sich der Typ einer Variablen ohne Neudeklaration einfach mal ändert dann wird's eben hakelig. Außerdem - nix für ungut, aber die Variable an den zugewiesenen Wert anzupassen ist doch m.E. gerade die verkehrte Welt der implizierten Konvertierung. Aber die Diskussion führt eh zu nix - das ist halt so und mit Typescript wird zumindest das besser, an manchen Ecken hapert's beim Typescript aber auch noch...

[BananaJoe]

@thisoft ich kenne das schon von anderen Scriptsprachen (AutoIt z.B., in der Bash).
Ich habe mir mal angewöhnt alle Variablen immer mit einem Buchstaben beginnen zu lassen der den Typ wiederspiegelt, egal ob die Sprache Typen unterstützt oder nicht:

a_Monate = a = Array
i_Tag = i = Integer
s_Tag = s = String
o_Datum = o = Objekt
usw.

usw.
Das setzte ich dann aber wiederum herrlich inkonsequent um ...

[Zarello]

@bananajoe sagte in Unerklärlicher Typkonflikt:

Ich habe mir mal angewöhnt alle Variablen immer mit einem Buchstaben beginnen zu lassen der den Typ wiederspiegelt, egal ob die Sprache Typen unterstützt oder nicht:

Das wurde so auch schon in Programmiersprachen umgesetzt, wer kennt es noch:

god is real - unless declared integer

[Thisoft]

@bananajoe sagte in Unerklärlicher Typkonflikt:

@thisoft ich kenne das schon von anderen Scriptsprachen (AutoIt z.B., in der Bash).
Ich habe mir mal angewöhnt alle Variablen immer mit einem Buchstaben beginnen zu lassen der den Typ wiederspiegelt, egal ob die Sprache Typen unterstützt oder nicht:

Tja, wie der Name schon sagt "Scriptsprachen" - das sind eben keine Programmiersprachen
Und was nützt es bitteschön die Variablennamen mit dem fraglichen Buchstaben beginnen zu lassen wenn das dann niemanden und am Wenigsten den Compiler interessiert?

[BananaJoe]

@thisoft das man persönlich den Überblick behält - gerade wenn es denn irgendwann mehrere duzend / hunderte von Variablen sind.
Programmiersprachen ist auch ein Oberbegriff. Und solange dabei PHP, Pearl und Python in einem Atemzug mit C++, JavaScript und SQL genannt werden schäme ich mich für nichts

Wenn der Compiler nicht kann hindert einen nichts daran zumindest selbst den Überblick zu behalten.
Meine Programme oder Skripte bestehen meist aus 10% der eigentlichen Aufgabe, 50% der Prüfung aller Eventualitäten und Fehlerfälle (Verlasse dich auf nichts! Sorge immer für einen definierten Zustand!) und die restlichen 40% sind Kommentare.

Und der Chef will einfach nicht verstehen warum man etwas noch mal neu coden will weil es "sch....e aussieht"