Verschiedene DPTs für Lesen und Schreiben

[l0wside]

Meine Somfy 510i (Rolladeninterface) erlauben es, per KO direkt die Rolladenposition zu setzen und auszulesen. Allerdings wird die Position mit einem 1-Byte-KO gesetzt (wohl DPT5), die Positionsrückmeldung erfolgt aber über ein 2-Byte-KO (wohl DPT7). Ich weiß nicht, wer das so erfunden hat, ich muss aber damit leben :-(

Mir fällt keine Möglichkeit ein, das in smarthome.py abzubilden. Eine Logik, die auf dem 2-Byte-KO hört und das 1-Byte-KO sendet, ist nicht machbar, weil ich jede GA nur einmal verwenden kann. Das 1-Byte-KO müsste ich aber zweimal verwenden, einmal lesend, einmal schreibend.
Direktes Setzen des Werts geht auch nicht, denn das würde smarthome.py dann als Befehl auf den Bus geben - was ich ja nicht will.

Hat jemand eine Anregung? Oder soll ich es lieber als Featurewunsch formulieren?

Max

[2ndsky]

Hallo Max,

probier es mal so:

[room]
    [[pos]]
        type = num
        knx_dpt = 5
        knx_send = 1/1/0
        knx_listen = 1/1/0
        eval = sh.room.pos_status()
        eval_trigger = room.pos_status
    [[pos_status]]
        type = num
        knx_dpt = 7
        knx_listen = 1/1/1

Wenn du den Rollo per 1/1/0 auf eine Position schickst, wird pos durch knx_listen auf diesen Wert gesetzt. Wenn dann über 1/1/1 der Status kommt, wird pos zwar gesetzt, da sich der Wert aber nicht geändert haben sollte, dürfte auch nichts gesendet werden.

Einzig wenn du den Rollo per Auf/Ab fährst und ihn dann anhälst kommt der status über 1/1/1 und wird in 1/1/0 gesetzt und damit nochmals gesendet. Da der Rollo aber bereits in der Position ist sollte er sich nicht ändern. Ist jetzt zwar nicht ganz so toll, aber vielleicht wäre es ein erster Workaround für dein Problem.

EDIT: andere Möglichkeit, aber ebenfalls ein Workaraound wäre eine Logik, die auf pos_status Änderungen lauscht und bei Änderungen pos wie folgt setzt sh.room.pos(sh.room.pos_status(), 'KNX'). Damit setzt du den Caller auf 'KNX', du tust quasi so, als ob der Wert vom KNX Plugin gesetzt worden wäre. Daraufhin ignoriert das KNX Plugin die Wertänderung und sendet nichts auf den Bus.

EDIT2: dritte Möglichkeit, du machst ne Logik die auf alle deine DPT7 Statusmeldungen hört und sie in DPT5 übersetzt und wieder sendet. Also eine DPT5 GA für Position Setzen, eine DPT5 GA für Position Rückmeldung und eine DPT7 für Position Rückmeldung je Rollladenkanal. Im Item verwendest du nur die DPT5 GAs.

[l0wside]

Deine Lösung 1 ist echt elegant, danke!

EDIT: andere Möglichkeit, aber ebenfalls ein Workaraound wäre eine Logik, die auf pos_status Änderungen lauscht und bei Änderungen pos wie folgt setzt sh.room.pos(sh.room.pos_status(), 'KNX'). Damit setzt du den Caller auf 'KNX', du tust quasi so, als ob der Wert vom KNX Plugin gesetzt worden wäre. Daraufhin ignoriert das KNX Plugin die Wertänderung und sendet nichts auf den Bus.

Ist auch nicht schlecht, braucht aber Logik - dein erster Ansatz kommt ohne aus, was mir besser zusagt.

EDIT2: dritte Möglichkeit, du machst ne Logik die auf alle deine DPT7 Statusmeldungen hört und sie in DPT5 übersetzt und wieder sendet. Also eine DPT5 GA für Position Setzen, eine DPT5 GA für Position Rückmeldung und eine DPT7 für Position Rückmeldung je Rollladenkanal. Im Item verwendest du nur die DPT5 GAs.

Nein, das geht nicht (die Idee hatte ich schon). Die DPT5-GA müsste ich in zwei Items verwenden, nämlich dem, das den Logiktrigger auslöst und dem, das das eigentliche Rolladen-Item ist. Und eine GA in zwei Items wird von sh.py nicht unterstützt.

Max

[2ndsky]

Verschiedene DPTs für Lesen und Schreiben

Nein, das geht nicht (die Idee hatte ich schon). Die DPT5-GA müsste ich in zwei Items verwenden, nämlich dem, das den Logiktrigger auslöst und dem, das das eigentliche Rolladen-Item ist. Und eine GA in zwei Items wird von sh.py nicht unterstützt.

Da hast du mich falsch verstanden. Wir nehmen an GA1 ist DPT5 und setzt die Position, GA2 gibt den Status als DPT7 zurück, beides verknüpft mit dem Rollladenaktor. Nun gibt es eine GA3, DPT5 und nicht mit dem Aktor verknüpft. Du nimmst eine Logik die auf GA2 lauscht, dafür brauchst du nichtmal ein sh.py Item denn Logiken können auch auf GAs lauschen. Wird ein Wert empfangen sendest du den Wert auf GA3. GA1 und GA3 sind nun bei knx_listen eines Items eingetragen. Somit sollte der Wert auch wieder in das Item wandern (da bin ich mir aber nicht ganz sicher, ob sh.py den Wert vom Bus liest wenn es ihn selber drauf gelegt hat).

Der Logiktrigger wird also von der DPT7 GA ausgelöst und nicht von der DPT5 GA. Des Weiteren, bist du dir sicher, dass eine GA nicht in zwei Items verwendet werden kann (wenn die Datentypen passen)? Ich hab das zwar noch nicht ausprobiert, wüsste aber momentan nicht, was dagegen spricht.