Neuer Baustein Hue Group (14100)

[En3rGy]

but would a check at the input with the dictionary suffice to prevent the value being send again to the Hue bridge?

Yes, I could check if the input equals the current expectation of the light status. But this holds the assumption that the expected light status equals the real one. I was not brave enough to assume this

On the other hand: If the user requests a specific input, I think, the module should send / process the input (and does not dismiss it due to “better knowledge what the user wants”).

The problem with the watch address is a design problem of the HS. A specific logic module should not find a work around for this one.

If there is no native solution, I preferred an additional “watch-address-filter” module dealing with this issue.

You should already be able to set this up:
Compare the new input with the current state.
Use the “if” module or a filter module to forward the new input only of different

[cevers]

Yes. Search the forum for that one, there are several posts dealing with this topic. If you have a recommendation for me on how to configure the outputs, feel invited to come back with this.

I have been over your code (which puts mine to shame with my very basic level of python )
And it seems like you send the inputs directly to the device and then the device reacts back with a message which you then use to send to the status outputs, while checking with a dictionary if the value is the same as before. The problem is with the watch address as it updates the input.
Now i might be thinking in the wrong direction, but would a check at the input with the dictionary suffice to prevent the value being send again to the Hue bridge?

I'll try this when i'm home and can test with a Hue bridge.

[En3rGy]

Cool, danke Dir!

Kommt es in die nächste Version und hast Du einen ungefähren Zeitrahmen für das Feature ?

Hier ist ein pre-release. Habe es nicht auf dem HS getestet. Die Unit-Tests waren gut. Die Chancen, dass es sofort klappt schätze ich auf 90%

https://github.com/En3rGy/14100_Hue/releases/tag/v3.6

[diskus]

Cool, danke Dir!

Kommt es in die nächste Version und hast Du einen ungefähren Zeitrahmen für das Feature ?

[En3rGy]

Steht jetzt im Backlog.

[diskus]

Ich habe eine OPNSense Firewall, da kann man vieles machen, ich habe gestern auch ein Multicast DNS-Repeater für beide Subnetze in beide Richtungen installiert. Aber es hat nicht funktiuniert. Könntest Du den Baustein mit einer IP erweitern, ich denke immer mehr Nutzer trennen ihre Netze in Maschinen und Menschennetze oder so wie ich in noch viel mehr .

Vielen Dank!

[En3rGy]

Wenn ein Routing hierfür definiert ist, muss das Routing auch Multicast in beide Richtungen zulassen - wenn das überhaupt geht.

Sonst kann das nur gehen wenn das Auto-Discovery wieder mit einem Eingang zur Vorgabe der IP umgangen werden kann.

Dachte, man könne hier einen Eingang sparen, wer hätte gedacht, dass jemand HS und FritzBox in verschiedene Subnetze packt

[diskus]

Hallo,
ich wollte nun von der 2.0 Version auf die neue Version upgraden. Der HS mit 192.168.6.10 findet die Hue nicht mit der IP 192.168.2.3. Sie befinden sich in unterschiedlichen Subnetzen, geht das dann nicht oder kann man irgendwie nachhelfen?

image.png

[ArchieSmith]

mit der alten API hat´s ja noch gut funktioniert.
Ist evtl. auch 3 Byte RGB vorgesehen ?

[En3rGy]

Die Farbe grün wird auch noch nicht richtig angesteuert

Das liegt an der Umrechnung von RGB zum xy-Farbraum, der von der Hue verwendet wird. Ich benutze hier eine Bibliothek, die im Netz oft dafür empfohlen ist und z.B. auch bei Philips verlinkt wird. Scheine hier in der Anwendung etwas falsch zu machen, obwohl ich mich IMHO an die Anleitung halte.

