device.rtrslider im 1 Byte Modus

[Sipple]

Hi

Ich versuche gerade einen Enertex MeTa Premium Heizungsregler zu programmieren. Regeln tut er, aber die Implementierung in die Visu ist tricky.

Der Taster sendet auf seinen 1-Bit Modus Objekten (Komfort, Nacht, Frost, etc) trotz setzen der Ü Flags KEINEN Status, wenn man am Taster selbst etwas umstellt. Auch beim Senden auf die Bit-Objekte verhält er sich - sagen wir mal - seltsam. 1-Bit Modus scheidet daher wohl aus oder ich bekomme das nur mit aufwändigen Logiken hin.

Im Byte Modus, will er das auf Objekt 11:

0 = Automatisch (was auch immer das heißen soll)
1 = Komfort
2 = Standby
3 = Nacht
4 = Gebäudeschutz

Die Rückmeldung ist nun das Problem. Die kommt über Objekt 17 und es wird folgendes gesendet:

1 = Komfort
2 = Standby
4 = Nacht
8 = Gebäudeschutz
16 = Taupunkt
32 = Heizen
64 = Totzone (Regler inaktiv)
128 = Frostalarm

Und das sollen Werte sein, die aufaddiert werden. Sprich, eigentlich sind das Bits eines Bytes und damit könnte man mehrere Stati melden. Damit kann doch device.rtrslider oder auch das standard rtr widget nichts anfangen? Siehe z.B. Nachtbetrieb - Setzen mit Wert 3, aber Rückmeldung

Hat jemand eine Idee, wie ich das gebacken bekomme, dass ich sowohl über das Widget, als auch auf dem Taster selber die Betriebsart umschalten kann und das korrekt angezeigt wird?

Danke schon mal

Martin

[Bonze]

weöche rückmeldungen erwartest du denn ? eventuell könntest du doch mit ner logik übersetzen?

[Sipple]

Ich erwarte dass er das zurück meldet, was man ihm auch schickt, so wie das alle anderen mir bekannten RTR's machen.
Enertex hat da wohl eigene Vorstellungen. Das ist nun schon das zweite Gerät, das etwas anderes zurück meldet, als man schicken muss (siehe der neue Dimmer im RGBxx Modus).
Wie oben gezeigt, erwartet er zum Moduswechsel nen 8-Bit HVAC Wert, schickt aber als Bestätigung was eigenes zurück. Das ist sch....
Das Visu Widget macht was es soll, aber wenn ich am Taster selber den Modus wechsle, kommt natürlich nix korrektes beim Widget an.

Ich möchte eigentlich verhindern da jetzt wieder ne aufwändige Logik zu bauen, nur weil ein Hersteller mal wieder ein eigenes Süppchen kocht.

Gruß, Martin

P.S. Mit den Flags haben sie's auch nicht so, sonst wär das nämlich kein Thema. BJ, MDT, Gira - alle können das.

[wvhn]

Das Thema hatten wir hier schon einmal diskutiert. Ich bin immer noch der Meinung, dass das Status-Byte innerhalb von shNG gewandelt werden sollte.
Da die Stati immer nur einzeln vorkommen ist eine Logik IMHO ziemlich einfach. Hier meine quick-and-dirty Test-Logik:

#!/usr/bin/env python3
# versuch.py
myitem = sh.test.input()
mynewitem = (myitem & 0x01) + 2* ((myitem >> 1) & 0x01) + 3 *((myitem >> 2) & 0x01) + 4* ((myitem >> 3)& 0x01)  
sh.test.output(mynewitem)​

Alternativ kann man einen speziellen Datenpunkt für das knx-Plugin machen, der die gleiche Wandlung durchführt oder ein einfaches eval, das aus einer 8 eine 4 macht, aus einer 4 eine 3 usw.

In smartVISU ist das ohne ganz neue Widgets nicht zu lösen.

Gruß
Wolfram