Ankündigung

**udo1toni** · 13.09.2019, 18:41

Warum so kompliziert? Du brauchst Doch gar keine einzelnen Schalter für die einzelnen Betriebsarten.

Aber zunächst einmal scheint mir Dein Channel schon nicht so ganz korrekt zu sein, der Status kommt exakt von einer GA, niemals von mehreren GA. Entsprechend ist es auch nicht sinnvoll, beim Start von openHAB auf mehreren GA einen Read Request zu schicken (das ist das < vor der GA).

Ich kenne Deinen RTR nicht, bei mir (Gira) ist es so, dass ich den Steuerbefehl als Number (1-4) senden muss, während die Rückmeldung über ein Byte kommt (Aufbau wie bei Dir, also die unteren vier Bit für die Betriebsart, Rest für anderes Zeug).

Ich gehe stark davon aus, dass Du besser zwei Channel zur Steuerung verwenden solltest, einen für ankommend, einen für abgehend.

Meine Konfiguration sieht so aus.
Channel:

Code:

    Thing device GiraTSplus1_1_100 "TS2plus Flur" @ "KNX" [
        Type number                 : opMode "Betriebsart ist"  [ ga="5.005:<10/7/36" ]
        Type number                 : opSet "Betriebsart soll"  [ ga="5.005:10/7/28" ]
    }

Items:

Code:

Number          TS2plusFlur_OpMode      "Betriebsart ist"        (GHeat_Mode)                   {channel="knx:device:bridge:GiraTSplus1_1_100:opMode"}
Number          TS2plusFlur_OpSet       "Betriebsart soll"       (GHeat_Set)                    {channel="knx:device:bridge:GiraTSplus1_1_100:opSet"}

und diese Rule:

Code:

rule "Betriebsart RTR"
 when
        Member of GHeat_Mode changed
 then
        var Integer newMode
        val mode = (triggeringItem.state as DecimalType).toBigDecimal.toBigInteger
        val iName = triggeringItem.name.split("_").get(0).toString
        logDebug("rtr","Name is: {}, Mode is: {}",iName,mode)
        switch (mode) {
                case mode.testBit(0) : newMode = 1
                case mode.testBit(2) : newMode = 3
                case mode.testBit(3) : newMode = 4
                default : newMode = 2
        }
        var myItem = GHeat_Set.members.filter[ f | f.name.startsWith(iName) ].head
        var Integer oldMode = 0
        if(myItem.state instanceof Number) oldMode = (myItem.state as Number).intValue
        if(oldMode != newMode) {
                logDebug("rtr","Name is: {}, oldMode is: {}, newMode is: {}",myItem.name,oldMode,newMode)
                myItem.postUpdate(newMode)
        }
end

Die Rule ist für alle RTR zuständig, weshalb es da auf den ersten Blick recht wenig Bezug zu den vorhandenen Items gibt, aber die beiden Items sind Member der beiden verwendeten Gruppen.

Wie funktioniert die Rule:
Die Rule triggert, sobald einer der Member der Gruppe GHeat_Mode seinen Status ändert.
Die Rule bestimmt den Status des triggernden Items und castet den wert nach BigInteger. Der Typ BigInteger kennt nämlich eine Funktion .testBit()

mit der man prima die verschiedenen Betriebsarten erkennen kann.
Als nächstes bestimmt es den Namen des triggernden Items. der erste Teil des Namens ist dabei identisch mit dem zugehörigen Item, welches für den Setzvorgang zuständig ist. (nur heißt das eine ..._OpMode und das andere ..._OpSet)
Nun folgt der Teil, welcher den neuen Modus bestimmt, switch case ist dabei schön platzsparend.
Da ich Betriebsart 2 als default haben möchte, wird diese Betriebsart ausgewählt, sollte keines der anderen Bits gesetzt sein.
Nun sucht die Rule aus der Gruppe GHeat_Set das passende Item zum triggernden Item heraus. Falls der Modus sich geändert hat, wird das Item entsprechend mit dem neuen Modus beschrieben.

