Neuer Baustein Hue Group (14100)

[erazor1112]

Kommt automatisch. Ich habe nichts mit Get Status verknüpft.
Hast du deine Bridge im selben Subnetz? Ich habe sie in einem anderen. Da muss man dann schauen, dass alle Firewall regeln passen. Ansonsten funktioniert das eigentlich auch so.

Ist bei mir alles im gleichen Subnetz, muss ich mir nochmal anschauen warum da nix ankommt...

[SpleXyo]

Triggerst du den Update oder kommt der automatisch?

Kommt automatisch. Ich habe nichts mit Get Status verknüpft.
Hast du deine Bridge im selben Subnetz? Ich habe sie in einem anderen. Da muss man dann schauen, dass alle Firewall regeln passen. Ansonsten funktioniert das eigentlich auch so.

[erazor1112]

Hmm. Du kannst natürlich die Verzögerung auf 0.01 oder noch weniger setzen. Das sollte dem oberen Baustein für den Vergleich schon reichen. Ich glaube ich schreib mal schnell einen Baustein, welcher das alles in einem macht, dann ist auch keine Verzögerung notwendig.
Wenn zu schnell 2 Befehle kommen kann man leider schlecht verhindern, dass sich der Baustein verschluckt, da die RM Werte erst nach einer gewissen Verzögerung ausgegeben werden. Damit müssen wir uns denke ich abfinden. Aber zumindestens sollten Loops verhindert werden.


Dafür bin ich leider nicht Zuständig, ist ja nicht mein Baustein. Aber zumindestens bei mir aktualisiert der Hue Baustein ca. alle 5 Sekunden seine Outputs. Also eigentlich müsste das schon gehen. Wenn ich über die Hue App die Lampen anschalte, dann ist auch 3-4s später der EIN & Brightness status im QC zu sehen.

Ein eigener Baustein wäre schon mega!
Ja, Hauptsache die Loops sind weg, da kann man jetzt schon ganz vernünftig mit arbeiten.

Triggerst du den Update oder kommt der automatisch?

[SpleXyo]

Leider ist jetzt alles ein wenig verzögert und wenn man zu schnell 2 Befehle ausführt verschluckt er sich manchmal.

Hmm. Du kannst natürlich die Verzögerung auf 0.01 oder noch weniger setzen. Das sollte dem oberen Baustein für den Vergleich schon reichen. Ich glaube ich schreib mal schnell einen Baustein, welcher das alles in einem macht, dann ist auch keine Verzögerung notwendig.
Wenn zu schnell 2 Befehle kommen kann man leider schlecht verhindern, dass sich der Baustein verschluckt, da die RM Werte erst nach einer gewissen Verzögerung ausgegeben werden. Damit müssen wir uns denke ich abfinden. Aber zumindestens sollten Loops verhindert werden.

Was noch schön wäre, wenn Brightness, Red, Green und Blue den Status nach dem Einschalten bzw. ändern nochmal senden, damit das in der Visu richtig angezeigt wird.

Dafür bin ich leider nicht Zuständig, ist ja nicht mein Baustein. Aber zumindestens bei mir aktualisiert der Hue Baustein ca. alle 5 Sekunden seine Outputs. Also eigentlich müsste das schon gehen. Wenn ich über die Hue App die Lampen anschalte, dann ist auch 3-4s später der EIN & Brightness status im QC zu sehen.

[erazor1112]

Also habe heute nach mehr als 1 Jahr mal den Hue Baustein geupdated und dann gleich die Beta von GitHub gezogen, da meine Hue Bridge in einem Isolierten Subnetz liegt. Einrichtung hat super funktioniert und das eintrag der manuellen IP auch! 👍


Also ich habe mit der neuesten Version und hatte mit der ältern auch immer dieses Problem und habe mich dem Ganzen mal angenommen.
Ich bin zu aktuell folgender vorläufiger Lösung gekommen. (Vielleicht packe ich das Ganze noch in einen HSL2 Baustein und nenne Ihn "RM Loop Prevention". Kann man tatsächlich immer wieder brauchen. Möglicherweise wird diese Logik aber auch irgendwann mal in den Hue Baustein übernommen.)

grafik.png

Hinweis: Die RM Adressen sind als Zentral Adressen bei den normalen Adressen hinterlegt. RM = Rückmeldung
Idee meiner kleinen Konstruktion zwischen den Eingängen und dem Hue Baustein:
Das Problem warum diese komischen Loops entstehen ist, das der Baustein und auch die RM des Bausteins eine gewisse Latenz haben oder während die Lampen im Dimmvorgang sind komische RM Werte ausspucken. Wenn diese RM dann durch die Zentrale Adresse auf das Schalt / Wertobjekt geschrieben wird, will der Baustein diesen Wert an die Lampe schicken, obwohl das nicht gewünscht war. Ich hatte auch denn Fall, dass das Delay genau so war, das der Baustein kontinuierlich zwischen 2 Werten hin und hergesprunge ist.
Also was machen meine 3 Bausteine da, für den, den es interessiert: Wenn der Wert des RM und Steuerobjektes gleich ist (also wenn der Baustein einen RM geschrieben hat) dann möchte ich nicht, dass dieser wieder im Baustein als Eingang landet. Also wird geprüft, ob RM und Steuerobjekt ungleich sind. Sind sie es nicht, wird gesperrt, und der Wert des Steuerobjektes kann den Eingang nicht erreichen. Die Verzögerung ist notwendig, da sonst der neue Wert durch die Sperre rutscht, bevor diese sperren kann, da der Vergleich noch berechnet wird.
Wenn nun ein Nutzer über QC oder KNX das Licht ändern will ist RM ungleich Steuerobjekt und der Wert darf passieren. Das ganze könnte ich wie gesagt noch in einen HSL Baustein packen. Aber aktuell keine Lust.

