Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Skripten / Logik
    4. JavaScript
    5. Problem mit getState()

    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

    Problem mit getState()

    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      fastfoot @AlCalzone last edited by

      @alcalzone sagte in Problem mit getState():

      Der korrekte Weg wären lokale Variablen für den Schutzzustand, die dann nur in den State gespeichert werden. Das getState kann man sich dann sparen und direkt die Variable verwenden.

      setState gefolgt von getState missbraucht eine Datenbank als Variable. Das sorgt erstens für mehr Systemlast, und zweitens zu Verzögerung durch den Umweg über die Datenbank.

      Eigentlich wollte ich das auch vorschlagen, dann kam mir aber der Gedanke, dass man mit der Variablen eigentlich nur den Zustand beschreibt, der nach dem setState() herrschen sollte, genau weiss man es nur nach getState(). Diesen 'Konflikt' konnte ich gerade nicht auflösen, also hatte ich es so belassen in meiner Lösung 🙂

      T AlCalzone 2 Replies Last reply Reply Quote 0
      • T
        ticaki Developer @fastfoot last edited by

        Hab zwar noch nicht mit setStateAsync() rumgespielt, wenn die Nachricht jedoch den tatsächlichen Zustand widerspiegeln soll muß man auf Änderungen der beiden States reagieren.

        Wenn innerhalb von setStateAsync() ein setState() aufgerufen wird, dass den wert auf "false" setzt, wird man es auf diesem Weg wohl nicht mitbekommen.

        1 Reply Last reply Reply Quote 0
        • AlCalzone
          AlCalzone Developer @fastfoot last edited by AlCalzone

          @fastfoot sagte in Problem mit getState():

          dass man mit der Variablen eigentlich nur den Zustand beschreibt, der nach dem setState() herrschen sollte

          Hä? setState (und setStateAsync) schreibt den Wert, den du übergibst in die Datenbank. Wenn direkt danach mit dem Wert was gemacht werden soll, brauchst du ihn doch nicht wieder aus der Datenbank lesen. Du weißt den Wert doch schon.
          Das ist wie als würde ich mir nen Notizzettel schreiben und selbst per Post schicken, um zu schauen was auf dem Notizzettel steht.

          F T 2 Replies Last reply Reply Quote 0
          • F
            fastfoot @AlCalzone last edited by

            @alcalzone sagte in Problem mit getState():

            Das ist wie als würde ich mir nen Notizzettel schreiben und selbst per Post schicken, um zu schauen was auf dem Notizzettel steht.

            Es ist in der Analogie wohl eher so, als wenn ich einen Anderen bitte, etwas auf den Zettel zu schreiben und dann lese, ob der das auch richtig geschrieben hat 🙂

            AlCalzone 1 Reply Last reply Reply Quote 0
            • AlCalzone
              AlCalzone Developer @fastfoot last edited by

              @fastfoot Ne, wenn dann bittest du den anderen, es vorzulesen. Ist aber auch egal, da du sicher davon ausgehen kannst, dass er es richtig macht, wenn das Skript nicht mit Fehler abstürzt.

              Dennoch bleibe ich dabei: Es spricht nichts dagegen die Daten rausspeichern, um beim nächsten Skript-Start darauf zuzugreifen, oder von wo anders darauf zu reagieren.
              Eine Datenbank als Variable zu missbrauchen ist Unsinn.

              1 Reply Last reply Reply Quote 0
              • T
                ticaki Developer @AlCalzone last edited by ticaki

                @alcalzone

                EDIT: Ups war garnicht an mich gerichtet... sry 🙂

                Ich habe dir nicht widersprochen, sondern den Gedanken des Vorpostens weitergeführt.
                Die Bestätigung das die Alarmanlage tatsächlich scharf geschaltet wurde ist durch ein "setStateAsync()" nicht zu verwirklichen. Dazu muß man auf Änderungen von '0_userdata.0.Alarmanlage.Alarm_Zustand' mit einem Delay reagieren um nicht doppelte Meldungen zu erhalten.

                Das ist für den Fall nötig dass das Alarmsystem im Fehlerfall die Variable wieder auf false setzt. Ansonsten ist nach setzten des States dessen auslesen überflüssig.

                @fastfoot
                Das die Datenbank es richtig macht muß man einfach annehmen* und alle anderen "Fehler" findest du auf diese Art nicht. 🙂
                *Wenn nicht wird viel viel mehr nicht funktionieren als nur das Skript g

                AlCalzone 1 Reply Last reply Reply Quote 0
                • AlCalzone
                  AlCalzone Developer @ticaki last edited by AlCalzone

                  @ticaki Okay, für den Fall dass irgendwas als Reaktion auf das setStateAsync von außen den State wieder zurück setzt, kann es tatsächlich Sinn machen. Alarm_Aktiv auszulesen, kannst du in dem Beispiel nicht vermeiden, Alarm_Zustand hingegen schon.

                  Aber es ist dennoch nicht garantiert, dass bis zum Auslesen für die Nachricht die Reaktion schon erfolgt ist. Da Skripte parallel laufen, ist folgendes denkbar

                  • Skript A setzt State 1 auf true
                  • Skript B reagiert auf State 1 (macht was, kann ein paar ms dauern)
                  • Skript A liest State 1 wieder aus (true)
                  • Skript B ist fertig mit Reaktion und setzt State 1 auf false (zu spät)
                  • Skript A liest State 2 aus (true)
                  • Skript B setzt State 2 auf false (zu spät)
                  • Skript A versendet Meldung mit true, true, obwohl beide States false sind

                  In dem Fall wäre es vielleicht sinnvoller, Skript B reagieren zu lassen und die Meldung selbst zu senden (mit garantiert richtigen und aktuellen Daten)

                  T 1 Reply Last reply Reply Quote 0
                  • T
                    ticaki Developer @AlCalzone last edited by

                    @alcalzone
                    Deshalb habe ich geschrieben auf Änderungen zu reagieren, also .on() zu verwenden. Ich widerspreche dir noch immer nicht, sondern bin deiner Meinung. 🙂

                    P 1 Reply Last reply Reply Quote 0
                    • P
                      PSims @ticaki last edited by

                      Hallo an euch und vielen Dank für die vielen Informationen.

                      @fastfoot
                      Deine vorgeschlagene Variante mit den verschiedenen Asynch-Parametern/ -Funktionen hatte ich auch ausprobiert. Jedoch hat sich der Zustand des Datenpunktes gar nicht mehr geändert, wenn ich diesen beschreiben wollte. Deshalb bin ich dann auf die Variante mit den lokalen Variablen umgeswitcht.

                      Somit wird nun am Anfang des Skriptes der aktuelle Zustand der Datenpunkte in eine lokale Variable geschrieben. Die ich dann im Skript weiter verwende. Das einzig "doofe" ist halt, dass ich diese dann im laufenden Skript mit verändern muss, da ich den aktuellen Zustand des Datenpunktes im laufenden Skript ja auch weiter benötige und über getState (aufgrund des Asynch-Problems) nicht nutzen kann.

                      Also hier ein Beispiel:

                      Hier werden die Werte am Anfang des Skriptes aus der Datenbank geholt bzw. in eine lokale Variable geschrieben:

                          // Einlesen der Zustände der Alarmanlage
                          STATE_ALARM_ZUSTAND = getState('0_userdata.0.Alarmanlage.Alarm_Zustand').val;
                          STATE_ALARM_AKTIV = getState('0_userdata.0.Alarmanlage.Alarm_Aktiv').val;
                      

                      Wenn jetzt innerhalb des Skriptes der Zustand des Datenpunktes geändert wird, ändere ich im Anschluss auch die lokale Variable, da ich diese ja im Nachhinein auch weiter nutze bzw. abfrage:

                          // Setze Alarmzustand aktiv
                          setState('0_userdata.0.Alarmanlage.Alarm_Zustand', true);
                          STATE_ALARM_ZUSTAND = true;
                      

                      Und hier wird die Variable dann nochmals genutzt bzw. abgefragt, bevor sie dann per Telegram verschickt wird:

                          sendTo('telegram', {
                              text:      '<b>Aktuelle Statusübersicht</b>\n' +
                                          '------------------------------------------\n' +
                                          'Alarmstatus: ' + TextAlarm(STATE_ALARM_ZUSTAND) + '\n' +
                                          'Auslösung: ' + TextAlarm(STATE_ALARM_AKTIV) + '\n' +
                                          '------------------------------------------',
                              parse_mode: 'HTML',
                          })
                      
                      function TextAlarm(zustandAlarm){
                          Text_Hilf = 'nicht aktiv';
                          if (zustandAlarm==true){
                              Text_Hilf = 'aktiv';
                          }
                          return Text_Hilf
                      }
                      

                      Aus eurer Sicht wäre das nun die optimale und gleichzeitig auch ressourcenschonende Variante?

                      T 1 Reply Last reply Reply Quote 1
                      • T
                        ticaki Developer @PSims last edited by

                        @psims
                        Ich würde, um Fehler in Zukunft auszuschließen(späteres editieren), folgende Variante bevorzugen:

                        // Setze Alarmzustand aktiv
                            STATE_ALARM_ZUSTAND = true;
                            setState('0_userdata.0.Alarmanlage.Alarm_Zustand', STATE_ALARM_ZUSTAND);
                        

                        Desweiteren würde ich innerhalb des If Blocks nur die Variable verändern und hinter diesem den State setzten.

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

                        Support us

                        ioBroker
                        Community Adapters
                        Donate

                        619
                        Online

                        31.8k
                        Users

                        80.0k
                        Topics

                        1.3m
                        Posts

                        4
                        15
                        836
                        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