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. Javascript - Verständnisproblem mit if ...

NEWS

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    11
    1
    492

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    24
    1
    1.7k

  • UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?
    apollon77A
    apollon77
    48
    3
    9.6k

Javascript - Verständnisproblem mit if ...

Geplant Angeheftet Gesperrt Verschoben JavaScript
16 Beiträge 4 Kommentatoren 1.2k Aufrufe 3 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.
  • paul53P paul53

    @ErazorVIP sagte:

    Was mache ich falsch?

    Du prüfst das gesamte Zustandsobjekt (state), was immer true liefert, wenn vorhanden. Richtig wäre

        if (getState('javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1').val)  {
    

    oder besser

        if (obj.state.val)  {
    
    K Offline
    K Offline
    klassisch
    Most Active
    schrieb am zuletzt editiert von
    #4

    @paul53 sagte in Javascript - Verständnisproblem mit if ...:

    oder besser

        if (obj.state.val)  {
    

    warum ist das besser und wo finde ich mehr Informationen dazu?
    Erinnere mich ganz dunkel daran, daß man damit auch den vorherigen Status des Objscts abfragen kann, ohne das selbst zwischenspeichern zu müssen. Habe aber leider nichts mehr dazu gefunden.

    paul53P N 2 Antworten Letzte Antwort
    0
    • K klassisch

      @paul53 sagte in Javascript - Verständnisproblem mit if ...:

      oder besser

          if (obj.state.val)  {
      

      warum ist das besser und wo finde ich mehr Informationen dazu?
      Erinnere mich ganz dunkel daran, daß man damit auch den vorherigen Status des Objscts abfragen kann, ohne das selbst zwischenspeichern zu müssen. Habe aber leider nichts mehr dazu gefunden.

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

      @klassisch sagte:

      warum ist das besser

      Weil das in der lokalen Variablen obj bereits vorliegt und nicht erst durch eine Funktion abgeholt werden muss (Ressourcenverbrauch).

      @klassisch sagte in Javascript - Verständnisproblem mit if ...:

      wo finde ich mehr Informationen dazu?

      In der Funktions-Doku.

      @klassisch sagte in Javascript - Verständnisproblem mit if ...:

      daß man damit auch den vorherigen Status des Objscts abfragen kann

      Ja, bei on()

      obj.oldState
      

      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

      K 1 Antwort Letzte Antwort
      1
      • K klassisch

        @paul53 sagte in Javascript - Verständnisproblem mit if ...:

        oder besser

            if (obj.state.val)  {
        

        warum ist das besser und wo finde ich mehr Informationen dazu?
        Erinnere mich ganz dunkel daran, daß man damit auch den vorherigen Status des Objscts abfragen kann, ohne das selbst zwischenspeichern zu müssen. Habe aber leider nichts mehr dazu gefunden.

        N Offline
        N Offline
        Nahasapee
        schrieb am zuletzt editiert von Nahasapee
        #6

        @klassisch und wenn du in deinem else sowieso "nothing" machen willst und nur auf true reagieren willst kannst du es auch gleich in dein trigger setzen , dann brauchst du gar nix mehr prüfen.

        on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1'/*Timer Solar Plug1*/, change: "ne" , val :true},(obj)=>{});
        
        1 Antwort Letzte Antwort
        0
        • paul53P paul53

          @klassisch sagte:

          warum ist das besser

          Weil das in der lokalen Variablen obj bereits vorliegt und nicht erst durch eine Funktion abgeholt werden muss (Ressourcenverbrauch).

          @klassisch sagte in Javascript - Verständnisproblem mit if ...:

          wo finde ich mehr Informationen dazu?

          In der Funktions-Doku.

          @klassisch sagte in Javascript - Verständnisproblem mit if ...:

          daß man damit auch den vorherigen Status des Objscts abfragen kann

          Ja, bei on()

          obj.oldState
          
          K Offline
          K Offline
          klassisch
          Most Active
          schrieb am zuletzt editiert von
          #7

          @paul53

          so langsam beginnt es zu dämmern.
          Bisher habe ich verwendet

          on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', change: "ne"}, function() {
          	result = getState('javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1').val;
          });
          

          und mich gefragt, warum das Objekt zweimal anfassen muß.
          Muß man aber nicht, geht auch so

          on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', change: "ne"}, (obj){
          	result = obj.state.val;	
          });
          

          und es geht noch mehr wie zB. oldState.

          Ist dabei obj ein fester Begriff oder köönte das auch data123 oder so heißen?

          paul53P 1 Antwort Letzte Antwort
          0
          • K klassisch

            @paul53

            so langsam beginnt es zu dämmern.
            Bisher habe ich verwendet

            on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', change: "ne"}, function() {
            	result = getState('javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1').val;
            });
            

            und mich gefragt, warum das Objekt zweimal anfassen muß.
            Muß man aber nicht, geht auch so

            on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', change: "ne"}, (obj){
            	result = obj.state.val;	
            });
            

            und es geht noch mehr wie zB. oldState.

            Ist dabei obj ein fester Begriff oder köönte das auch data123 oder so heißen?

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

            @klassisch sagte:

            köönte das auch data123 oder so heißen?

            Ja. Ich verwende dp, das es das statische Objekt und den Zustand (state, oldState) liefert.

            on('javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', function(dp) { // triggert bei Wertänderung
               let val = dp.state.val;	
            });
            

            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

            K 1 Antwort Letzte Antwort
            0
            • paul53P paul53

              @klassisch sagte:

              köönte das auch data123 oder so heißen?

              Ja. Ich verwende dp, das es das statische Objekt und den Zustand (state, oldState) liefert.

              on('javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', function(dp) { // triggert bei Wertänderung
                 let val = dp.state.val;	
              });
              
              K Offline
              K Offline
              klassisch
              Most Active
              schrieb am zuletzt editiert von
              #9

              @paul53 Danke, also dp als Abkürzung für data point. Muß man die unterscheiden, wenn man mehree "on" statements im Script hat, also dp01, dp02 ?

              paul53P 1 Antwort Letzte Antwort
              0
              • K klassisch

                @paul53 Danke, also dp als Abkürzung für data point. Muß man die unterscheiden, wenn man mehree "on" statements im Script hat, also dp01, dp02 ?

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

                @klassisch sagte:

                Muß man die unterscheiden, wenn man mehree "on" statements im Script hat, also dp01, dp02 ?

                Nein, Funktionsparameter sind lokal, d.h. nur innerhalb der jeweiligen Callback-Funktion gültig.

                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

                K 1 Antwort Letzte Antwort
                0
                • paul53P paul53

                  @klassisch sagte:

                  Muß man die unterscheiden, wenn man mehree "on" statements im Script hat, also dp01, dp02 ?

                  Nein, Funktionsparameter sind lokal, d.h. nur innerhalb der jeweiligen Callback-Funktion gültig.

                  K Offline
                  K Offline
                  klassisch
                  Most Active
                  schrieb am zuletzt editiert von
                  #11

                  @paul53 Danke! Falls man das schachteln würde (wobei mir bei on jetzt nichts dazu einfiele), dann wäre eine andere Benennung wohl sinnvoll.

                  paul53P 1 Antwort Letzte Antwort
                  0
                  • K klassisch

                    @paul53 Danke! Falls man das schachteln würde (wobei mir bei on jetzt nichts dazu einfiele), dann wäre eine andere Benennung wohl sinnvoll.

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

                    @klassisch sagte:

                    Falls man das schachteln würde (wobei mir bei on jetzt nichts dazu einfiele), dann wäre eine andere Benennung wohl sinnvoll.

                    I.d.R. nicht. Beim Schachteln von Triggern sollte man genau wissen, was man tut.

                    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

                    K 1 Antwort Letzte Antwort
                    0
                    • paul53P paul53

                      @klassisch sagte:

                      Falls man das schachteln würde (wobei mir bei on jetzt nichts dazu einfiele), dann wäre eine andere Benennung wohl sinnvoll.

                      I.d.R. nicht. Beim Schachteln von Triggern sollte man genau wissen, was man tut.

                      K Offline
                      K Offline
                      klassisch
                      Most Active
                      schrieb am zuletzt editiert von
                      #13

                      @paul53 wenn wir schon bei solchen "Abkürzungen" sind: Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern, also nicht mit setState(id, value), sondern mit dp. irgendwas?

                      paul53P 1 Antwort Letzte Antwort
                      0
                      • K klassisch

                        @paul53 wenn wir schon bei solchen "Abkürzungen" sind: Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern, also nicht mit setState(id, value), sondern mit dp. irgendwas?

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

                        @klassisch sagte:

                        Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern,

                        Du meinst den Trigger-Datenpunkt ?

                        setState(dp.id, neuer_Wert);
                        

                        Damit löst man aber meist einen neuen Trigger aus.

                        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

                        K 1 Antwort Letzte Antwort
                        0
                        • paul53P paul53

                          @klassisch sagte:

                          Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern,

                          Du meinst den Trigger-Datenpunkt ?

                          setState(dp.id, neuer_Wert);
                          

                          Damit löst man aber meist einen neuen Trigger aus.

                          K Offline
                          K Offline
                          klassisch
                          Most Active
                          schrieb am zuletzt editiert von
                          #15

                          @paul53 sagte in Javascript - Verständnisproblem mit if ...:

                          @klassisch sagte:

                          Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern,

                          Du meinst den Trigger-Datenpunkt ?

                          Ja, den Datenpunkt, auf den man getriggert hat, dessen Wert man dann entnommen und verarbeitet hat und dessen neuen Wert man dann zurückspeichern möchte.

                          setState(dp.id, neuer_Wert);
                          

                          Damit löst man aber meist einen neuen Trigger aus.

                          Oh, das könnte dann oszillieren bzw. in einer Endlosschleife enden.

                          paul53P 1 Antwort Letzte Antwort
                          0
                          • K klassisch

                            @paul53 sagte in Javascript - Verständnisproblem mit if ...:

                            @klassisch sagte:

                            Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern,

                            Du meinst den Trigger-Datenpunkt ?

                            Ja, den Datenpunkt, auf den man getriggert hat, dessen Wert man dann entnommen und verarbeitet hat und dessen neuen Wert man dann zurückspeichern möchte.

                            setState(dp.id, neuer_Wert);
                            

                            Damit löst man aber meist einen neuen Trigger aus.

                            Oh, das könnte dann oszillieren bzw. in einer Endlosschleife enden.

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

                            @klassisch sagte:

                            Oh, das könnte dann oszillieren bzw. in einer Endlosschleife enden.

                            Ja, wenn man es nicht abfängt.

                            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

                            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

                            321

                            Online

                            32.5k

                            Benutzer

                            81.8k

                            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