OpenHAB mit - BUSCH-JAEGER Triton RTR

[H0lger]

Hallo zusammen,

ich stelle immer wieder fest, dass ich mit meinen rudimentären Wissen zu openHAB und KNX schnell an meine Grenzen stoße.

Mit dem KNX-Binding kann ich das Licht an/aus schalten und die Rollläden hoch/runter fahren lassen.
Was ich nun gerne auch noch hinbekommen würde: Das Steuern der Raumtemperaturregler meiner Triton Bedienelemente. Ich schaffe es, die IST-Temperatur auszulesen - an die Soll-Temperatur komme ich aber nicht dran.

Meine Konfig sieht so aus:

knx.things (verkürzt):

Bridge knx:ip:bridge [  
    type="TUNNEL",
    ipAddress="192.168.2.250"
] {
    Thing device Hager_RTR_6  "Triton RTR Schlafzimmer" [
        address="1.1.36",
        readInterval=3600
    ] {
        Type number : KNX_Temperatur_IST_Schlafzimmer  "KNX_Temperatur_Schlafzimmer"  [ga="0/4/23"]
    }
​}
​

knx.items

Number:Temperature  KNX_Temperatur_IST_Schlafzimmer "Temperatur Schlafzimmer IST [%.1f °C]" <temperature>    { channel="knx:device:bridge:Hager_RTR_6:KNX_Temperatur_IST_Schlafzimmer" }
​

Weil ich an die IST-Temperatur über eine GA ("0/4/23") komme, war das recht einfach. Der Soll-Wert scheint aber keine GA zu haben. Daher weiß ich nun nicht, wie ich in der knx.things Datei das Thing Hager_RTR_6 mit einem oder mehrere Kanäle erweitern muss, damit ich auch die Soll-Temperatur in ein Item von openHAB bekomme (und wie ich die Soll-Temperatur dann auch verändert bekomme). Außerdem wäre es natürlich auch schön, wenn ich zwischen Komfort und Standby umschalten könnte.

Ich bin bei der Bedienung der ETS ein absoluter Laie. Bitte setzt nicht voraus, dass ich das alles verstehe, wie das in der ETS funktioniert. Mein Elektriker hat das (vor fast 20 Jahren) eingerichtet und ich habe mich mit der Bedienung der ETS nie wirklich beschäftigt. Ich bewohne also seit fast 20 Jahren ein KNX-Haus - ich benutze es aber nur - ohne selbst in der ETS etwas zu machen. Am KNX-System möchte ich auch nicht wirklich etwas verändern (zumindest zur Zeit nicht). Im Moment geht es mir darum, dass ich mir mit openHAB eine Visualisierung bauen kann.

Wie der Busch-Jaeger 6327 5-fach Triton-Taster mit RTR bei mir in der ETS aussieht, hänge ich hier als Grafik ein (würde das auch anders gehen?):

triton.jpg

Wäre klasse, wenn mir jemand sagen könnte, wie ich die knx.things und knx.items nun für die Sollwert-Steuerung ergänzen muss. Da ich alles über die Basic UI mache, hätte ich auch Interesse an einem Beispiel einer .sitemap Datei, aus der ich ggf. Dinge übernehmen könnte.

Ich vermute, dass ich mir noch Werte aus der ETS rausziehen muss. Aber welche? Und wo finde ich diese?

Hoffe sehr, dass ich mit eurer Hilfe mein Problem gelöst bekomme.

Viele Grüße
Holger

[udo1toni]

Die Kommunikation auf dem knx Bus läuft (im Regelbetrieb) ausschließlich über GA (Gruppenadressen.)
Soll ein KO (Kommunikationsobjekt) mit dem Bus kommunizieren, so muss es zwingend eine GA zugewiesen bekommen.
Alle KO am knx Bus, die miteinander verbunden werden sollen, bekommen die gleiche GA zugewiesen.
Aber Achtung! Es gibt dabei noch einige weitere Regeln, über die Flags eines KO kann man z.B. beeinflussen, ob ein KO kommuniziert und wie es kommuniziert. Außerdem sind KO gewöhnlich gerichtet und nicht jedes KO unterstützt bidirektionale Kommunikation. Außerdem ist es auch nicht bei jedem KO sinnvoll. Um auf die Solltemperatur zuzugreifen, musst Du also eine GA eintragen, sinnvollerweise eine, die bisher nicht genutzt wird
Welche GA Du verwendest, ist "egal", eine GA ist lediglich ein 16-Bit-Wert, es gibt keine Festlegung, welche Nummernkreise für welche Funktion genutzt werden. Du kannst versuchen, die GA in das bestehende GA-System einzubinden, oder Du legst die GA bewusst außerhalb des Systems an, so dass der Elektriker direkt erkennen kann, dass diese GA nicht von ihm stammen (falls mal von einem Fachmann was gemacht werden soll).
Es gibt noch eine Besonderheit zu erwähnen, denn vielleicht möchtest Du die Solltemperatur auch verstellen, das geschieht dann gewöhnlich über den Basis Sollwert (KO 5).
Der Basis Sollwert gibt die Solltemperatur für den Komfortbetrieb an. Je nach Parametrierung bewirk die Nachtabsenkung dann eine Reduzierung der Solltemperatur z.B. um 2 K, Standby 4 K und Frostschutz 14 K. Gleichzeitig wird auch das Regelfenster vergrößert, eine Klimaanlage wird also ebenfalls erst später auf Kühlung schalten.
In openHAB muss man höllisch aufpassen, denn Solltemperatur setzen und Solltemperatur holen sind zwei unterschiedliche Dinge. Wenn ich auf NAchtabsenkung schalte, liefert KO 7 nämlich auf einen Schlag z.B. nicht mehr 21 °C sondern 19 °C. Wenn ich aber den Sollwert auf 19 ° C einstelle, werden daraus 17 °C, denn dei Nachtabsenkung zieht ja immer 2 K ab. Die beiden Werte sind also nicht identisch, vielmehr hängt KO 7 von KO 5 und den KO 0 - KO 2 ab.
Die genaue Abhängigkeit findest Du in der technischen Dokumentation zum Triton RTR erklärt.

Auf openHAB-Seite legst Du am besten zwei Channel an, den einen für Soll-Ist und den anderen für Soll-Basis, wenn Du nur ein Widget haben willst, welches jederzeit korrekt die echte Soll Temperatur anzeigt und setzt, brauchst Du eine Rule, welche die fünf Größen miteinander verrechnet.

[H0lger]

Hi!
Danke für die schnelle Antwort. Ok, ich muss also schauen, wie ich in der ETS dem Basis Sollwert (und dem aktuellen Sollwert) eine Gruppenadresse zugewiesen bekomme. Nur dann bekomme ich die Werte zu openHAB.

Für meine "weiteren Gehversuche" versuche ich mich gerade in der Standby/Komfort-Schaltung des Triton. Schließlich ist für den Komfort-Betrieb bereits eine GA zugewiesen.
Die knx.thing habe ich um diese Zeile erweitert:

  Type switch : KNX_Schlafzimmer_Standby_Komfort   "Schlafzimmer Standby oder Komfort"  [ga="0/4/10"]
​

und die knx.items:

Switch  KNX_Schlafzimmer_Standby_Komfort "Schlafzimmer Standby/Komfort"  <temperature>  { channel="knx:device:bridge:Hager_RTR_6:KNX_Schlafzimmer_Standby_Komfort" }
​

Gut: Ich kann über openHAB den Triton damit steuern. Ok.

Was ich nun aber nicht verstehe: Das Switch-Item springt nach ein paar Sekunden immer wieder auf OFF/Standbay - ohne dass dies eine Wirkung auf den KNX-Bus hat. Ich kann das in der Diagnose der ETS nachvollziehen: Wenn ich in openHAB den Switch betätige (egal ob von ON auf OFF oder von OFF auf ON), wird über das IP-Gateway ein Telegramm in den KNX-Bus gesendet. Das "geisterhafter Zurückspringen" des Switches auf OFF findet offentlichlich nur in openHAB statt. Der KNX-Bus bekommt davon nichts mit. Das ist aber natürlich doof: Der Status des openHAB-Items spiegelt dann nicht (mehr) den Status des Triton-Raumtemparaturreglers wider.

Wo liegt mein Fehler? Darf ich kein Switch-Item für die GA der Standby/Komfort-Schaltung nehmen?

