NEWS
Unerklärlicher Typkonflikt
-
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 versionsIst 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 :-(
@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)ioBroker@Ubuntu 24.04 LTS (VMware) für: >260 Geräte, 5 Switche, 7 AP, 9 IP-Cam, 1 NAS 42TB, 1 ESXi 15TB, 4 Proxmox 1TB, 1 Hyper-V 48TB, 14 x Echo, 5x FireTV, 5 x Tablett/Handy VIS || >=160 Tasmota/Shelly || >=95 ZigBee || PV 8.1kW / Akku 14kWh || 2x USV 750W kaskadiert || Creality CR-10 SE 3D-Drucker
-
@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)@bananajoe sagte: Eventuell ist das schon der ganze Grund
Es funktioniert auch ohne Semikolon durch die Zeilenschaltung. Man sollte aber immer ein Semikolon setzen.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: RPi 2 mit S.USV, HM-MOD-RPI und SLC-USB-Stick mit root fs -
@thisoft sagte in Unerklärlicher Typkonflikt:
Tupel.Fuellhoehe
wahrscheinlich ist
Tupel.Fuellhoehe
ein Stringjavascript 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 wurdesemicolons sind zwar nicht immer notwendig (manchmal schon), aber es ist einfach
jeden befehl damit abzuschließen um misinterpretationen zu vermeiden -
@bananajoe sagte: Eventuell ist das schon der ganze Grund
Es funktioniert auch ohne Semikolon durch die Zeilenschaltung. Man sollte aber immer ein Semikolon setzen.
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.
-
@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
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.@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...
22 HM-Geräte; PivCCU2 auf RasPi
ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients
-
@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...
@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 ...ioBroker@Ubuntu 24.04 LTS (VMware) für: >260 Geräte, 5 Switche, 7 AP, 9 IP-Cam, 1 NAS 42TB, 1 ESXi 15TB, 4 Proxmox 1TB, 1 Hyper-V 48TB, 14 x Echo, 5x FireTV, 5 x Tablett/Handy VIS || >=160 Tasmota/Shelly || >=95 ZigBee || PV 8.1kW / Akku 14kWh || 2x USV 750W kaskadiert || Creality CR-10 SE 3D-Drucker
-
@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 ...@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
:D
-
@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 ...@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?22 HM-Geräte; PivCCU2 auf RasPi
ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients
-
@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?@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"
Support us
744
Online32.6k
Benutzer82.2k
Themen1.3m
Beiträge