Die Hue Leuchten können abh. vom Modell verschieben Bereiche des Farbraums abdecken. Welcher das ist wird mit Gamut A, B oder C beschrieben. Wenn eine georderte Farbe außerhalb des möglichen Farbaums liegt, wird durch die genutze Bibliothek die der am nächsten kommende Farbe angesteuert. Das sorgt für den (falschen) Effekt, dass Grün nur als Gelb-Grün angesteuert wird. Kennt jemand den Effekt bzw. hat jemand eine Lösungsidee?

Hier eine Version, bei der ich den Test des möglichen Farbraums herausgenommen habe:
https://github.com/En3rGy/14100_Hue/releases/tag/v3.5

Keine Ahnung, was passiert, wenn eine Farbe kommandiert wird, die außerhalb des möglichen Bereichs ist. ChatGPT behauptet, dass die Leuchte selbst die nächst gelegen Farbe darstellt. Was dem beabsichtigten Effekt des Algorithmus entsprechen würde (warum aber dann die Implementierung im Code?). Kann das Verhalten jemand bestätigen?

[ArchieSmith]

Die Farbe grün wird auch noch nicht richtig angesteuert

[erazor1112]

Das ist schon mal ganz falsch.
Du willst aber nicht die "Befehls-Adresse" abfragen, sondern die "Status-Adresse" und die soll für den Quadclient das Kommunikationsobjekt aktualisieren.
Zentral-Adresse wäre dafür der richtige Ansatz:

Es ist alles in KNX Objekten abgebildet und die Status Objekte jetzt mit Zentral Adressen verknüpft.
Leider habe ich noch immer das gleiche Problem. Hier mal ein paar Screenshots von meiner Config:

image.png

Hier noch meine Logik:

image.png



QC Config mit Color Picker:

image.png

Hast du noch eine Idee was ich falsch mache?

[DirtyHarry]

also habe ich das ganze mit "Watch Adressen" versucht.

Das ist schon mal ganz falsch.

Wenn eines der Watch-Objekt auf dem Bus oder im HS/FS geändert wird, wird der Wert des KNX-Objekts, dem die Watch-Adresse zugeordnet ist, auf dem Bus abgefragt.

Du willst aber nicht die "Befehls-Adresse" abfragen, sondern die "Status-Adresse" und die soll für den Quadclient das Kommunikationsobjekt aktualisieren.
Zentral-Adresse wäre dafür der richtige Ansatz:

Wenn eine der Zentral-Adressen (mit Wert) vom HS/FS empfangen wird, werden alle KNX-Objekte, denen diese Zentral-Adresse zugewiesen wurde, auf den Wert des Zentral-Objekts gesetzt.

[erazor1112]

Hallo,

ich habe den neuen Baustein mittlerweile im Einsatz und mich würde interessieren wie Ihr die Rückmeldungen im HS / QC umgesetzt habt.
Ich nutze im QuadClient entsprechende Funktionen für Dimmen / RGB, diese Funktionen haben aber keine Möglichkeit direkt ein Rückmeldeobjekt einzufügen, also habe ich das ganze mit "Watch Adressen" versucht. Sobald ich die Objekte dann zuweise scheinen sich die Telegramme zu überlagern und es funktioniert nicht mehr wirklich.

Habt Ihr eine Idee woran das liegt?

Gruß
Sascha

[cevers]

Yes. Search the forum for that one, there are several posts dealing with this topic. If you have a recommendation for me on how to configure the outputs, feel invited to come back with this.

In my module i used a check with a remanent object before triggering an output, that seems to work now that i put all my modules back.

if (r['action']['on']) == True:
onoff = 1
brightness = (math.ceil((r['action']['bri'])/2.55))
else:
onoff = 0
brightness = 0​

            if onoff != int(self._get_remanent(self.REM_REMSCHAKEL)):
                self._set_output_value(self.PIN_O_SCHAKEL, onoff)
            if brightness != int(self._get_remanent(self.REM_REMWAARDE)):
                self._set_output_value(self.PIN_O_WAARDE, brightness)
          
            self._set_remanent(self.REM_REMSCHAKEL, onoff)
            self._set_remanent(self.REM_REMWAARDE, brightness)​