Viele Grüße
Holger

[udo1toni]

Gibt es im Log irgendwelche Zeilen dazu?

Grundsätzlich möchte ich empfehlen, IDs und Namen möglichst kurz zu gestalten. Der RTR ist fix einem Raum zugeordnet, es wäre also sinnvoll, diesen Namen in der ID des Things einzubauen:

Thing device hagerRTRschlafen "RTR Schlafzimmer"

Und dafür in der Channel ID darauf zu verzichten:

Type number : tempIst "Temperatur Ist" [...]
Type switch : modeComfort "Comfort" [...]
Type switch : modeNight   "Nachtabsenkung" [...]
Type switch : modeAntiFreeze "Frostschutz" [...]

womit sich dann wesentlich kürzere UIDs ergeben:

Switch Schlafzimmer_RTR_Komfort     "RTR Komfort"        <temperature> { channel="knx:device:bridge:hagerRTRschlafen:modeComfort" }
Switch Schlafzimmer_RTR_Nacht       "RTR Nachtabsenkung" <temperature> { channel="knx:device:bridge:hagerRTRschlafen:modeNight" }
Switch Schlafzimmer_RTR_Frostschutz "RTR Frostschutz"    <temperature> { channel="knx:device:bridge:hagerRTRschlafen:modeAntiFreeze" }

KNX ist auf Itemseite sinnfrei, es geht bei openHAB ja gerade darum, die Abhängigkeit von der Hardware zu eliminieren. Alle Stuerfunktionen sollten also möglichst ohne Bezug auf die Hardware definiert werden, oder anders ausgedrückt: Stell Dir vor, Du möchtest den knx RTR durch einen Zigbee RTR ersetzen (wird man nicht machen, klar, aber nur als Beispiel), dann müsstest Du - gegeben, dass die Steuerung ansonsten identisch ist - bei allen Items das KNX durch Zigbee ersetzen, ohne dass Du dadurch irgendwas gewinnst. Die Channel UIDs sind hierarchisch aufgebaut. der Begriff knx ist automatisch in jeder UID enthalten, warum also ein zweites Mal verwenden? Wenn Du das raumbezogene Thing auch raumbezogen benennst, ist auch dieser Teil bereits enthalten.

Die Frage ist auch, wie die drei Bits gemeinsam betrachtet werden. Wechseln die "älteren" Bits auf 0, wenn eine andere Betriebsart gesetzt wird? Obdr bleiben die Bits erhalten, so dass die Steuerung damit dann signalisiert, welche Betriebsart aktiv sein wird, wenn die gerade priorisierte Betriebsart (und welche Reihenfolge haben die Bits - Frostschutz-Nacht-Komfort oder Nacht-Frostschutz-Komfort?) wieder abgeschaltet wird?

Grundsätzlich sollte Switch schon korrekt sein, das Verhalten ist mindestens ungewöhnlich. Ob es sich hier um einen Fehler in openHAB oder in der Kommunikation mit dem knx Bus handelt, müsste man über ein erweitertes Log herausfinden (mindestens DEBUG für das knx Addons, evtl. auch TRACE, lässt sich in der MAIN UI - Administration pro Addon einstellen).

[H0lger]

Ich weiß, dass echte Programmierer mit der Anzahl von Zeichen gerne sparsam umgehen. Ich finde aber, dass lange und sprechende Namen die Lesbarkeit deutlich verbessern - und auch wenn das von mir in den Items vorgestellte 'KNX' sinnbefreit ist: Es hilft mir z.B. beim Filtern - wenn ich einen bestimmten Wert suche.
Aber wie auch immer: Ich habe Deinen Rat befolgt und habe die IDs und Namen gekürzt (wobei ich Deinen Hinweis 'Und dafür in der Channel ID darauf zu verzichten' nicht verstanden habe. Wo (und weshalb) kann ich auf die Channel ID verzichten?)

Auf die Idee mal im event.log nachzuschauen, hätte ich natürlich auch einmal selber kommen können...
Dort kann ich das "geisterhafte" Zurückspringen des Switches tatsächlich nachvollziehen. Im Log steht (ich habe 2x den Schalter auf "ON" gestellt):