In der Sitemap habe ich die Darstellung mit vier Knöpfen gewählt:

Code:

 Switch item=TS2plusFlur_OpSet label="Betriebsart soll" mappings=[1="Komf",2="Stby",3="N8",4="Frost"]

Falls Dein Steuerbefehl die gleichen Bits setzen muss, heißen die zu sendenen Zahlen dann halt 1,2,4,8, das musst Du dann nur in der Sitemap und der Rule anpassen. Wichtig ist aber, dass empfangende und sendende GA auf zwei unterschiedlichen Channels sitzen und auf zwei unterschiedliche Items verlinkt sind.

**nubbler** · 14.09.2019, 13:23

Ok, hier gefällt mir dann schon einmal das ich die gleiche Rule für alle RTRs benutzen kann :-).

Hab es mal wie folgt übernommen:

Channel

Code:

 [COLOR=#000000]        Type number         : ch313     [ ga="5.010:3/1/3" ][/COLOR]
  [COLOR=#000000]        Type number         : ch314     [ ga="5.010:<3/1/4" ][/COLOR]

Items

Code:

 Number          EG_Bad_RTR_OpSet           "Betriebsart RTR Soll"        <heatingrtr>      (EG_Bad, RTR_Set) { channel="knx:device:bridge:t1_1_14:ch313" }
  Number          EG_Bad_RTR_OpMode          "Betriebsart RTR Ist"         <heatingrtr>      (EG_Bad, RTR_Mode) { channel="knx:device:bridge:t1_1_14:ch314" }

Rule

Code:

rule "Betriebsart RTR"
 when
        Member of RTR_Mode changed
 then
        var Integer newMode
        val mode = (triggeringItem.state as DecimalType).toBigDecimal.toBigInteger
        val iName = triggeringItem.name.split("_").get(0).toString
        logDebug("rtr","Name is: {}, Mode is: {}",iName,mode)
        switch (mode) {
                case mode.testBit(0) : newMode = 1
                case mode.testBit(1) : newMode = 2
                case mode.testBit(2) : newMode = 3
                case mode.testBit(3) : newMode = 4
                default : newMode = 2
        }
        var myItem = RTR_Set.members.filter[ f | f.name.startsWith(iName) ].head
        var Integer oldMode = 0
        if(myItem.state instanceof Number) oldMode = (myItem.state as Number).intValue
        if(oldMode != newMode) {
                logDebug("rtr","Name is: {}, oldMode is: {}, newMode is: {}",myItem.name,oldMode,newMode)
                myItem.postUpdate(newMode)
        }
end

Sitemap

Code:

 Switch item=EG_Bad_RTR_OpSet label="Betriebsart soll" mappings=[1="Komfort",2="Standby",3="Nacht",4="Frost"]

Das Funktioniert soweit mit der Steuerung über die Sitemap (zumindest wenn ich die Betriebsarten im Switch Item nicht zu schnell durchklicke).
Aber wenn ich den Betriebsstatus am RTR selber ändere, wird das Switch Item nicht aktualisiert...

**udo1toni** · 14.09.2019, 22:34

Das Problem ist, dass Dein Itemname mehrere Unterstriche enthält. iName wird mit dem Teil des Namens gefüllt, der vor dem ersten Unterstrich steht. Falls es gute Gründe für die Unterstriche gibt, muss die entsprechende Zeile etwas angepasst werden (müsste man drüber nachdenken), am einfachsten wäre es natürlich, die vorderen Unterstriche zu entfernen...

Die Zeile

Code:

case mode.testBit(1) : newMode = 2

ist unnötige Redundanz

**nubbler** · 17.09.2019, 12:48

Hallo,

also ich bekomme es einfach nicht hin, auch mit nur einem Bindestrich. Wenn ich am RTR den Betriebsmodus ändere, kommt es im Switch Item nicht an.

Erschwerend kommt aber auch hinzu, das mit das debuggen nicht ganz leicht fällt. Wo schreibt er die logDebug Zeilen denn hin? Ich finde die Einträge weder in der openhab-log noch in der events-log. Gibt es noch andere log Dateien?

Vielen dank!

**udo1toni** · 17.09.2019, 15:33

Die logDebug Ausgabe wird nur ausgegeben, wenn Du das Logging auch auf DEBUG setzt. Es kommt ein bisschen auf die Version von openHAB an, aber grundsätzlich sieht das so aus:

Code:

openhabian@openhab2:~$ openhab-cli console

Logging in as openhab

                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.5.0-SNAPSHOT
                               Build #1502

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.

openhab> bundle:list -s | grep script
139 x Active   x  80 x 0.11.0.201901111358    x org.eclipse.smarthome.model.script
140 x Active   x  80 x 0.11.0.201901111358    x org.eclipse.smarthome.model.script.ide
141 x Active   x  80 x 0.11.0.201901111358    x org.eclipse.smarthome.model.script.runtime
228 x Active   x  75 x 0.11.0.201901111358    x org.eclipse.smarthome.transform.javascript
openhab> log:set DEBUG org.eclipse.smarthome.model.script.rtr
openhab> log:list | grep rtr
org.eclipse.smarthome.model.script.rtr             x DEBUG
openhab>

Wenn man die aktuelle OH2.5.0-M3-1 verwendet, liefert der erste Befehl aber eine andere Antwort:

Code:

171 | Active |  80 | 2.5.0.M3              | org.openhab.core.model.script

entsprechend muss dann der zweite Befehl ebenfalls anders lauten:

Code:

openhab> log:set DEBUG org.openhab.core.model.script.rtr

Der Witz ist, dass dieses Umschalten des Loggings bei laufendem openHAB funktioniert, kein Reload der Rules, kein Restart von openHAB. Es wird in diesem Fall nur das Logging für die Rules auf DEBUG gestellt, welche als Loggernamen "rtr" verwenden. Man kann also sehr präzise steuern, wie umfangreich die Ausgaben sind.

Nun zum eigentlichen Problem:
Bist Du sicher, dass die Merten RTR den geänderten Status auf den Bus schicken? (kannst Du mit dem Gruppenmonitor in ETS prüfen)
Es geht auch nicht um einen Bindestrich, sondern um einen Unterstrich

Und meine Rule verwendet Number Items, keine Switch Items. Aber das ist vielleicht nur in der Hitze des Gefechts passiert...

**nubbler** · 25.10.2019, 22:28

Hallo, sorry, die letzten Wochen konnte ich das Thema nicht mehr weiterverfolgen...

Die LogFiles hatte ich im September versucht zu aktivieren, die Einstellung hatte aber nichts gebracht. Wollte mir das eben nochmal genau anschauen, komme nun aber nicht mehr auf die openhab-Console im Synology. Ich weiß allerdings nicht mehr wie ich damals darauf gekommen bin....

Code:

user@synology:~$ openhab-cli console
-sh: openhab-cli: command not found

Code:

user@synology:~$ sudo ssh -p 8101 -l openhab localhost
ssh_exchange_identification: Connection closed by remote host

Aber gut, das ist erstmal ein Nebenproblem. Wie gesagt, die Steuerung des Betriebsmodus über openhab funktioniert, nur wenn ich den Betriebsmodus am Taster ändere wird die Anzeige in Openhab nicht angepasst. Also wenn ich am Taster von Nacht auf Standby Umschalte wird der Betriebsmodus geändert, die SOLL Temperatur korrekt geändert und RTR_Mode Item korrekt angezeigt. Das RTR_Set Item bleibt aber auf Nacht stehen...da das RTR_Mode Item korrekt geändert wird gehe ich davon aus das der Merten RTR auch den STatus auf den Bus schickt...(mein Busmonitor funktioniert nicht, daher kann ich das nicht direkt prüfen - vermutlich da ich die ETS3 in VirtualBox laufen habe...)

things

Code:

         Type number         : ch313     [ ga="5.010:<3/1/3" ]
          Type number         : ch314     [ ga="5.010:<3/1/4" ]

items

Code:

 Number          EGBadRTR_OpSet             "Betriebsart RTR Soll"        <heatingrtr>      (EG_Bad, RTR_Set) { channel="knx:device:bridge:t1_1_14:ch313" }
  Number          EGBadRTR_OpMode            "Betriebsart RTR Ist"         <heatingrtr>      (EG_Bad, RTR_Mode) { channel="knx:device:bridge:t1_1_14:ch314" }

sitemap

Code:

Switch item=EGBadRTR_OpSet label="Betriebsart soll" mappings=[1="Komfort",2="Standby",3="Nacht",4="Frost"] Text item=EGBadRTR_OpSet label="Betriebsart soll"
  Text item=EGBadRTR_OpMode

Wie Beschrieben, EGBadRTR_OpSet ändert sich nicht wenn am RTR direkt umgestellt wird. EGBadRTR_OpMode ändert sich und wird in openhab auch angezeigt.

rule

Code:

rule "Betriebsart RTR"
 when
        Member of RTR_Mode changed
 then
        var Integer newMode
        val mode = (triggeringItem.state as DecimalType).toBigDecimal.toBigInteger
        val iName = triggeringItem.name.split("_").get(0).toString
        logDebug("rtr","Name is: {}, Mode is: {}",iName,mode)
        switch (mode) {
                case mode.testBit(0) : newMode = 1
                case mode.testBit(1) : newMode = 2
                case mode.testBit(2) : newMode = 3
                case mode.testBit(3) : newMode = 4
        }
        var myItem = RTR_Set.members.filter[ f | f.name.startsWith(iName) ].head
        var Integer oldMode = 0
        if(myItem.state instanceof Number) oldMode = (myItem.state as Number).intValue
        if(oldMode != newMode) {
                logDebug("rtr","Name is: {}, oldMode is: {}, newMode is: {}",myItem.name,oldMode,newMode)
                myItem.postUpdate(newMode)
        }
end

Und ja, ich meinte ja auch Unterstrich (hatte nur Bindestrich geschrieben da ich versucht hatte meine Benennungen beizubehalten und hatte daher das Trennzeichen mal Testweise in Bindestrich geändert). Mit Switch Item meinte ich die Anzeige/Steuerung in der Sitemap. :-)

**udo1toni** · 26.10.2019, 08:06

Wenn Du openhab-cli nicht zur Verfügung hast, wäre der korrekte Befehl dieser:

Code:

user@synology:~$ ssh openhab@localhost -p8101

Was zeigt denn EGBadRTR_OpMode in der Sitemap an?

**nubbler** · 26.10.2019, 13:05

Zitat von udo1toni Beitrag anzeigen

Wenn Du openhab-cli nicht zur Verfügung hast, wäre der korrekte Befehl dieser:

Code:

user@synology:~$ ssh openhab@localhost -p8101

zeigt ebenfalls

Code:

ssh_exchange_identification: Connection closed by remote host

Zitat von udo1toni Beitrag anzeigen

Was zeigt denn EGBadRTR_OpMode in der Sitemap an?

Betriebsart 1 --> 33
Betriebsart 2 --> 34
Betriebsart 3 --> 36
Betriebsart 4 --> 232

Die angezeigten Werte sind gleich, egal ob ich beim RTR oder in openHAB die Betriebsart umschalte.

**udo1toni** · 26.10.2019, 22:26

Da Du momentan offensichtlich nicht auf die karaf Konsole kommst, kannst Du statt logDebug einfach logInfo schreiben, dann sollten die Meldungen in der Datei openhab.log auftauchen.
Hast Du openHAB mal zwischendurch neu gestartet?

**zukunftathome** · 27.10.2019, 14:40

Hi udo1toni ,
vielen Dank für die ausführliche Anleitungen und den genialen Code. Ich habe bei mir Gira RTR Tasetensorgen V2 verbaut und soweit funktioniert die Umschaltung der Betriebsmodi.

Allerdings habe ich einen interessanten Effekt, sobald ich nicht im Modus Komfort bin. Ist der Taster z.B. im Modus "Nacht" und ich möchte dann die Temperatur ändern, dann springt die Temperatur immer 2,1 Grad nach unten (egal ob ich hoch oder runter regle) bis 7 Grad. Ab da läuft alles wieder normal. Ich habe ein Video in mein Drive hochgeladen
Die Werte werden auch entsprechend auf den Bus geschrieben und sind als neue Soll Temperatur am Taster eingestellt.

Schalte ich in openHAB den Betriebsmodus um und passe am Taster selbst die Temperatur an ist alles normal.

Things:

Code:

Type number         : temperatur_EG_Eingang_Ist                 "IST Eingang [%.1f °C]"     [ga="<13/1/1"]
        Type number         : temperatur_EG_Eingang_Soll                "SOLL Eingang [%.1f °C]"    [ga="3/1/2+<13/1/2"]
        Type number         : ventil_EG_Eingang_Status                  "Status Eingang [%s %%]"    [ga="5.001:<13/1/3"]
        Type number         : betriebsmodus_EG_Eingang                  "Betriebsmodus [%s]"        [ga="5.005:3/1/1"]
        Type number         : betriebsmodus_EG_Eingang_Status           "Betriebsmodus Status [%s]" [ga="5.005:<13/1/4"]

Meine Items:

Code:

Number Temperatur_EG_Eingang_Ist "IST Eingang [%.1f °C]" <temperature>  (TemperaturIst, HeizungIst, Temperatur, Heizung, HeizungEG)  { channel="knx:device:bridge:thermoantriebaktor1:temperatur_EG_Eingang_Ist" }
    Number Temperatur_EG_Eingang_Soll "SOLL Eingang [%.1f °C]" <temperature>  (Temperatur, HeizungSoll, HeizungEG)  { channel="knx:device:bridge:thermoantriebaktor1:temperatur_EG_Eingang_Soll" }
    Dimmer Ventil_EG_Eingang_Status "Status Eingang [%s %%]" (Status, Heizung, HeizungEG) { channel="knx:device:bridge:thermoantriebaktor1:ventil_EG_Eingang_Status" }
    Number Betriebsmodus_EG_Eingang "Betriebsmodus [%s]" (GHeat_Set, Betriebsmodus ) { channel="knx:device:bridge:thermoantriebaktor1:betriebsmodus_EG_Eingang" }
    Number Betriebsmodus_EG_Eingang_Status "Betriebsmodus Status [%s]" (GHeat_Mode) { channel="knx:device:bridge:thermoantriebaktor1:betriebsmodus_EG_Eingang_Status" }

Rule:

Code:

rule "Betriebsart RTR"
 when
        Member of GHeat_Mode changed
 then
        var Integer newMode
        val mode = (triggeringItem.state as DecimalType).toBigDecimal.toBigInteger
        val iName = triggeringItem.name.split("_").get(0).toString
        logDebug("rtr","Name is: {}, Mode is: {}",iName,mode)
        switch (mode) {
                case mode.testBit(0) : newMode = 1
                case mode.testBit(2) : newMode = 3
                case mode.testBit(3) : newMode = 4
                default : newMode = 2
        }
        var myItem = GHeat_Set.members.filter[ f | f.name.startsWith(iName) ].head
        var Integer oldMode = 0
        if(myItem.state instanceof Number) oldMode = (myItem.state as Number).intValue
        if(oldMode != newMode) {
                logDebug("rtr","Name is: {}, oldMode is: {}, newMode is: {}",myItem.name,oldMode,newMode)
                myItem.postUpdate(newMode)
        }
end

Sitemap:

Code:

Frame label="Heizung Eingang EG"
                {
                    Text item=Temperatur_EG_Eingang_Ist icon="temperature"
                    Setpoint item=Temperatur_EG_Eingang_Soll step=0.1 icon="temperature"
                    Text item=Ventil_EG_Eingang_Status icon="heating"
                    Selection item=Betriebsmodus_EG_Eingang label="Betriebsmodus [%s]" mappings=[1="Komfort", 2="Abwesend", 3="Nacht", 4="Frost"] icon="house"
                }

Vielleicht hast du eine Idee was das Phänomen auslöst.

Viele Grüße
Patrick

**nubbler** · 27.10.2019, 22:30

Zitat von udo1toni Beitrag anzeigen

Da Du momentan offensichtlich nicht auf die karaf Konsole kommst, kannst Du statt logDebug einfach logInfo schreiben, dann sollten die Meldungen in der Datei openhab.log auftauchen.
Hast Du openHAB mal zwischendurch neu gestartet?

Nunja, nachdem ich mich gewundert habe das ich mit logInfo immer noch keine logs bekomme bin ich nun nach langer suche darauf gekommen wo hier der grundsätzliche Fehler liegt: Ich Depp habe die Rule-Date nicht *.rules sondern *.rule genannt

So komme ich natürlich trotz deiner super Hilfe hier nicht weiter....

Nachdem das behoben war geht's zwar immer noch nicht, aber wenigstens sehe ich jetzt auch konkrete Fehlermeldungen:

Code:

 2019-10-27 22:18:39.696 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Betriebsart RTR': The name 'RTR_Set' cannot be resolved to an item or type; line 15, column 22, length 7

Er findet also das Item der RTR_Set Gruppe nicht. Komisch da die Gruppe so korrekt zugeordnet ist und er die Items der RTR_Mode ja findet....

nochmal die Items:

Code:

 Number          EGBadRTR_OpSet             "Betriebsart RTR Soll"                    <radiator>        (EG_Bad, RTR_Set)  { channel="knx:device:bridge:t1_1_14:ch313" }
  Number          EGBadRTR_OpMode            "Betriebsart RTR Ist"                     <radiator>      (EG_Bad, RTR_Mode) { channel="knx:device:bridge:t1_1_14:ch314" }

Jetzt hoffe ich du hast hier noch eine Idee (na wenigstens die Dimmer habe ich eben selbst hinbekommen :-))

