Ankündigung

**Msinn** · 19.04.2020, 09:31

Ich verstehe die Frage nicht:

Zitat von aldaris Beitrag anzeigen

Das kann man jetzt mit eval und eval_trigger bauen, nur baue ich dann ja "Endlosschleifen". Ist das der Fall, oder wird eval_trigger Wert sich nicht auslösen, wenn ein Wert von 240 auf 240 geändert wird? Gibt es sonst Lösungen?

Da fehlen Informationen:
- Wie ist das Item definiert?
- Was meinst Du mit (251.600)?
- Du sprichst von mehreren Items. Welche Items, wie definiert und wofür genutzt?
- Hast Du "Ist das der Fall, oder wird eval_trigger Wert sich nicht auslösen, wenn ein Wert von 240 auf 240 geändert wird?" das mal ausprobiert?
- Hast Du Dir mal angeschaut was enforce_updates tut?

**aldaris** · 19.04.2020, 10:53

Hallo,

vielen Dank für die schnelle Antwort. Ich habe vielleicht etwas schneller geschrieben, ich veruch es mal einfacher, mit Beispiel:
Ich beziehe mich auf diese Seite: https://www.smarthomeng.de/user/beispiele/eval.html
Das Beispiel "Erzeugen einer Liste aus den Werten anderer Items" ist das Item Beispiel, bei dem der RGB Wert aus Einzelerten zusammengesetzt wird.
Das ist aber eben nur in eine Richtung. Wenn die die r(), g(), b() items z.B. mit basic.colordisk verbinde werden diese z.B. über die Visu verändert. Diese Veränderung müsste aber nun auf das Hauptitem zurückübertragen werden, um es z.B. mit KNX an den Aktor zu senden.

- Wie ist das Item definiert? ) => siehe oben
- Was meinst Du mit (251.600)? => Das ist der KNX Typ für 4 Byte. Für smarthomeng ist vermutlich eher die Info "list" wichtig.
- Du sprichst von mehreren Items. Welche Items, wie definiert und wofür genutzt? => RGBW für KNX, RGB für Alexa, R, G, B, W für Slider an der UI
- Hast Du "Ist das der Fall, oder wird eval_trigger Wert sich nicht auslösen, wenn ein Wert von 240 auf 240 geändert wird?" das mal ausprobiert? => Nein, wollte erstmal Infos sammeln und das Gerät nicht aufhängen
- Hast Du Dir mal angeschaut was enforce_updates tut? => Ja, habe den Nutzen für das Problem aber nicht verstanden.

Gruß
aldaris

**Msinn** · 19.04.2020, 12:38

Meinst Du mit basic.colordisk ein Widget aus der SmartVISU? Ich kenne das nicht. Vermutlich kann Dir da eher im smartVISU Forum jemand weiterhelfen der das Widget einsetzt.

Zitat von aldaris Beitrag anzeigen

Wie ist das Item definiert? ) => siehe oben

Mit solchen Antworten kann ich nichts anfangen. Oben steht keine Item Definition!

Zitat von aldaris Beitrag anzeigen

Hast Du Dir mal angeschaut was enforce_updates tut? => Ja, habe den Nutzen für das Problem aber nicht verstanden.

Vieleicht nichts, aber ohne vernünftige Beschreibung von Dir hilft nur die hier:

**Onkelandy** · 19.04.2020, 13:40

Zitat von aldaris Beitrag anzeigen

Ist das der Fall, oder wird eval_trigger Wert sich nicht auslösen, wenn ein Wert von 240 auf 240 geändert wird? Gibt es sonst Lösungen?

Wenn du kein enforce_updates nutzt, wird beim Schreiben von 240, wenn das Item schon 240 ist, nichts passieren.

**aldaris** · 19.04.2020, 13:48

Hallo,

ich habe die Glaskugel bemüht. Ich kopiere das Item aus dem Link, damit du siehst, das ich sehe:

Code:

rgb:
    name: RGB
    type: list
    cache: yes
    eval: "[sh..r(), sh..g(), sh..b()]"
    eval_trigger:
        - .r
        - .g
        - .b
    r:
        name: Wert für Rot
        type: num
        cache: yes
        visu_acl: rw
    g:
        name: Wert für Grün
        type: num
        cache: yes
        visu_acl: rw
    b:
        name: Wert für Blau
        type: num
        cache: yes
        visu_acl: rw

**aldaris** · 19.04.2020, 13:50

Das mit dem Enforce_Updates habe ich auch gesehen. Ich denke das "on_change" der richtige Weg sein könnte, um die jeweils andern Items anzupassen. Passt wird ebenfalls nur bei Wertänderung gefeuert

**Msinn** · 19.04.2020, 18:15

Zitat von aldaris Beitrag anzeigen

ich habe die Glaskugel bemüht. Ich kopiere das Item aus dem Link, damit du siehst, das ich sehe:

Lass Dir nicht alles aus der Nase ziehen. Du sprichst von KNX und von der smartVISU. Für keines von beiden hast Du in Deinem obigen Beispiel Attribute angegeben.