Hoffe das hilft dir und dem ein oder anderen.

Hatte auch das Problem mit den Loops und mit deiner Lösung funktioniert es jetzt endlich, Danke
Leider ist jetzt alles ein wenig verzögert und wenn man zu schnell 2 Befehle ausführt verschluckt er sich manchmal.

Was noch schön wäre, wenn Brightness, Red, Green und Blue den Status nach dem Einschalten bzw. ändern nochmal senden, damit das in der Visu richtig angezeigt wird.

[diskus]

Habe es ausprobiert, scheint am Setzen der Konstante mit dem Text zu liegen . Wie kann ich mit einem Logikbaustein bei einem Signal = 1 auslösen, dass ein Text (14 Byte) direkt als Item ID oder Scene ID im Baustein gesetzt wird? Habt Ihr einen Tipp.

image.png
Wenn ich Off an 1. Stelle setze, dann geht die zuletzt geschaltete Lampe schnell aus . Aber das ist ja leider dann Zufall.

[En3rGy]

Darüber hinaus habe ich folgende Fehler im Log

Sieht so aus, als sei bei irgendeinem Schaltvorgang die Id noch nicht parat.
Der Baustein reagiert bei Signalen an den Eingängen. Du müsst sicher stellen, dass die richtige Id da ist, booze ein Schalt- oder Szenen-Kommando kommt.

Ob das mit den 3 sec damit zusammenhängt?

Korrektur: So wie es aussieht passiert der Fehler ja nur 1x, vermutlich beim Starten des HS, also vermutlich ein Initialisierungs-Problem.

Schon mal versucht, im Experten den Eingang zur Laufzeit zu setzen, und zu schauen, ob‘s am Baustein on an der Bereitstellung der Signale liegt?

[SpleXyo]

Also habe heute nach mehr als 1 Jahr mal den Hue Baustein geupdated und dann gleich die Beta von GitHub gezogen, da meine Hue Bridge in einem Isolierten Subnetz liegt. Einrichtung hat super funktioniert und das eintrag der manuellen IP auch! 👍

Hast du noch eine Idee was ich falsch mache?

Also ich habe mit der neuesten Version und hatte mit der ältern auch immer dieses Problem und habe mich dem Ganzen mal angenommen.
Ich bin zu aktuell folgender vorläufiger Lösung gekommen. (Vielleicht packe ich das Ganze noch in einen HSL2 Baustein und nenne Ihn "RM Loop Prevention". Kann man tatsächlich immer wieder brauchen. Möglicherweise wird diese Logik aber auch irgendwann mal in den Hue Baustein übernommen.)

grafik.png

Hinweis: Die RM Adressen sind als Zentral Adressen bei den normalen Adressen hinterlegt. RM = Rückmeldung
Idee meiner kleinen Konstruktion zwischen den Eingängen und dem Hue Baustein:
Das Problem warum diese komischen Loops entstehen ist, das der Baustein und auch die RM des Bausteins eine gewisse Latenz haben oder während die Lampen im Dimmvorgang sind komische RM Werte ausspucken. Wenn diese RM dann durch die Zentrale Adresse auf das Schalt / Wertobjekt geschrieben wird, will der Baustein diesen Wert an die Lampe schicken, obwohl das nicht gewünscht war. Ich hatte auch denn Fall, dass das Delay genau so war, das der Baustein kontinuierlich zwischen 2 Werten hin und hergesprunge ist.
Also was machen meine 3 Bausteine da, für den, den es interessiert: Wenn der Wert des RM und Steuerobjektes gleich ist (also wenn der Baustein einen RM geschrieben hat) dann möchte ich nicht, dass dieser wieder im Baustein als Eingang landet. Also wird geprüft, ob RM und Steuerobjekt ungleich sind. Sind sie es nicht, wird gesperrt, und der Wert des Steuerobjektes kann den Eingang nicht erreichen. Die Verzögerung ist notwendig, da sonst der neue Wert durch die Sperre rutscht, bevor diese sperren kann, da der Vergleich noch berechnet wird.
Wenn nun ein Nutzer über QC oder KNX das Licht ändern will ist RM ungleich Steuerobjekt und der Wert darf passieren. Das ganze könnte ich wie gesagt noch in einen HSL Baustein packen. Aber aktuell keine Lust.

Hoffe das hilft dir und dem ein oder anderen.

[diskus]

Guten Abend,

ich habe den Baustein erfolgreich zum Laufen bekommen. Ich habe 35 Lampen, daher setze ich diese mit Konstanten. Allerdings habe ich folgendes Problem. Das Einschalten geht sofort, das Auschalten der Lampe dauert > 3 Sekunden und damit zu lang. Über die Hue App reagiert die Lampe sofort. Habe auch die Bridge neu gestartet. Habt Ihr eine Idee?

Hier meine Logik:
image.png


Darüber hinaus habe ich folgende Fehler im Log:

image.png
Hardware ist eine Hue (3. Generation) und ein HS (i24).

[diskus]

Der neuen Baustein (3.6) verbindet sich über den IP Parameter auch mit anderen Subnetzen. Danke!

Konnte auch einmal ein Licht schalten, jetzt muss ich meine Programmierung anpassen.

image.png

[diskus]

Hallo En3rGy,

Vielen Dank! Ich werde die neue Version am Wochenende testen und Feedback geben.

Einen tollen Start in die Woche
Christian

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