Achja, openHAB wurde schon öfters neugestartet da ich auch für die Dimmer und Rollläden auch in der ETS einiges nachpflegen musste und ich openHAB immer stoppen muss damit ich die ETS programmieren kann.

Danke und Grüße

**udo1toni** · 28.10.2019, 23:44

Du musst die Gruppe aber auch als Item definieren, nicht nur Items dier Gruppe zuordnen

**nubbler** · 07.11.2019, 14:25

Zitat von udo1toni Beitrag anzeigen

Du musst die Gruppe aber auch als Item definieren, nicht nur Items dier Gruppe zuordnen

:-) Ja das war es natürlich, vielen Dank für deine Hilfe

Aktuell habe ich zwei Merten RTR drin und einmal den RTR des Busch-Jäger Comfort-Panels. Es funktioniert bei allen drei über die gleiche Rule, nur beim Busch-Jäger RTR habe ich den Effekt das beim Umschalten der Betriebsart am Panel es korrekt in der Sitemap angezeigt wird (Zustand wechselt zwischen 1,2,3 und 4), nur wird die aktuelle Selection Schaltfläche nicht ausgewählt (alle werden als inaktiv angezeigt). Ist jetzt wirklich nur ein Schönheitsfehler, aber was könnte der Grund dafür sein? Gibt es einen Befehl den man in die Rule einbauen könnte das er die Sitemap anzeige nochmal "aktualisiert" o.ä.? Oder ist das einfach ein Bug in der Android App?

**udo1toni** · 09.11.2019, 02:56

Schwierig zu sagen. Solche Fehler können verschiedene Ursachen haben, vielleicht schaust Du mal, was das Log für das entsprechende Item hergibt.

Ankündigung

Merten RTR Betriebsart

Merten RTR Betriebsart

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar