Ankündigung

Einklappen
Keine Ankündigung bisher.

RGB/W-Dimmer in GPA => RGB-Wert statt einzelne R-G-B-Werte?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #31
    Ja, ist eingeschaltet...

    Kommentar


      #32
      Und er funktioniert doch, der Color-Picker in der X1-Funktion "Dimmer (RGB / RGBW)" 😂😊🤩 praktisch ein Monat habe ich gebraucht, bis ich es sehen konnte...
      • Bei diesem Dimmer hängt alles zusammen: Ein/Aus, R-G-B und Helligkeitswert
      • Die Status-Rückmeldung muss zur Vorgabe des Dimmers passen, sonst will er nicht, siehe oben
      • Der Datenpunkt-Typ für Helligkeitswert, Rot, Grün und Blau muss 1 Byte 5.001 sein - das war mein entscheidender Fehler - also DPT_Scaling [0...100] %
      Mangels HUE-Lampen habe ich eine Simulation im X1 gebaut, die die Vorgabe als Status zurück sendet; dann kann ich sogar die eingestellte Farbe dimmen.

      Mein "Beweis-Foto" ist ein screenshot von der Windows Smart Home App.
      You do not have permission to view this gallery.
      This gallery has 1 photos.

      Kommentar


        #33
        knxPaul
        So, jetzt habe ich mir endlich mal die Zeit genommen um das noch mal anzugehen... Und Deine Hinweise waren echt sehr hilfreich. Ich habe mir jetzt die Umrechnung und Übertragung in einen RGB-Datenpunkt gespart und habe stattdessen 3 Prozenzt-Datenpunkte (wie ja von Dir bereits herausgefunden) verwendet.

        Dabei habe ich aber - bereits auf dem DP-Monitor - eine zusätzliche Besonderheit festgestellt. Keine Ahnung ob das "normal" ist, ich fand es seltsam und es erfordert (in meinem Fall) eine zusätzliche Umrechnung: Und zwar wird der RGB-Wert nicht etwa absolut in % ausgegeben (Beispiel "Knall-Rot" wäre dann ja 100%,0%,0%) sondern das Maximum ist immer die Helligkeit... D.h. bei 50% Helligkeit kommt man bei "Knallrot) auf 50%,0%,0%. Wie gesagt ich finde es eher Quatsch, weil man so - gerade bei niedrigen Helligkeiten ja massiv an Genauigkeit verliert. Sehr gut testen kann man das übrigens bei Helligkeit 0%, da kann man den Color-Picker zwar bedienen aber auf dem Bus wird egal welche Farbe man auswählt immer 0%, 0%, 0% ausgegeben...
        Ich bin mit der Umrechnen und Basteln noch nicht fertig, aber es geht voran. Weiß jemand ob dieses Verhalten für einen KNX-Color-Picker (mit Dimmer) normal ist, oder hat sich Gira das so ausgedacht?

        Kommentar


          #34
          Ich empfinde das als normal und logisch, knallrot ist knallrot, ob dunkel oder hell. Was möchtest du denn an Werten haben?
          Gruß Florian

          Kommentar


            #35
            Hallo Florian,
            Deine Beschreibung passt Du dem was ich erwartet hätte, aber nicht zu dem was ich beschrieben habe, wie es beim Color-Picker gemacht wird.
            Ich versuche es noch mal anders zu erklären:
            Ich möchte knallrot haben, dann erwarte ich dass als RGB-Wert 100,0,0 gesetzt wird, ganz unabhängig von der Helligkeit (die dann von 0 bis 100 gehen kann), d.h. dunkkles (10% Dimmung) Knallrot wäre 100,0,0,10 bis hin zu ganz hellem Knallrot 100,0,0,100...

            Passieren tut aber folgendes: dunkles hellrot ergibt 10,0,0,10 bis hin zu hellem Knallrot 100,0,0,100...

            Ich finde es unlogisch, dass der Farbton abhängig von der Helligkeit ist, dann könnte ich mir den separaten Helligkeitsregler auch gleich sparen, oder?

            Kommentar


              #36
              Zitat von martiko Beitrag anzeigen
              Ich finde es unlogisch, dass der Farbton abhängig von der Helligkeit ist, dann könnte ich mir den separaten Helligkeitsregler auch gleich sparen, oder?
              Kannst Du aus Sicht Gira auch: Der Datenpunkt Helligkeitswert im Dimmer ist optional 😀 und das liegt daran, dass die X1-Funktionen vom Benutzer nicht geändert / neu erstellt werden können und daher für Alles passen müssen. Also kann der Dimmer sowohl mit als auch ohne Einstellung der Helligkeit eingesetzt werden.

              Beobachtet habe ich das Verhalten exakt wie Du - das ist selbstverständlich

              Kommentar


                #37
                Hallo zusammen,

                ich habe das Ganze ja über Node Red implementiert und nachdem es trotz der Tipps hier aus dem Thread und einigem Herumprobieren noch nicht ganz wie gewünscht geklappt hat, bin ich ein bisschen auf die Suche gegangen... und siehe da, der Hue-Magic-Node, den ich im Einsatz hatte, hat tatsächlich einen Bug (ganz unabhängig von KNX und/oder dem X1-Color-Picker): Der zugerückgemeldete RGB-Status stimmt einfach nicht, ich habe die Hue-Farbe eingestellt und als Status kamen ganz andere Werte zurück (das hat dann als Status an den X1-Color-Picker zu sehr komischen Effekten geführt...).
                Nachdem ich jetzt einen anderen Hue-Node verwende, sieht das Ganze schon viel besser aus! Mir gefällt zwar diese Verknüpfung von Helligkeit und RGB-Werten nicht (die macht, wie knxPaul erwähnt hat für mich nur Sinn, wenn man keinen separaten Helligkeits-Kanal hat, das sollte Gira sich mal überlegen...), aber ich habe darauf verzichtet, das durch irgendwelche Umrechnungen auszugleichen.
                Ich nutze jetzt einfach wirklich 4 separate GAs für RGB und Hellingkeit und noch eine fürs Schalten (und das Gleiche dann noch mal für die Statuswerte) und das funktioniert sehr gut. Die Einzige Umrechnung, die ich auf Node-Red-Seite dann noch brauchte war von dem Prozentwert, den der Gira-Color-Picker liefert in 0..255 (und umgekehrt 0..255 => 0..100% für den Status). Damit klappt es jetzt sehr gut und mit wenig Node.
                Was ich mir gespart habe ist die Umsetzung von relativem Dimmen, ich werde die Hue-Bedienung ohnehin nicht auf einen Glastaster legen (dafür würde ich es brauchen, der arbeitet ja mit relativem Dimmen im Gegensatz zu den X1-Dimmern/Colorpickern).

                Also noch mal danke für die tollen Tipps und Hinweise, ohne Euch (speziell knxPaul ) hätte ich das vermutlich nie hinbekommen!

                Viele Grüße
                Martin

                Kommentar

                Lädt...
                X