Und: Was machst Du mit der Liste die eval erzeugt? Für das von Dir angegebene basic.colordisc brauchst Du es jedenfalls nicht. Siehe smartVISU Doku:

Code:

{{ basic.colordisc(id, item_r, item_g, item_b, min, max, step, colors) }}

Dort übergibst Du die einzelnen Farben und die Visu gibt Dir dann die veränderten Werte zurück.

Du solltest schauen wie Du Deinen RGBW Controller (welchen überhaupt?) anders ansprichst, zumal das knx Plugin das DPT 251.600 nicht unterstützt, wie Dir ein Blick in die Doku verraten hätte.

**aldaris** · 19.04.2020, 18:53

Hallo,

ich weiß nicht, warum unsere Kommunikation nicht recht funktionieren will. Ich habe den items.yaml Abschnitt noch nicht fertig, da ich eben nicht weiß, wie der aufgebaut werden soll. Aber ich kann gerne nochmal versuchen, das an oben dem Beispiel weiter zu spezifieren, wie es, meiner Meinung nach, aussehen könnte.

a) rgb bekommt genau oben das colordisk ding
b) Ausserdem hätte ich gern getrennte slider für jede Farbe (eigentlich 4, aber in dem RGB Beispiel nur 3)
c) Für die Farbsteuerung brauch ich den ColorController, also Alexa4p3. Hier eben das list Item mit 3 Werten.

Code:

rgb:
    name: RGB
    type: list
    cache: yes
    sv_widget: {{ basic.colordisc('somedisk', 'item.r', 'item.g', 'item.b') }} (a)
    alexa_actions = "SetColor" (c)
    alexa_color_value_type = RGB
    alexa_icon = "LIGHT"
    eval: "[sh..r(), sh..g(), sh..b()]"
    eval_trigger:
        - .r
        - .g
        - .b
    r:
        name: Wert für Rot
        type: num
        cache: yes
        sv_widget: {{ basic.slider('redslider', 'item') }} (b)
        visu_acl: rw
    g:
....

So, der Controller ist ein MDT AKD 0424R02.2. In der Tat habe ich aber übersehen, dass der 4 Byte Typ nicht unterstützt wird. Der Controller kann umgestellt werden zwischen einzeln (4 x 1 Byte), RGB + Weiss (3 Byte + 1 Byte) und RGBW (4 Byte). Schade dass 4 Byte nicht geht, dann muss ich eben RGB + W nehmen, wenn man das nicht erweitern kann.

Was will ich eigentlich: Es gibt zwei gleichwertig Repräsenationen im obigen Beispiel: RGB oder eben r, g, und b getrennt. Ich will davon einen über KNX mit dem Controller per send und listen verbinden, die andere Repräsentation über smarthomeng, also ohne den KNX bus, synchronisieren. Für meinen konkreten Fall mit RGBW ist es nochmal der weiß Kanal dazu, aber wenn mir das prinzip klar ist, hoffe ich das zu erweitern.

Mir ist klar, wie ich das mit logiken machen würde:

Eine Logik, die auf Änderung von RGB horcht und r, g und b daraus umsetzt und eine andere logik, die auf r, g und b horcht und RGB berechnet.

Ich interessiere mich aber dafür, ob dass nicht auch ohne logik geht.

**Msinn** · 19.04.2020, 19:08

Dadurch dass Du nicht den 4-Byte Wert nimmst, löst sich Dein Problem der "Konvertierung in beide Richtungen" in Luft auf, weil Du dann keine rdb Representation brauchst. Also wieso ist das dann schade?

Zu Alexa kann ich nichts sagen, da ich weder Alexa noch das Plugin nutze.

Den rgbw Controller der in meiner Installation sein ca. 8 Jahren seinen Dienst versieht, spreche ich so an:

Code:

wohnung:
    dusche:
        spiegelleuchte_weiss:
            name: Spiegelleuchte weiss
            type: bool
            knx_dpt: 1
            knx_send: 1/1/38
            knx_cache: 1/2/38

            level:
                type: num
                visu: 'yes'
                knx_dpt: 5
                knx_send: 1/4/38
                knx_cache: 1/5/38

        spiegelleuchte_rot:
            name: Spiegelleuchte LED farbig
            type: bool
            knx_dpt: 1
            knx_send: 1/1/35
            knx_cache: 1/2/35

            level:
                type: num
                visu: 'yes'
                knx_dpt: 5
                knx_send: 1/4/35
                knx_cache: 1/5/35

        spiegelleuchte_gruen:
            name: Spiegelleuchte grün
            type: bool
            knx_dpt: 1
            knx_send: 1/1/36
            knx_cache: 1/2/36

            level:
                type: num
                visu: 'yes'
                knx_dpt: 5
                knx_send: 1/4/36
                knx_cache: 1/5/36

        spiegelleuchte_blau:
            name: Spiegelleuchte blau
            type: bool
            knx_dpt: 1
            knx_send: 1/1/37
            knx_cache: 1/2/37

            level:
                type: num
                visu: 'yes'
                knx_dpt: 5
                knx_send: 1/4/37
                knx_cache: 1/5/37
                comment: Abluft

