Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Pman]

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?

[Bluefox]

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.

[Pman]

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

[ruhr70]

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.

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

[Bluefox]

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

[Bluefox]

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.