Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Skripten / Logik
  4. JavaScript
  5. Unerklärlicher Typkonflikt

NEWS

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    17
    1
    2.4k

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    965

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    25
    1
    2.2k

Unerklärlicher Typkonflikt

Geplant Angeheftet Gesperrt Verschoben JavaScript
13 Beiträge 6 Kommentatoren 1.1k Aufrufe 5 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • ThisoftT 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 :-(

    AsgothianA Offline
    AsgothianA Offline
    Asgothian
    Developer
    schrieb am zuletzt editiert von
    #3

    @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.

    ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
    "Shit don't work" ist keine Fehlermeldung, sondern ein Fluch.

    1 Antwort Letzte Antwort
    0
    • ThisoftT 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 :-(

      BananaJoeB Offline
      BananaJoeB Offline
      BananaJoe
      Most Active
      schrieb am zuletzt editiert von BananaJoe
      #4

      @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

      paul53P 1 Antwort Letzte Antwort
      0
      • BananaJoeB 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)

        paul53P Offline
        paul53P Offline
        paul53
        schrieb am zuletzt editiert von
        #5

        @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

        ThisoftT 1 Antwort Letzte Antwort
        0
        • OliverIOO Offline
          OliverIOO Offline
          OliverIO
          schrieb am zuletzt editiert von OliverIO
          #6

          @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

          Meine Adapter und Widgets
          TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
          Links im Profil

          1 Antwort Letzte Antwort
          0
          • paul53P 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.

            ThisoftT Offline
            ThisoftT Offline
            Thisoft
            schrieb am zuletzt editiert von
            #7

            @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.

            22 HM-Geräte; PivCCU2 auf RasPi

            ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients

            1 Antwort Letzte Antwort
            0
            • OliverIOO Offline
              OliverIOO Offline
              OliverIO
              schrieb am zuletzt editiert von
              #8

              @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.

              Meine Adapter und Widgets
              TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
              Links im Profil

              ThisoftT 1 Antwort Letzte Antwort
              0
              • OliverIOO 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.

                ThisoftT Offline
                ThisoftT Offline
                Thisoft
                schrieb am zuletzt editiert von
                #9

                @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

                BananaJoeB 1 Antwort Letzte Antwort
                0
                • ThisoftT 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...

                  BananaJoeB Offline
                  BananaJoeB Offline
                  BananaJoe
                  Most Active
                  schrieb am zuletzt editiert von
                  #10

                  @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

                  ZarelloZ ThisoftT 2 Antworten Letzte Antwort
                  1
                  • BananaJoeB 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 ...

                    ZarelloZ Offline
                    ZarelloZ Offline
                    Zarello
                    schrieb am zuletzt editiert von
                    #11

                    @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

                    1 Antwort Letzte Antwort
                    0
                    • BananaJoeB 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 ...

                      ThisoftT Offline
                      ThisoftT Offline
                      Thisoft
                      schrieb am zuletzt editiert von
                      #12

                      @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

                      BananaJoeB 1 Antwort Letzte Antwort
                      0
                      • ThisoftT 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?

                        BananaJoeB Offline
                        BananaJoeB Offline
                        BananaJoe
                        Most Active
                        schrieb am zuletzt editiert von BananaJoe
                        #13

                        @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"

                        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

                        1 Antwort Letzte Antwort
                        0
                        Antworten
                        • In einem neuen Thema antworten
                        Anmelden zum Antworten
                        • Älteste zuerst
                        • Neuste zuerst
                        • Meiste Stimmen


                        Support us

                        ioBroker
                        Community Adapters
                        Donate

                        564

                        Online

                        32.6k

                        Benutzer

                        82.2k

                        Themen

                        1.3m

                        Beiträge
                        Community
                        Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                        ioBroker Community 2014-2025
                        logo
                        • Anmelden

                        • Du hast noch kein Konto? Registrieren

                        • Anmelden oder registrieren, um zu suchen
                        • Erster Beitrag
                          Letzter Beitrag
                        0
                        • Home
                        • Aktuell
                        • Tags
                        • Ungelesen 0
                        • Kategorien
                        • Unreplied
                        • Beliebt
                        • GitHub
                        • Docu
                        • Hilfe