2024-02-11 22:00:27.697 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KuecheKomfort' received command ON
2024-02-11 22:00:27.699 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'KuecheKomfort' predicted to become NULL
2024-02-11 22:01:01.272 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KuecheKomfort' received command ON
2024-02-11 22:01:01.274 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'KuecheKomfort' predicted to become NULL
​

Anders als von mir bisher vermutet, geht das Item also nicht in den Status "OFF". Das erklärt, wieso kein Telegramm zum KNX-Bus gesendet wird (was beim "command ON" getan wurde) - und der RTR im Komfortmodus bleibt - obwohl der Schalter dann nicht mehr auf "ON" steht. Hast Du eine Idee, was die Statusänderung auf NULL auslösen könnte? Werde mal schauen, wie ich den Log-Level verändern kann.

[udo1toni]

NULL ist ja kompletter Schwachsinn... Keine Ahnung, wie das passieren kann. Aber Du kannst das Problem loswerden, indem Du autoupdate="false" ergänzt.
Ich gebe ja immer die Itemdefinition über Items Dateien an, da sähe das so aus:

Switch Schlafzimmer_RTR_Komfort "RTR Komfort" <temperature> { channel="knx:device:bridge:hagerRTRschlafen:modeComfort", autoupdate="false" }
​

Natürlich kann man das auch in der UI über die Metadaten hinzufügen.

(wobei ich Deinen Hinweis 'Und dafür in der Channel ID darauf zu verzichten' nicht verstanden habe. Wo (und weshalb) kann ich auf die Channel ID verzichten?)

Na, Wenn die Thing ID schon einen Hinweis auf den Raum enthält, muss dieser nicht nochmal im Channel verwendet werden.
Statt

channel="knx:device:bridge:Hager_RTR_6:KNX_Schlafzimmer_Standby_Komfort"

"knx:device:bridge:hagerRTRschlafen:modeComfort"

Ich behaupte, dass der Informationsgehalt nahezu identisch ist (und auch der zweite Ausdruck wird zuverlässig von der Suche gefunden).

[H0lger]

Danke!
Ich habe das autoupdate="false" eintragen. Das war die Lösung - jetzt funktioniert es.

Das letzte "predicted to become NULL" hat heute Nacht stattgefunden:

2024-02-12 03:43:14.718 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'KuecheKomfort' changed from NULL to ON

D.h. während ich geschlafen habe, hat sich der Switch auf den Status geändert, welcher der Triton-RTR tatsächlich hat(te).

Mit dem autoupdate="false" geht das Item nun nicht mehr auf NULL. Ich bin begeistert. Nochmals vielen Dank!

[udo1toni]

Immer gerne.

Natürlich fuchst es mich etwas, nicht zu wissen, wie openHAB auf die Schanpsidee kommt, dass ein Befehl ON zu einem Status NULL führen sollte - es handelt sich ja um eine Voraussage (predicted) und openHAB generiert dann schon mal ein passendes postUpdate, damit der Anwender die Rückmeldung so schnell wie möglich bekommt.
Das ist an sich eine gute Sache, aber doch bitte mit korrekten Annahmen...

[H0lger]

