Ankündigung

Einklappen
Keine Ankündigung bisher.

Datentyp für 6 Byte KO

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

    Datentyp für 6 Byte KO

    Moin Moin,

    ist es irgendwie möglich einen 6 Bytes großen Datentyp über den Bus in EDOMI zu empfangen?
    Oder ist es geplant so einen Datentypen anzubieten?
    Konkret möchte ich in der Visu die Gerätediagnose darstellen. In der ETS habe ich dafür einen KO mit 6 Bytes.

    In aktuell verfügbaren Datentypen in EDOMI gibt es keinen passenden.
    Als einzige Möglichkeit bliebt dann bis jetzt der "KNX Rohdaten" Datentyp in EDOMI.

    Viele Grüße
    scott

    #2
    Ich möchte hier noch mal nachfragen...
    Jetzt stehe ich wieder vor einem 6 Byte KO.
    Diesmal geht es um das Status KO eines MDT LED Controllers „Ausgabe der Statuswerte für Rot, Grün, Blau und Weiß“.

    Gibt es denn eine Möglichkeit diese KOs ins EDOMI zu bringen?
    Außer als Rohdaten natürlich.

    Viele Grüße
    scott

    Kommentar


      #3
      Bist Du sicher, dass es 6 Bytes sind? Für einen validen RGB-Wert (mit den üblichen 8Bit je Farbkanal) würde ich 3 Bytes erwarten - und dann nutzt man in edomi DPT232. Ansonsten sollte Variant immer gehen - auch mit 6 Bytes. Nur was nützen Dir 6 Bytes, wenn die Interpretation (für mich) fraglich ist: Wie bekommst Du aus den 6 ein nutzbares RGB? Die Frage solltest Du als erstes klären.

      Kommentar


        #4
        Es ist vermutlich der RGBW Controller von MDT und der liefert tatsächlich 6 Byte als RGBW Status, wobei

        Byte 1: R
        Byte 2: G
        Byte 3: B
        Byte 4: W
        Byte 5: 0
        Byte 6: 0

        Mit einem kleinen LBS sollte die Dekodierung problemlos funktionieren.

        scott74: Wenn du mir mal einen Beispielstring der KNX Rohdaten schicken kannst, dann kann ich mir das mal anschauen.

        Kommentar


          #5
          Würde man das nicht besser aufteilen auf 1x DPT232 für RGB und einen Kanal für W? Ich habe bei mir im Haus eine Reihe RGB und RGBW und verarbeite die alle so. Damit kann man die edomi-LBS und Funktionen nutzen. Nur zum Aufteilen braucht es eine Splitter-LBS. Und wenn der Aktor es als Eingang auch wieder so braucht, dann sollte der LBS am besten beide Richtungen können. Vielleicht kann da zum Einstieg auch schon LBS 19000699 und 19000698 helfen.

          Kommentar


            #6
            Ja das könnte tatsächlich sein, dass der 698er LBS schon genau das leistet. Es kommt drauf an, wie die KNX Rohdaten nun wirklich aussehen.

            Kommentar


              #7
              Danke euch für die Mühen.
              Hey, richtig erkannt im letzten Beispiel geht es mir um den RGBW Controller von MDT.
              Auszug aus der Doku angehängt.

              jonofe hat es erkannt. Wobei ich mich nicht nur auf den Controller versteifen wollte.

              Heute Abend kann ich mal die Rohdaten hier einstellen.

              Angehängte Dateien

              Kommentar


                #8
                jonofe
                So hier kommen zwei Rohdaten aus dem Gruppenmonitor: (siehe Anhang)
                6 Byte Status - DPT 251.600
                und zum Vergleich
                3 Byte Status - DPT 232.600

                saegefisch
                Den LBS 19000698 habe ich mir eben angeschaut.. Wüsste aber nicht, wie ich ihn in meinem Fall anwenden soll, wenn ich von dem KO 6 Bytes bekomme.
                Angehängte Dateien

                Kommentar


                  #9
                  ich meinte eigentlich, wie die Daten in Edomi ankommen, d.h. das K.O. als KNX Rohdaten in Edomi definieren und dann schauen, welcher String genau ankommt. Dann kann man erkennen, wie man den Wert dekodieren kann.

                  Kommentar


                    #10

                    Aus den Screenshots vermute ich mal...
                    Das eine ist RGBW mit 6Byte: "#00a19cdf000f", ich vermute mal, es wäre "#00a19c" der RGB-Wert und "#df" der W-Wert.
                    Das andere ist der HSV-Wert als 3-Byte (DPTZ232): #7e5bdf, wäre rein technisch aber für RGB wohl gelich-formatig, hier eben "#00a19c"

                    LBS 19000698 würde wohl mit dem Input "#00a19cdf000f" die 4 Kanäle R/G/B/W ausgeben (der LBS schneidet Stringteile aus und ignoriert alles nach dem 4.Wert). Der LBS würde aus R/G/B/W einen #ffffffff machen, da müsste man wohl noch 0000 oder 000f "drankleben" um auf die 6Bytes zu kommen und ab zum MDT zurück.

                    Am besten mal das Coding anschauen und ggf. auf eigene Anforderungen umsetzen - das ist recht einfach und gut zu lesen. Oder mit den beiden mal anfangen zu testen. KOs anlegen (ich würde mal mit Variant anfangen) und dem Spieltrieb freien Lauf lassen... einfach mal anfangen und bei Bedarf Screenshots von Deiner Logik, am besten im Liveview zeigen - da sollten die Rohdaten in edomi ja irgendwo sichtbar sein...
                    Zuletzt geändert von saegefisch; 05.05.2018, 00:55.

                    Kommentar


                      #11
                      Nach dem Screenshot scheint es so zu sein, dass grundsätzlich auf dem KNX 00,RR,GG,BB,00,WW gesendet wird. Ich habe leider nicht die Konnex DPT Beschreibung gefunden, in der die Struktur der 6 Byte dokumentiert ist.

                      Die obige Struktur angenommen, macht Edomi daraus den Komma-separierten Rohdatenstring: 00,00,RR,GG,BB,00,WW.
                      Erstes Byte steht dabei immer für den Bit-Datentyp und muss ignoriert werden, genauso das Byte 2 und 6.

                      Danach ist es eigentlich ganz einfach:

                      ==> LBS19001579-DPT251.600-RGBW

                      Kommentar


                        #12
                        jonofe => Danke für den schnellen schlanken LBS. Auf den kann man aufbauen.
                        saegefisch
                        ...weiter geht's. Wir haben immernoch den Spielmodus an.

                        In Edomi kommt noch etwas anderes an.
                        Screenshot aus dem Gruppenmonitor und Edomi anbei.

                        Edomi empfängt: 00,00,0e,15,ff,00,0f
                        ETS hat diesen Wert: 00 0E 15 FF 00 0F

                        Ich hoffe, ich habe hier keine Verwirrung gestiftet, aber ich fahre nicht die einzelnen Farbkanäle an, sodern folge der Empfehlung von MDT und nutze HSV.
                        Daher sind in den einzelnen Bytes die Werte von HSV.
                        Zum Vergleich habe ich in dem Screenshot aus dem Gruppenmonitor auch die einzelnen Statuswerte eingefügt.
                        Trotzdem verstehe ich den Zusammenhang nicht, wenn ich mir als Erläuterung die Beschreibung von MDT anschaue (siehe Screenshot im Post 7). Demnach hätte ich erwartet dass in den sog. Kombi-Status-KOs die RGB Werte und zusätzlich Weiß stehen.

                        Nach meinen Recherchen ergeben die HSV Werte aus meinem Screenshot den RGB-Hex-Wert #EBF8FF
                        (Umgerechnet auf dieser Seite: https://www.rapidtables.com/convert/...sv-to-rgb.html )
                        Diese Info finde ich aber nicht in den zusammengefassten Status-Objekten.


                        Angehängte Dateien

                        Kommentar


                          #13
                          auf Deinem Screenshot in Post #8 war der HSV-Wert aber 3Bytes (DPT232), nicht 6. Mir wäre auch kein "HSVW" bekannt - was nicht heißt, dass es das nicht gibt. Mit HSV hast Du nach meinem Verständnis das ganze Thema mit den 6 Bytes doch gar nicht; den W-Kanal muss Du dann vermutlich einzeln anfahren (1 Byte).
                          RGB ist technisch klarer, HSV ist halt "menschlicher"/praktischer. In Edomi findest Du Funktionen und LBS zum wandeln; ich würde mal eine Testseite mit RGB und HSV machen für den Aktor, Anbindung per HSV + W an den Aktor. Ob Du recht hast oder nicht, das zeigt Dir gleich das Licht...

                          Kommentar


                            #14
                            Ich kann jetzt nicht mehr ganz folgen. Habe ja ober erklärt wo die erste 00 bei Edomi herkommt.
                            Daher liefert der LBS auch das Byte 3,4,5 und 7. Und wenn der Aktor DPT251.600 liefert, dann sollte das passen.

                            Wo genau kommt jetzt bei dir HSV her? Wenn der Ausgang beim MDT DPT251.600 liefert, dann sollte es doch RGBW sein und nicht HSV.

                            Kommentar


                              #15
                              ich denke, wir reden von zweierlei verschiedenen GA des Aktor: einmal 6-Bytes - in der von Dir analyiserten Struktur und HSV als 3-Bytes. Vermutlich auch RGB als 3-Bytes und W als 1 Byte. Mir scheint - aus der Ferne - das Thema 6-Bytes umschiffbar, wenn man primär über hSV steuern will... das wäre das Thema wohlmöglich kein Thema mehr. Oder ich kann nicht mehr folgen. Oder wir beide. Komm' lass uns was trinken gehen...

                              Kommentar

                              Lädt...
                              X