Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Skripten / Logik
    4. JavaScript
    5. Unerklärlicher Typkonflikt

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    Unerklärlicher Typkonflikt

    This topic has been deleted. Only users with topic management privileges can see it.
    • Thisoft
      Thisoft last edited by

      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 Asgothian 3 Replies Last reply Reply Quote 0
      • BananaJoe
        BananaJoe Most Active @Thisoft last edited by

        @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

        1 Reply Last reply Reply Quote 0
        • Asgothian
          Asgothian Developer @Thisoft last edited by

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

          1 Reply Last reply Reply Quote 0
          • BananaJoe
            BananaJoe Most Active @Thisoft last edited by 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 1 Reply Last reply Reply Quote 0
            • paul53
              paul53 @BananaJoe last edited by

              @bananajoe sagte: Eventuell ist das schon der ganze Grund

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

              Thisoft 1 Reply Last reply Reply Quote 0
              • OliverIO
                OliverIO last edited by 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

                1 Reply Last reply Reply Quote 0
                • Thisoft
                  Thisoft @paul53 last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • OliverIO
                    OliverIO last edited by

                    @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 1 Reply Last reply Reply Quote 0
                    • Thisoft
                      Thisoft @OliverIO last edited by

                      @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 1 Reply Last reply Reply Quote 0
                      • BananaJoe
                        BananaJoe Most Active @Thisoft last edited by

                        @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 Thisoft 2 Replies Last reply Reply Quote 1
                        • Zarello
                          Zarello @BananaJoe last edited by

                          @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

                          😄

                          1 Reply Last reply Reply Quote 0
                          • Thisoft
                            Thisoft @BananaJoe last edited by

                            @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 1 Reply Last reply Reply Quote 0
                            • BananaJoe
                              BananaJoe Most Active @Thisoft last edited by 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"

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post

                              Support us

                              ioBroker
                              Community Adapters
                              Donate

                              755
                              Online

                              31.8k
                              Users

                              80.0k
                              Topics

                              1.3m
                              Posts

                              6
                              13
                              587
                              Loading More Posts
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes
                              Reply
                              • Reply as topic
                              Log in to reply
                              Community
                              Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                              The ioBroker Community 2014-2023
                              logo