Zu früh gefreut. :-(

Das Problem des "geisterhaft zurückspringenden Switches besteht immer noch - dies obwohl jetzt tatsächlich kein "predicted to become NULL" mehr im Log erscheint.

Was mir aber jetzt (erst) aufgefallen ist: Die beiden RTRs werden in openHAB als "Offline" angezeigt: tritonOffline.jpg

Sie sind aber nicht wirklich offline.
Das Item für die Ist-Temperatur aktualisiert sich regelmäßig und ich kann auch zwischen Standby und Komfort hin-und-herschalten. Ich sehe sowohl im Log von openHAB die (erwarteten) Aktualisierungen - sowie die Telegramme im KNX-Bus beim Betätigen des Komfort-Switches.

    Thing device RTRSchlafzimmmer  "Triton RTR Schlafzimmer" [
        address="1.1.36",
        readInterval=3600
    ] {
        Type number : TempSchlafzimmer         "KNX_Temperatur_Schlafzimmer"           [ga="0/4/23"]
        Type switch : Schlafzimmer_Komfort     "Schlafzimmer Standby oder Komfort"     [ga="0/4/10"]
    }
​

Was ich für keinen Zufall halte: Das sind genau die beiden RTRs, bei denen ich derzeit eine Komfort/Standby-Steuerung über openHAB versuche. Alle anderen Triton-RTRs sind weiterhin "Online". Und ich bin mir recht sicher, dass die RTRs für Küche und Schlafzimmer auch "Online" angezeigt wurden, als ich die RTRs in der knx.things erstmalig in openHAB eingebunden habe. Die IST-Temperatur bekomme ich von allen RTRs ausgelesen - das hat keinen Einfluss auf den Online/Offline-Status. Die beiden RTRs, bei denen ich über den Switch die Komfort/Standby Einstellung des RTRs zu ändern versuche, haben sich nun aber irgendwie "verschluckt". Weder ein Neustart von openHAB, noch ein Abziehen und Neuaufstecken des RTRs auf den Busankoppler haben einen Einfluss. Die beiden Things werden weiterhin als "offline" angezeigt.

Das wäre natürlich eine Erklärung für das ungewöhnliche Verhalten des Switches. Wenn das Thing (angeblich) Offline ist, verhält sich das Item irrational (und stellt sich mit autoupdate von NULL). Die Frage ich nun allerdings, wie ich die beiden RTRs in openHAB wieder online bekomme. Die Konfig unterscheidet sich nicht von allen anderen RTRs, die online sind - und die beiden RTRs für Küche und Schlafzimmer waren ja auch mit dieser Konfig bereits online.

Was kann ich tun, damit die beiden RTRs, die sich "verschluckt" haben, wieder als online angezeigt werden? Ich könnte mal den gesamten KNX-Bus kurz stromlos schalten. Aber selbst wenn die beiden Things dann wieder online werden sollten: Das kann m.E. ja nicht die Lösung sein. Weil ich in der ETS ja nichts gemacht habe, würde ich erwarten, dass die RTRs wieder auf Offline gehen, wenn ich über openHAB die GA anspreche.

[udo1toni]

Du kannst einfach den address Parameter leeren (also entfernen). Hilft das nicht unmittelbar, dann bitte einmal die ID des Things ÄNDERN (z.B. eine 1 hinten dran schreiben), speichern und nach kurzem Warten wieder auf die ursprüngliche ID zurück wechseln.
Hintergrund: Manchmal funktioniert die Übernahme von Änderungen an Things nicht sauber im laufenden Betrieb. Eine Änderung der ID in einer things-Datei ist aber in Wirklichkeit wie das Löschen des ursprünglichen Eintrags und eine neue Konfiguration eines völlig neuen Things (welches lediglich die selben Einstellungen hat...)
Danach muss das Thing Online angezeigt werden.

[H0lger]

negativ.
Weder das temporäre Ändern/Entfernen des address Parameter, noch das Ändern der ID (noch ein Neustart von openHAB) hat einen Einfluss auf den Status des Things.
Die "Problem RTRs" werden weiterhin als Offline angezeigt.
Merkwürdig ist allerdings: Um zu Testen ob das Fehlerbild reproduzierbar ist, habe ich nun einen Komfort/Standby-Switch bei einem dritten RTR (Kind1) konfiguriert. Der Effekt des "geiterhaften Zurückspringens" gibt es auch beim nächsten RTR. Aber: Das Thing dieses dritten RTR wird weiterhin als Online angezeigt.

Irgendwie bin ich lost.
Ich habe die ITEMs für die Standby/Komfort-Switche in eine Gruppe gesetzt und diese Regel erzeugt:

rule "RTR Schalter wurden geändert"
when
    Member of gStandbyKomfort received command
then
    logInfo( ruleId, "RTR wurde in openHAB geändert => {}", triggeringItem.name + "  neuer Status: " + triggeringItem.state.toString )
end
​

Das, was ich im Log angezeigt bekomme, stimmt aber nicht mit dem überein, wie ich den Switch schalte.
Schalte ich den Schalter auf EIN, sehe ich im event.log "Item 'Kind1Komfort' received command ON' im openhab.log steht aber: "RTR wurde in openHAB geändert => Kind1Komfort neuer Status: OFF"

Das ist für mich alles irgendwie unlogisch. Gibt es hier einen zeitlichen Verzug zu beachten? Das Item ist auch nach Schreiben dieses Textes im Status "OFF" - obwohl es den "received command ON" gegeben hat.

[udo1toni]

negativ

.
Das kann eigentlich nicht sein, es spricht an dieser Stelle einiges dafür, dass irgendwas in Deiner Konfiguration durcheinander geraten ist. Mein Empfehlung wäre also, die betreffenden Things komplett zu entfernen und neu zu erstellen, am besten mit einer anderen ID.

Weder das temporäre Ändern/Entfernen des address Parameter,

Oh. Nein, nicht temporär, lass ihn komplett weg, nicht neu setzen. KEINESFALLS ändern, die eingetragenen Daten müssen zwingend exakt zu dem angelegten Device gehören (oder man lässt sie halt weg... für die Funktion des Addons spielt das keine Rolle).

Ich habe die ITEMs für die Standby/Komfort-Switche in eine Gruppe gesetzt und diese Regel erzeugt:

rule "RTR Schalter wurden geändert"
when
    Member of gStandbyKomfort received command
then
    logInfo( ruleId, "RTR wurde in openHAB geändert => {}", triggeringItem.name + " neuer Status: " + triggeringItem.state.toString )
end​

Achtung! logInfo() erwartet exakt zwei Strings, wobei der erste String der letzte Teil des Loggernamens ist, der zweite String ist die auszugebende Meldung. Im zweiten String ist Substituierung möglich, wobei openHAB automatisch passend substituiert, soweit das möglich ist. Und noch wichtiger: Der Status eines Items ist etwas völlig anderes als ein Befehl. Beide müssen nicht zwingend etwas miteinander zu tun haben.

Korrekt also eher so:

rule "RTR Schalter wurden geändert"
when
    Member of gStandbyKomfort received command
then
    logInfo( "rtr", "RTR {} hat Befehl empfangen: {}", triggeringItem.name, receivedCommand)
end​

Du hast stattdessen auf den Status des Items zugegriffen, welches den Befehl empfangen hat. Da openHAB asynchron arbeitet, ist es höchst wahrscheinlich, dass die Rule sehr viel eher ausgeführt wird, als der aus dem Befehl resultierende Statuswechsel. Wenn überhaupt, dann müsstest Du ein bisschen warten, bis Du den Status überprüfst, also z.B. so:

rule "RTR Schalter wurden geändert"
when
    Member of gStandbyKomfort received command
then
    Thread.sleep(1500)
    logInfo( "rtr", "RTR {} hat Befehl empfangen: {}, Status nach 1,5 Sekunden ist {}", triggeringItem.name, receivedCommand, trigeringItem.state)
end​

[H0lger]

Hallo Udo,

danke für Deine Erläuterungen. Mir war nicht bewusst, dass openHAB asynchron arbeitet - jetzt ist mir klar, woher die "Differenzen" zwischen log-Ausgaben mit logInfo und dem tatsächlichen Status kommen. Wieder etwas dazugelernt...

Jetzt ist Wochenende und ich habe wieder etwas Zeit mich um meine Installation zu kümmern. So wie es sich mir darstellt, kämpfe ich mit zwei Fehlerbildern, die unabhängig voneinander sind:

1) Das "geisterhafte" Zurückspringen der Standby/Komfort-Switche
Der Triton-Schalter und das Item stehen am Anfang meiner "Testreihe" beide auf Komfort bzw. auf ON. Wenn ich nun in openHAB den Switch auf OFF schalte, geht der RTR korrekt auf Standby. Das passt. Nur dann passiert etwas Überraschendes: Der Switch schaltet unmittelbar danach wieder auf ON (ohne das der RTR das mitbekommt). Wenn ich dann (wiederholt) erneut auf OFF schalte, sehe ich im events.log (bei vier Wiederholungen):

2024-02-17 10:54:17.240 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KuecheKomfort' received command OFF
2024-02-17 10:54:31.911 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KuecheKomfort' received command OFF
2024-02-17 10:55:03.970 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KuecheKomfort' received command OFF
2024-02-17 10:55:33.529 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KuecheKomfort' received command OFF
2024-02-17 10:56:04.204 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KuecheKomfort' received command OFF
​​

In openab.log sieht man das die (von Dir korrigierte) Rule korrekt durch das von mir 5x getätigte Umschalten getriggert worden ist:

2024-02-17 10:54:17.241 [INFO ] [org.openhab.core.model.script.knx   ] - RTR KuecheKomfort hat von openHAB Befehl empfangen: OFF
2024-02-17 10:54:31.913 [INFO ] [org.openhab.core.model.script.knx   ] - RTR KuecheKomfort hat von openHAB Befehl empfangen: OFF
2024-02-17 10:55:03.971 [INFO ] [org.openhab.core.model.script.knx   ] - RTR KuecheKomfort hat von openHAB Befehl empfangen: OFF
2024-02-17 10:55:33.532 [INFO ] [org.openhab.core.model.script.knx   ] - RTR KuecheKomfort hat von openHAB Befehl empfangen: OFF
2024-02-17 10:56:04.206 [INFO ] [org.openhab.core.model.script.knx   ] - RTR KuecheKomfort hat von openHAB Befehl empfangen: OFF
​​​

Das Merkwürdige ist aber: Der Status des Items geht immer wieder sofort in ON:
basic.jpg

In den Logs sieht man aber: Das Item wieder immer nur auf OFF geschaltet. Ein ON-Befehl hat es nie gegeben.
Wie kann es sein, dass der Status des Items sich auf ON ändert - ohne dass davon etwas im events.log steht und ohne dass die Rule getriggert wird? Was konsequent ist: Auch auf den KNX-Bus wird kein ON-Befehl gesendet. Der RTR wurde mit dem erstmaligen Ändern des Switches korrekt auf Standby geschaltet (weil über die IP-Schnittstelle ein Telegramm gesendet wird - das kann ich in der ETS sehen). Der RTR bleibt dann solange auf Standby, bis ich den Switch auf OFF- und dann sofort selbst (also ohne Geisterhand) wieder auf ON stelle. Das "echte" von mir getätigte Umschalten schaltet den RTR korrekt um.

2. Das oben beschriebene Fehlerbild habe ich sowohl an den RTRs, die mir in openHAB als "ONLINE" angezeigt werden - als auch an den drei RTRs, bei denen das Thing als 'OFFLINE' angezeigt wird. Ich schaffe es nicht die drei OFFLINE-RTRs wieder als ONLINE angezeigt zu bekommen. Ich habe den Busankoppler stromlos geschaltet, der KNX-Bridge einen neuen Namen gegeben und auch die ID der Things geändert. Nichts von dem bewirkt eine Veränderung. Das scheint mir aber ein reines "Anzeigenproblem" zu sein. Auch bei den drei OFFLINE-RTRs kann ich (wie unter 1. beschrieben) den RTR über openHAB steuern.

Der Fehler 2) stört mich eigentlich nicht weiter. Es ist m.E. nur Optik. Der Fehler 1) hat aber zur Folge, dass der Status des Items nicht mit dem Status des RTRs übereinstimmt.

Ohne das autoupdate="false" beim Item sieht man in der events.log beim gesterhaften Zurückspringen das "predicted to become NULL".

Irgendwie fällt es mir schwer zu glauben, dass dies an meiner Konfiguration liegt (von der Du, Udo, annimmst, dass sie "durcheinander" ist). Falls das aber kein Fehler vom KNX-Binding (oder des Triton RTRs) sein sollte: Wie könnte/sollte ich meine Konfig ändern?

Viele Grüße
Holger

[udo1toni]

Einen grundsätzlichen Fehler kann man so gut wie sicher ausschließen, das knx Addon steht seit vielen Jahren zur Verfügung und wird von tausenden Anwendern genutzt, so auch von mir. Ich habe auch diverse switch Channel, welche alle einwandfrei funktionieren. Ich nutze openHAB seit Version 1.0 und habe quasi alle anderen Versionen mit genutzt (wobei ich openHAB2 erst sehr spät produktiv eingesetzt habe, nachdem das knx Binding auf V2 umgestellt war - OH2.3? - auch die Umstellung auf produktiv OH3 habe ich erst spät vollzogen, im Testbetrieb lief es aber die ganze Zeit mit...)

ONLINE/OFFLINE: Wie gesagt, nimm den address Parameter komplett raus, das bringt keine Nachteile, aber das generic knx Thing muss dann dauerhaft online angezeigt werden, weil die Ermittlung des Zustands nur aufgrund der physikalischen Adresse erfolgt.
Da fällt mir gerade ein: Hast Du evtl. mehrere knx Linien oder gar Bereiche? Es könnte sein, dass im knx Bus Telegramme gefiltert werden, damit könnten solche Effekte auftreten.

Status springt zurück: Bis Du sicher, dass da nicht irgendwo anders noch was konfiguriert ist, was diese Items beeinflusst? Was passiert, wenn Du in der Rule, welche das OFF sendet, zusätzlich noch ein postUpdate(OFF) einbaust? Eventuell besteht das Problem auch darin, dass der Triton seinen Status niemals zurückmeldet.

Ich kenne den Triton nicht, ich nutze hier Gira TS 2 plus als RTR, die habe ich so konfiguriert, dass ich zwei KO habe, die jeweils ein Byte senden bzw. empfangen. Das eine KO erwartet eine Zahl 1 - 4 für die vier verschiedenen Modi (Komfort, Nacht, Standby, Frostschutz), das andere KO meldet die Betriebszustände über die Bits 0-7 (wobei hier je ein Bit für Komfort, Nacht, Standby, Frostschutz, Heizen/Kühlen, Reglersperrung, Inaktivität und Frostalarm steht)
Daraus ergibt sich, dass ich für die Rückmeldung eine Rule benötige, welche die Bits auf den jeweiligen Wert mappt, damit das Steueritem auch umschaltet, wenn ich am RTR lokal die Betriebsart ändere.
Der Punkt ist aber: ich habe zwei Channel (für die beiden Richtungen) über die die Umschaltung komplett erfolgt, samt aktiver Rückmeldung. Das funktioniert hier seit fast zwölf Jahren einwandfrei (so lange nutze ich openHAB schon...)

[H0lger]

Hallo Udo,
ich denke, das war es: Der Triton meldet seinen Status niemals zurück.
Ist meine Annahme korrekt, demnach die Kommunikation im KNX-Bus bidirektional ist? Der Adressat des Telegramms meldet dem Absender also den erfolgreichen Empfang zurück? Wenn der Triton das nicht macht, erlärt dies, wieso openHAB die gewünschte Statusänderung wieder rückgängig macht. Ohne Bestätigung gab es für openHAB keine Statusänderung.

Mit der Rule:

rule "RTR Standby_Komfort-Schalter wurde von openHAB geändert"
when
    Member of gStandbyKomfort received command
then
    logInfo("knx", "RTR {} hat von openHAB Befehl empfangen: {}", triggeringItem.name, receivedCommand)
    triggeringItem.postUpdate(receivedCommand)
end​

gibt es nun kein Zurückspringen mehr.
Ich bin begeistert! Danke!

Dann werde ich mich jetzt darum kümmern, dass ich an die RTR-Sollwerte komme (und sie verändert bekomme).
Weil ich bisher Angst hatte meine Konfiguration im Haus zu zerschießen, habe ich die ETS bisher nur als "read only" verwendet. Wirklich gemacht habe ich in der ETS nie etwas. Damit - wie Du vor ein paar Tagen beschrieben hast - dem Basis Sollwert und aktueller Sollwert je eine GA zugewiesen wird, habe ich nun gerade erstmalig ein KNX-Gerät programmiert.

BadEG.jpg
Sieht (zumindest für mich) erst einmal gut aus: Dem Basis Sollwert ist nun die GA 0/4/50 zugewiesen (zuvor war dem nicht so - es gab keine GA).
Mir scheint aber, dass ich noch mehr tun muss.
Lege ich in openhab einen zusätlichen Channel im Thing an, sowie ein Item (so, wie ich es für die IST-Temperatur gemacht habe), kommt in openHAB nichts an. Wenn ich die Soll-Temperatur am RTR ändere: Das neu angelegte Item behält den Status NULL.
Wahrscheinlich war das etwas naiv von mir - zu glauben, dass das schon alles hätte sein können...
Was muss ich denn noch machen, damit ich den im RTR eingestellten Basis Sollwert in openHAB ausgelesen bekomme?