Welche Bits der Hersteller setzt, sagt nicht unbedingt etwas darüber aus, was mit dem Objekt sinnvoll erledigt werden kann. Man kann die Flags auch selbst setzen, für bestimmte "Tricks" ist das auch notwendig. Im Normalfall läuft die Kommunikation aber immer unidirektional, das heißt, ein Kommunikationsobjekt dient entweder zum Senden eines Status oder auch eines Befehls, oder es dient zum Empfangen eines Befehls (oder eines Status)
Deshalb gibt es gewöhnlich immer mindestens zwei Kommunikationsobjekte bei bidirektionaler Kommunikation. Beispiel Solltemperatur: Es gibt ein KO, um die Solltemperatur absolut zu setzen (19,6°C) und eines um die eingestellte Solltemperatur zu melden. Kommt auf dem ersten KO ein Befehl zum Setzen, antwortet der RTR auf dem zweiten KO als Bestätigung mit dem neuen Sollwert. Gewöhnlich gibt es noch ein drittes KO, über das man Schritte nach oben und unten senden kann. Im RTR wird dann die Schrittweite hinterlegt, z.B. 0,1. Jede 1 auf dem Schritt-KO erhöht dann die Solltemperatur um 0.1°C, jede 0 verringert sie. Der RTR antwortet auf beide KO, also sowohl bei Setzen über Absolutwert als auch bei Setzten über "Sollwertverschiebung"
Das gesagte gilt auch für Funktionen wie Nachtabsenkung, Frostschutz usw.
Allerdings gibt es für einen RTR eigentlich eine Gruppe Betriebsarten, welche exklusiv sind. Der RTR kann im Komfortbetrieb sein, er kann sich im Standby befinden, die Nachtabsenkung kann aktiv sein oder der Frostschutz kann aktiv sein. Aber es ist eben immer exakt eine dieser Betriebsarten aktiv, niemals mehrere gleichzeitig. Um die Steuerung über Tasten zu vereinfachen, werden oftmals mehrere dieser Objekte einzeln als Bit angeboten, so dass man gezielt die Nachtabsenkung aktivieren oder deaktivieren kann. Je nach Bedienphilosophie des Herstellers gibt es dabei verschiedene Möglichkeiten, wie sich der RTR verhält. Beispiel Gira: Die Betriebsart wird über einen Wert 1 - 4 gesetzt, intern werden die Werte in Bits umgesetzt, höhere Bits haben auch höhere Priorität. Die Rückmeldung der Betriebsart erfolgt über ein Byte, wobei die unteren vier Bit die vier Betriebsarten sind, also 1, 2, 4 oder 8, wenn man das Byte als Wert 0 - 255 betrachtet. Die oberen vier Bit geben andere Informationen, Bit 5 steht für Kühlen, Bit 6 für Heizen. Wenn der RTR also im reinen Heizbetrieb läuft, meldet er 33, 34, 36 oder 40, entsprechend der Betriebsarten 1,2,3 und 4. gibt es den Kühlbetrieb, so meldet er 17, 18, 20 oder 24 und so weiter...
Es gibt bei Feller zumindest auch ein Rückmeldeobjekt für die Betriebsarten (KO 61), aber leider keine Information darüber, welcher Datentyp verwendet wird. Weitergehende Dokumentation auf der Fellerseite: Fehlanzeige. Vielleicht gibt es noch was auf französisch oder englisch...
Wenn ausschließlich Bit-KO zum Steuern zur Verfügung stehen, gibt es wiederum zwei Möglichkeiten des Verhaltens:
- Letzter Befehl gewinnt. Ich sende Nacht aktiv, also wechselt der RTR auf Nachtbetrieb. Irgendwann sende ich Komfort aktiv, also schaltet der RTR auf Komfort. Sende ich stattdessen Nacht inaktiv, so wechselt der RTR auf die zuvor gewählte Betriebsart. Es ist aber nur genau ein "inaktivieren" möglich, wenn also darüber auf Komfort geschaltet wird, kann ich nicht anschließend Komfort deaktivieren und dadurch auf Frostschutz schalten, weil das die vorletzte Betriebsart war. Stattdessen wird wieder auf Nacht gewechselt (und gewöhnlich wird auch das KO-Bit entsprechend gesetzt)
- Es gibt eine Hierarchie. Wurde Komfort aktiviert, kann man so oft Nacht aktivieren, wie man will, man muss zunächst Komfort deaktivieren, damit der RTR auf Nacht wechseln kann. Entsprechendes gilt sinngemäß für alle anderen Modusumschaltungen.
Wie die Priorisierung im 2. Fall definiert ist, muss man allerdings aus der (wie erwähnt nicht aufzufindenden) Doku ermitteln. Natürlich kannst Du das mehr oder weniger mühsam durch Ausprobieren selbst ermitteln, schöner wäre aber, dass Feller diese Informationen mit den Kunden teilt.
Für openHAB ist es aber unerlässlich, dass Du die Rückmeldung der Betriebsart über das KO 61 ermittelst. Ich gehe erst mal vom DPT 20.102 (HVAC Modus) aus, da stehen die Werte für: 0->Auto (oder vielmehr unbekannt, aber was soll's) 1->Komfort, 2->Standby, 3->Eco, 4->Frostschutz. Wobei hier noch zu erraten wäre, ob nun Standby der Nachtbetrieb ist oder doch ECO...
Es könnte aber z.B. auch DPT 201.100 sein, das macht es etwas schierig (auch wenn die unteren drei Bit identisch codiert sind...)
Du solltest auf jeden Fall versuchen, in openHAB möglichst nur ein Item zur Stuerung zu verwenden. Im Hintergrund musst Du Steuerbefehle dann mittels Rule auf die vier Bits verteilen, weil Feller leider kein gemeinsames Steuerobjekt bietet. Eine mögliche Variante:
Code: Alles auswählen
Type switch : Mode1 "Komfort" [ga="..."]
Type switch : Mode2 "Nacht" [ga="..."]
Type switch : Mode3 "Standby" [ga="..."]
Type switch : Mode4 "Frostschutz [ga="..."]
Type number : Modus "Rückmeldung" [ga="..."]
Nun hast Du fünf Channel, die wir auf die Items Raum_RTR_Modus, Raum_RTR_Mode1, Raum_RTR_Mode2 usw. abbilden.
Alle Items vom Typ RTR_Modus kommen in eine Gruppe gRTR_Modus. Alle Items vom Typ RTR_Mode# (#=1-4) kommen in die Gruppe gRTR_Mode.
Eine Rule:
Code: Alles auswählen
rule "Modus an RTR senden"
when
Member of gRTR_Modus received command
then
val strRaum = triggeringItem.name.split("_").get(0)
val strModus = receivedCommand.toString
val sItem = gRTR_Mode.members.filter[i|i.name.startsWith(strRaum) && i.name.endsWith(strModus)].head
sItem.sendCommand(ON)
end
Solange Du die Namenskonvention einhältst, reicht diese eine Rule, um beliebig viele RTR dieses Typs zu steuern. Die Rule ermittelt, welcher Raum betroffen ist und sucht das passende Item zum Setzen der gewünschten Betriebsart heraus.
Sollte es eine Priorisierung der Betriebsarten geben, so müssen die beiden letzten Zeilen angepasst werden:
Code: Alles auswählen
rule "Modus an RTR senden"
when
Member of gRTR_Modus received command
then
val strRaum = triggeringItem.name.split("_").get(0)
val strModus = receivedCommand.toString
gRTR_Mode.members.filter[i|i.name.startsWith(strRaum)].forEach[m|
if(!(m.name.endsWith(strModus)))
m.sendCommand(OFF)
else
m.sendCommand(ON)
]
end
Jetzt werden halt immer vier Befehle abgesetzt und gezielt alle Modi deaktiviert, bis auf den, der aktiviert werden soll, der wird halt aktiviert.
Es kann natürlich noch sein, dass der zu aktivierende Modus als letztes gesendet werden muss
dann muss man mit zwei Stufen arbeiten, in der ersten deaktiviert man alle Betriebsarten, welche nicht gewünscht sind, im zweiten Schritt schaltet man die eine gezielt ein - das wäre dann eine Kombination aus Variante zwei und eins, wobei der Part mit dem ON aus Part zwei entfällt, also die das else und das folgende sendCommand(ON) und dafür eben das eine Element anschließend einzeln aus der Gruppe gefiltert wird, um es zu setzen.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