also als wären das 4 von einander unabhängige Dimmer. Die level Items übergebe ich dann an das von mir genutzte Widget für die smartVISU.

**aldaris** · 20.04.2020, 20:09

Einen wunderschönen,

ich habe es mit on_Change lösen können. Falls noch jemand ein ähnliches Problem hat, hilft das hier vielleicht

Code:

Test:
    name: Test
    type: bool
    knx_dpt: 1

    rgbwLevel:
        name: rgbwLevel
        type: list
        on_change:
            - "sh..rgbLevel([sh..self()[0], sh..self()[1], sh..self()[2]])"
            - "sh..rgbLevel.rLevel(sh..self()[0])"
            - "sh..rgbLevel.gLevel(sh..self()[1])"
            - "sh..rgbLevel.bLevel(sh..self()[2])"
            - "sh..wLevel(sh..self()[3])"
        rgbLevel:
            name: rgbLevel
            type: list
            on_change:
                - "sh....rgbwLevel([sh..self()[0], sh..self()[1], sh..self()[2], sh....rgbwLevel()[3]])"
                - "sh..rLevel(sh..self()[0])"
                - "sh..gLevel(sh..self()[1])"
                - "sh..bLevel(sh..self()[2])"
            rLevel:
                name: rLevel
                type: num
                on_change:
                    - "sh.....rgbwLevel([sh..self(), sh.....rgbwLevel()[1], sh.....rgbwLevel()[2], sh.....rgbwLevel()[3]])"
                    - "sh....rgbLevel([sh..self(), sh....rgbLevel()[1], sh....rgbLevel()[2]])"
          gLevel:
              name: gLevel
              type: num
              on_change:
                  - "sh.....rgbwLevel([sh.....rgbwLevel()[0], sh..self(), sh.....rgbwLevel()[2], sh.....rgbwLevel()[3]])"
                  - "sh....rgbLevel([sh....rgbLevel()[0], sh..self(), sh....rgbLevel()[2]])"
          bLevel:
              name: bLevel
              type: num
              on_change:
                  - "sh.....rgbwLevel([sh.....rgbwLevel()[0], sh.....rgbwLevel()[1], sh..self(), sh.....rgbwLevel()[3]])"
                  - "sh....rgbLevel([sh....rgbLevel()[0], sh....rgbLevel()[1], sh..self()])"
       wLevel:
           name: wLevel
          type: num
          on_change:
              - "sh....rgbwLevel([sh....rgbwLevel()[0], sh....rgbwLevel()[1], sh....rgbwLevel()[2], sh..self()])"

Um das jetzt vollumfänglich nutzen zu können, würde ich gerne noch fragen, ob und falls ja wie ich das knx plugin erweitern kann, um den 4 Byte Typ zu senden und zu lesen.

Reicht eine Erweiterung wie folgt? (in dpts.py)

Code:

def en251(value):
    return [0, int(value[0]) & 0xff, int(value[1]) & 0xff, int(value[2]) & 0xff, int(value[3]) & 0xff]


def de251(payload):
    if len(payload) != 4:
        return None
    return list(struct.unpack('>BBBB', payload))

**wvhn** · 20.04.2020, 20:36

Am Ende der dpts.py musst Du die Datenpunkte nochmal in die "decode" und "encode" Arrays eintragen. Dann sollte es gehen.

Das Dumme ist, dass Du die Änderungen beim nächsten Update von shNG neu einpflegen musst. Deswegen hatte ich mal ein "Plugin" für die Datenpunkte vorgeschlagen und als Prototyp umgesetzt, über das man seine eigenen dpts integrieren kann. Daraus ist aber nichts geworden.

Gruß
Wolfram

**Sisamiwe** · 20.04.2020, 21:04

Zitat von wvhn Beitrag anzeigen

Das Dumme ist, dass Du die Änderungen beim nächsten Update von shNG neu einpflegen musst. Deswegen hatte ich mal ein "Plugin" für die Datenpunkte vorgeschlagen und als Prototyp umgesetzt, über das man seine eigenen dpts integrieren kann. Daraus ist aber nichts geworden.

Könnt ihr dafür nicht einfach einen PR gegen develop stellen?

**wvhn** · 20.04.2020, 22:09

Die data points sind genormt. Ein PR für neue genormte data points, die in der dpts.py noch fehlen, macht sicher Sinn. Wenn wir unsere "privaten" data points ins develop schieben, ist das aber irgendwann nicht mehr beherrschbar (bei mir ist es ein altes Hager Tebis TS, das keine genormten Datenpunkte verwendet).
Die lokalen Änderungen immer wieder lokal mit den neuen shNG-Versionen zu mergen, habe ich bisher noch nicht hinbekommen.

Gruß
Wolfram

**thesing** · 21.04.2020, 13:20

Ich würde auch einfach die nicht genormten Datapoints mit aufnehmen. Als Name kann man dann ein Herstellkürzel als Präfix verwenden, dazu noch ein Kommentar, bei welchem Gerät/Hersteller der benutzt wird und gut ist.

Grüße,
Thomas

Ankündigung

RGBW Item Konvertierung in beide Richtungen

RGBW Item Konvertierung in beide Richtungen

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar