Rückmeldeobjekt aus MDT Heizungsaktor verarbeiten

[Peiper]

Hallo zusammen,

ich bin dabei endlich mal meine openHAB Kombi mit RTR Tastern zum Laufen zu bringen.

Als Heizungsaktor verwende ich einen MDT AKH mit integriertem Regler.

Der Sollwert Komfort kann über openHAB eingestellt werden. Hierfür meine Things:

Type number : FF_Gaestezimmer_Soll_Temperatur "Temperatur (Soll)" [ ga="9.001:3/3/5" ]

Funktioniert auch wunderbar, solange nur OH2 und der MDT im Spiel ist...

Nun kommen noch die Gira TS3+ RTR dazu. Die können über 1 Byte Sollwertverschiebung dem MDT AKH ebenfalls eine Sollwertverschiebung mitteilen. Funktioniert auch soweit.

Was nicht funktioniert ist, dass die Sollwertverschiebung durch die Gira TS3+ an OH2 übergeben wird. Ich habe versucht, dies über eine Erweiterung des Things zu lösen und damit den Aktuellen Sollwert (GA 3/4/5) des MDT Heizungsaktors (auf den sich die Sollwertverschiebung durch die Gira TS3+ beziehen) vom Bus zu lesen:

Type number : FF_Gaestezimmer_Soll_Temperatur "Temperatur (Soll)" [ ga="9.001:3/3/5+<3/4/5" ]

Das funktioniert aber leider nicht, es wird weiterhin der Sollwert Komfort angezeigt in der BasicUI (GA 3/3/5).

Hier die GA Struktur:
3/1/5 = Ist Temperatur vom RTR Sensor
3/3/5 = Sollwert Komfort
3/4/5 = Aktueller Sollwert MDT AKH
3/7/5 = Sollwertverschiebung

OpenHab Logfile vom Testfall (Sollwertverschiebung um 4 x -0,1K über GA 3/7/5 von 20,4 °C auf 20,0 °C):

2020-11-06 19:21:02.479 [GroupItemStateChangedEvent] - gHeating changed from 21.4 to 21.3 through FF_Gaestezimmer_Soll_Temperatur
2020-11-06 19:21:02.482 [vent.ItemStateChangedEvent] - FF_Gaestezimmer_Soll_Temperatur changed from 20.3 to 20.0
2020-11-06 19:21:02.521 [GroupItemStateChangedEvent] - gHeating changed from 21.3 to 21.4 through FF_Gaestezimmer_Soll_Temperatur
2020-11-06 19:21:02.524 [vent.ItemStateChangedEvent] - FF_Gaestezimmer_Soll_Temperatur changed from 20.0 to 20.3
==> /var/log/openhab2/openhab.log <==
2020-11-06 19:21:10.065 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
tuwien.auto.calimero.KNXIllegalArgumentException: non-valid routing multicast localhost/127.0.0.1
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.<ini t>(KNXnetIPRouting.java:162) ~[?:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.<ini t>(KNXnetIPRouting.java:145) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.g etConnection(IPClient.java:122) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.c reateKNXNetworkLinkIP(IPClient.java:93) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.e stablishConnection(IPClient.java:80) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKN XClient.connect(AbstractKNXClient.java:178) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.jav a:266) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.access$201(ScheduledThreadPoolE xecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.run(ScheduledThreadPoolExecutor .java:293) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
==> /var/log/openhab2/events.log <==
2020-11-06 19:21:19.739 [ome.event.ItemCommandEvent] - Item 'FF_Gaestezimmer_Soll_Temperatur' received command 20.400000000000002
2020-11-06 19:21:19.754 [nt.ItemStatePredictedEvent] - FF_Gaestezimmer_Soll_Temperatur predicted to become 20.3
2020-11-06 19:21:19.967 [GroupItemStateChangedEvent] - gHeating changed from 21.4 to 21.383333333333334 through FF_Gaestezimmer_Soll_Temperatur
2020-11-06 19:21:19.969 [vent.ItemStateChangedEvent] - FF_Gaestezimmer_Soll_Temperatur changed from 20.3 to 20.400000000000002
2020-11-06 19:21:23.786 [vent.ItemStateChangedEvent] - HO_Date changed from 2020-11-06T19:20:53.763+0100 to 2020-11-06T19:21:23.765+0100
2020-11-06 19:21:40.499 [GroupItemStateChangedEvent] - gHeating changed from 21.383333333333334 to 21.3 through FF_Gaestezimmer_Soll_Temperatur
2020-11-06 19:21:40.504 [vent.ItemStateChangedEvent] - FF_Gaestezimmer_Soll_Temperatur changed from 20.400000000000002 to 20.0
2020-11-06 19:21:40.708 [vent.ItemStateChangedEvent] - FF_Gaestezimmer_Soll_Temperatur changed from 20.0 to 20.400000000000002

Anbei noch die entsprechenden Screens aus der ETS Konfiguration sowie der Testfall (wie im OH Logfile als Gruppenmonitoraufzeichnung).

Bitte nicht verwirren lassen, das Kinderzimmer ist aktuell gleich Gästezimmer... ;-)

Wo kann ich ansetzen? Vielen Dank für die Hilfe!


Gruppenmonitor Testfall:
ga_monitor.png

MDT AKH Kanal GA Parameter
mdt_akh.png

Gira TS3+ Parameter
gira_ts3plus.png

[udo1toni]

Du kannst Doch nicht zwei voneinander unabhängige Werte auf einen Channel mappen und dann erwarten, dass das funktioniert!?!

Über openHAB hast Du den Sollwert Komfort verbunden. Der Sollwert Komfort hat nichts mit Sollwertverschiebung zu tun. Wenn Du also am MDT die Komforttemperatur änderst, verstellst Du den Sollwert Komfort. Ebenso passiert das über openHAB.
Wenn Du jedoch über den Gira den Sollwert verschiebst, so wird der Bezugspunkt auf den Sollwert verschoben. Gewöhnlich ist es so, dass Du eine Komforttemperatur hast, z.B. 22°C. Die Nachtabsenkung läuft dann über eine Sollwertverschiebung, z.B. -2 °C, das ergibt dann 20°C, aber der Sollwert Komfort ist weiterhin 22°C. Der aktuelle Sollwert ist jedoch 20°C. Schaltest Du zurück auf Komfort, so ist der Sollwert wieder 22°C.
Änderst Du am MDT die Komforttemperatur, so ändert sich auch die Nachtabsenkung entsprechend. aus Soll Komfort 21.5°C werden dann Soll Nacht 19,5°C usw.
Die Sollwertverschiebung über den Gira verstellt nun also den Null-Punkt. Die Komforttemperatur entspricht damit nicht mehr der Solltemperatur.

Entweder passt Du openHAB dahingehend an, dass es die Temperatur ebenfalls über die Sollwertverschiebung steuert (und lässt die Finger vom MDT) oder Du passt den Gira dahingehend an, dass er die Komforttemperatur direkt steuert, nicht die Sollwertverschiebung.

Alternativ kannst Du natürlich in openHAB die Verschiebung mit berücksichtigen, ich fürchte aber, das wird kompliziert.

[Peiper]

Ich muss zugeben, dass ich mit dem ganzen Kram Sollwertverschiebung, Nachtabsenkung etc. noch nicht ganz durchsteige.

Allerdings brauche ich das auch alles nicht. Wir haben einen Neubau mit FBH, d.h. mit Nachtabsenkung etc. brauche ich nicht anzufangen.

Eigentlich wäre es mir am liebsten nur den Sollwert Komfort zu ändern (wie eben aktuell mit OH2). Leider scheint das mit den Gira TS3+ nicht zu funktionieren. Deswegen hier der Umweg über die Sollwertverschiebung.

Mir ist eben nur noch nicht ganz klar wie ich beide Techniken kombinieren muss um a) den Sollwert Komfort über OH2 zu ändern und b) über die Sollwertverschiebung mit den Gira TS3+ ändern zu können.

Zum Thema Sollwertverschiebung...wenn ich den Sollwert Komfort (3/3/5) ändere, ändert sich der Aktuelle Sollwert (3/4/5) im MDT ja auch direkt entsprechend, mir ist eben nur nicht klar wie ich das mit den Gira TS3+ vergleichbar hinbekommen kann?
ga_monitor2.png

[udo1toni]

Ich könnte jetzt eine Gegenfrage stellen, warum Du überhaupt TS3+ einsetzt, wenn Du HVAC doch über den MDT steuerst.

Ich habe das bei mir nicht in Betrieb, denke aber, dass Du den TS3+ als Wertgeber betreiben musst. Dabei musst Du dann natürlich direkt den Sollwert und die Rückmeldung Sollwert im TS3+ eintragen. Da es auf den ersten Blick kein entsprechendes KO gibt, schau mal in die Konfigurationsoberfläche des TS3+, ob man das parametrieren kann. Ich habe bei mir nur TS2+ verbaut.

[Peiper]

Die Gegenfrage ist prinzipiell ja berechtigt...aber wenn die Gira TS3+ schon an der Wand hängen und die Soll Temperatur anzeigen, sollte man sie damit auch verändern können. Im Worst Case sollte die KNX Installation ja auch ohne OH2 laufen (tut sie aktuell auch, bis auf die RTR eben).

Ich habe auch versucht die Gira TS3+ so zu konfigurieren (siehe Screenshot), dass sie bei Änderungen den absoluten Sollwert Komfort auf den Bus schreiben, das klappt auch allerdings kommt dann bei jeder Änderung um 0,1K die Meldung "Die Einstellung wurde verworfen" (siehe Screenshot) und man muss ca. 15s warten bis man weitermachen kann, das ist nicht gerade der Hit. Hab deswegen schon eine Anfrage beim Gira Support laufen.

Deswegen ist aktuell die Kombination aus Sollwert Komfort über OH2 und Sollwertverschiebung über TS3+ meine letzte Hoffnung aber wie gesagt da hänge ich derzeit noch.

Ich verstehe auch nicht welchen Wert der MDT AKH nun konkret als Referenz für die gewünschte Raumtemperatur nimmt: a) Sollwert Komfort oder b) Aktueller Sollwert?

Fehlermeldung TS3+
ts3plus_meldung.png

Parametrisierung TS3+ für Solltemperatursteuerung über absoluten Sollwert Komfort (3/3/0 = Sollwert Komfort, 3/4/0 = Aktueller Sollwert MDT AKH)
gira_ts3plus_sollwertkomfort.png

[udo1toni]

Der MDT nutzt den aktuellen Sollwert zur Regelung. Du kannst mit einem Befehl die Sollwertverschiebung auf bestimmte Werte setzen (z.B. mittels Nachtabsenkung), auch auf 0, womit dann gilt: aktuelle Solltemperatur = Solltemperatur Komfort.

[Peiper]

Dann müsste es doch theoretisch funktionieren wenn ich den TS3+ so konfigurieren würde, dass er mit Sollwertverschiebung arbeitet (GA 3/7/5) und als Sollwert im Display den Aktuellen Sollwert (GA 3/4/5) vom MDT anzeigt (denn das ist dann ja der gültige Sollwert)?

Und für OpenHAB müsste ich die Konfiguration so umsetzen, dass in der Sitemap ebenfalls der Aktuelle Sollwert vom MDT (GA 3/4/5) angezeigt wird aber Änderungen am Sollwert über den Sollwert Komfort (GA 3/3/5) auf den Bus geschrieben werden (da der Absolute Sollwert vom MDT nicht direkt über die GA änderbar ist)?

Würde das auf Seiten von openHAB ohne eine Rule funktionieren?

[udo1toni]

Warum sollte der Sollwert nicht direkt geändert werden können? Das Problem ist doch nur, dass der TS3+ nicht in der Lage ist, die Komforttemperatur direkt zu steuern?

[Peiper]

Hab jetzt die Konfiguration so umgebaut, dass die TS3+ die FBH Regelung übernehmen und der MDT AKH nur noch die Ventile ansteuert (1 bit).

Leider nicht meine Wunschkonfiguration aber laut Gira und MDT Support die einzige die mit dieser Konstellation sauber mit absoluten Sollwerten arbeitet.