Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Entwicklung
    4. Gleichzeitiges ändern mehrerer States eines Gerätes

    NEWS

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

    • ioBroker goes Matter ... Matter Adapter in Stable

    • Monatsrückblick - April 2025

    Gleichzeitiges ändern mehrerer States eines Gerätes

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

      Manche Geräte (z. B. Philips Hue) erlauben das ändern von mehreren Zuständen (Farbe, Helligkeit usw.) in einem Schritt. In einigen Fällen könnte das durchaus sinnvoll sein um die Anzahl der Anfragen zu verringern und ungewollte Effekte zu vermeiden.

      Aus User Sicht werden States ja mit setState() verändert, aus Adapter Sicht wird "stateChange" ausgelöst.

      Jetzt wäre meine Frage:

      wie implementiert man am besten das gleichzeitige ändern mehrerer States in einem Adapter, so dass man diese auch in einer Anfrage an das Gerät weiterleiten kann?

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

        Man erzeugt ein State für das Gerät, welches dann mehr Daten empfangen kann und nicht nur true/false.

        Z.B. Wir haben ein Zustand "hue.0.Lampe0.state", dann im Adapter neuen Zustand generieren "hue.0.Lampe0.command".

        Diese dann kann verschiedene Objekte empfangen, so was wie:

        { 
           r: 100, 
           g: 120, 
           b: 30
        }
        
        

        Man kann natürlich nach Empfang von jedem Zustand 50ms warten, und falls keine neue Zustände für das Objekt innerhalb 50ms gekommen sind, das Kommando an das Gerät raussenden. Aber das ist eher Workaround als Lösung.

        1 Reply Last reply Reply Quote 0
        • P
          Pman last edited by

          @Bluefox:

          Man kann natürlich nach Empfang von jedem Zustand 50ms warten, und falls keine neue Zustände für das Objekt innerhalb 50ms gekommen sind, das Kommando an das Gerät raussenden. Aber das ist eher Workaround als Lösung. `
          Darüber hatte ich auch nachgedacht, aber wäre evtl. zu Fehleranfällig und die zusätzliche Verzögerung will ich vermeiden.

          Deinen anderen Vorschlag hatten wir auch in dem Hue Thread schon diskutiert. Ich werde die Funktion dann vermutlich so implementieren.

          Allerdings finde ich, dass man einen solchen "Sammelstate" evtl. abstrahiert implementieren könnte, so dass die Nutzung dieser Funktion standardisiert möglich ist.

          Vorschlag:

          Nutzerebene:

          setStates(objId,array), wobei array dann so aussähe: [{'state': state1, 'value': value1, 'ack': bool1},{'state': state2, 'value': value2, 'ack': bool2}]

          Adapterebene:

          ab hier bin ich mir nicht mehr sicher was bei aktueller Implementieren überhaupt möglich ist. Ich stelle mir vor, dass man standardmäßig einfach für jedes Element in array den bisher gewöhnlichen setState-Weg gehen könnte (on 'stateChange'), so wäre es auch bei alten Adaptern möglich die setStates Funktionalität zu nutzen.

          Als nächstes müsste es dann irgendwie möglich sein im Adapter eine Funktion zu implementieren, welche alle über setStates geänderten Werte in einem Rutsch verarbeiten kann (so etwas wie: on 'statesChange').

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

            Ich seh das vielleicht zu einfach…

            setState("datenpunkt",{r: 100,g: 120,b: 30});

            -> an den Adapter

            PUT Kommando {r: 100,g: 120,b: 30}

            -> zur Bridge

            So verstehe ich das 🙂 und könnte es extrem einfach in Scripte nutzen.

            Die bisherigen Datenpunkte sollten alle parallel weiter funktionieren, um einzelne Funktionen einfach verändern zu können und für die Nutzung der Datenpunkte in VIS.

            Beim stateChange() müsste man doch wieder schauen, wann was geändert wurde.

            1 Reply Last reply Reply Quote 0
            • P
              Pman last edited by

              Ja genau, dazu könnte man dann einen State im Adapter generieren, welcher so ein array entgegennimmt, verarbeitet und die Änderungen durchführt. Dann könnte man bei diesem speziellen Adapter mehrere States gleichzeitig ändern.

              Meine Frage war ja eher, ob man dieses Vorgehen etwas verallgemeinern kann, so dass das Ändern von mehreren States eines Objektes grundsätzlich in einem Befehl möglich ist.

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

                @Pman:

                Ja genau, dazu könnte man dann einen State im Adapter generieren, welcher so ein array entgegennimmt, verarbeitet und die Änderungen durchführt. Dann könnte man bei diesem speziellen Adapter mehrere States gleichzeitig ändern.

                Meine Frage war ja eher, ob man dieses Vorgehen etwas verallgemeinern kann, so dass das Ändern von mehreren States eines Objektes grundsätzlich in einem Befehl möglich ist. `
                Es wird nicht möglich setStates so zu implementieren, dass die States auch beim Adapter zusammen ankommen.

                Es liegt an der Architektur:

                • Man hat Datenpunkte (DP)

                • Jemand beschreibt diese DPs

                • Jemand (du weißt nicht wer) ist angemeldet, die Änderungen von DPs zu bekommen.

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

                  Es ist aber irgendwann geplant Szene Adapter zu implementieren.

                  Man definiert eine Szene, definiert welche Zustande sind in diese Szene drin und Werte, die Zustände haben müssen.

                  dann hat man "scene.0.Kino". Wenn man "scene.0.Kino" auf true setzt, dann werden alle Zustände in diese Szene auf voreingestellte Werte gesetzt. Falls ein Wert aus der liste sich ändert, dann wird Szene wieder "false". Falls durch einen anderen Adapter die Konstellation von Szene Kino erreicht wird (z.B. manuell geschaltet), dann wird auch "scene.0.Kino" true.

                  Das löst aber dein Problem nicht.

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

                  Support us

                  ioBroker
                  Community Adapters
                  Donate

                  723
                  Online

                  31.7k
                  Users

                  79.8k
                  Topics

                  1.3m
                  Posts

                  3
                  7
                  1672
                  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