Heizungsaktoren steuern mit OpenHAB2. Wie komme ich von Ist zu Soll?

[maxheartrate]

Liebe Foristen,

dank Eurer vielen Erklärungen hier konnte ich als KNX- und OpenHAB-Einsteiger mein System in Gang bringen. Bei der Heizungssteuerung komme ich mit den Lösungsvorschlägen hier und anderswo nicht weiter. Vielleicht kann das jemand von Euch Newbie-verständlich erklären.

Ich habe an den Stellventilen der Fußbodenheizung Aktoren von MDT. Dafür hat unser Systemintegrator nach folgendem Schema Gruppenadressen angelegt:

Erdgeschoss Flur
3/1/9 EG-Flur-Temperaturwert IST - Temperatur (°C)
3/2/9 EG-Flur-Sollwert Komfort - Temperatur (°C)
3/2/26 EG-Flur-aktueller Sollwert - Temperatur (°C)
3/3/9 EG-Flur-Komfortbetrieb - Schalten
3/3/26 EG-Flur-Nachtbetrieb - Schalten
3/3/43 EG-Flur-Frostbetrieb - Schalten
3/4/9 EG-Flur-Frostalarm - Alarm
3/4/26 EG-Flur-Hitzealarm - Alarm
3/5/9 EG-Flur-Sollwertverschiebung - Schritt
3/6/9 EG-Flur-Betriebsartauswahl - HVAC Modus
3/6/26 EG-Flur-HVAC-Status - 1 byte
3/7/9 EG-Flur-Status Stellwert - Prozent (0 .. 100%)

Die Heizungssteuerung soll ausschließlich über die OpenHAB Visualisierung erfolgen. Wir haben Sensoren in den Tastern, aber keine Stellmöglichkeit.

Was ich hinbekommen habe, ist das Auslesen der IST- und der SOLL-Temperaturen:

home.things

Type number : EG_Flur_Temp_Ist "EG Flur Temperatur Ist" [ ga="9.001:<3/1/9" ]
Type number : EG_Flur_Temp_Soll "EG Flur Temperatur Soll" [ ga="9.001:<3/2/26" ]

home.items

Number GF_FlurEg_Temperature "Flur Temperatur [%.1f °C]" <temperature> (GF_FlurEg, gTemperature) ["Temperature"] {channel="knx:device:bridge:generic:EG_Flur_Temp_Ist"}
Number GF_FlurEg_Heating "Flur Heizung" <heating> (GF_FlurEg, gHeating) ["HVAC"] {channel="knx:device:bridge:generic:EG_Flur_Temp_Soll"}

Ergebnis: Ist-Temperatur 22,7 °C. Soll-Temperatur 19 °C.

Jetzt wird es für mich zu kompliziert. In diversen Foren-Beiträgen wird über prozentuale Verschiebungen diskutiert. Ein User hat vor einer Weile geschrieben, er übergibt einfach nur die Ist- und die Solltemperatur an den Aktor und der errechnet dann selbst die Differenz. Nur leider gibt es dafür kein Code-Beispiel. Ich habe es mit diversen Rule-Befehlen versucht, die ich gefunden habe. Die möchte ich hier lieber nicht posten, damit ich keinen Mist verbreite. Momentan ist in meiner Visu eine +/- Steuerung mit Setpoint, aber die bekome ich nicht ans Laufen.

Ziel der Übung ist "einfach" nur, dass ich in der OpenHAB-Visualisierung einen Sollwert für den Raum einstelle und dann wird die Heizung entsprechend hoch- bzw. runtergeregelt, bis die Ist-Temperatur den neuen Sollwert erreicht hat. Wenn ich zusätzlich noch einfach zwischen den Heizungsmodi Komfort, Nacht und Frost wechseln könnte, wäre das die Kür.

Für weiterführende Hinweise dankt
maxheartrate.

[udo1toni]

Schau mal bei MDT nach dem exakten Aktor und lade Dir die technische Referenz herunter. Dort kannst Du nachlesen, wie die Steuerung genau funktioniert (das ist von Modell zu Modell meist etwas unterschiedlich).
In der Liste der GA gibt es nur eine Solltemperatur, die kannst Du einstellen. Über die Umschaltung auf Nacht aktivierst Du vermutlich eine fixe Sollwertverschiebung.
Die Betriebsart wählst Du vermutlich über HVAC Betriebsart aus, die Rückmeldung, welche Betriebsart ausgewählt ist, kommt entsprechend über den Status rein.

Es ist möglich, dass die Betriebsart anders rückgemeldet wird, als die dazu passende Steuerung funktioniert (das ist z.B. bei meinen TS2plus von Gira der Fall). Falls das so ist, musst Du eine Rule bauen, die die Rückmeldung entsprechend auf das Item spiegelt (deshalb ist die genaue Kenntnis des Modells so wichtig).

Der Sollwert sollte so aussehen:

Type number : EG_Flur_Temp_Soll "EG Flur Temperatur Soll" [ ga="9.001:3/2/9+<3/2/26" ]

Funktioniert evtl. auch ohne Angabe des DPT. openHAB sendet den Sollwert über 3/2/9 und empfängt den aktuellen Sollwert über 3/2/9 und 3/2/26. openHAB sendet bei Systemstart einen Read request auf 3/2/26.

[maxheartrate]

Vielen Dank für Deine Hilfe, @udo1toni!

Den Sollwert-Tipp werde ich gleich ausprobieren. Dann müsste ich doch auch über eine Regel und einen Setpoint eine konkrete Zahl - also nicht umständlich Prozentwerte - als Soll-Temperatur an den Aktor senden können, oder?

[udo1toni]

Der Sollwert sollte in °C codiert sein, nicht in Prozent. Der Prozentwert bezieht sich auf den Stellantrieb, also, zu wie viel % das Ventil gerade geöffnet ist/sein soll.

[maxheartrate]

Ich habe versucht, das umzusetzen. Dabei habe ich mich an diesem Thread im Forum orientiert:
https://knx-user-forum.de/forum/supp...openhab-setzen

Spoiler: Es funktioniert nicht.

home.things
Hier habe ich es als Type dimmer und number versucht:

Type dimmer : EG_Flur_Temp_Soll "EG Flur Temperatur Soll" [ ga="5.001:3/2/9+<3/2/26" ]

home.items

Number GF_FlurEg_Heating "Flur Heizung" <heating> (GF_FlurEg, gHeating) ["HVAC"] {channel="knx:device:bridge:generic:EG_Flur_Temp_Soll"}

home.rules

rule "update_EG_Flur_Temp_Soll"
when
Item GF_FlurEg_Heating changed
then
var int value = (GF_FlurEg_Heating.state as DecimalType).intValue
GF_FlurEg_Heating.postUpdate(value)
GF_FlurEg_Heating.sendCommand(value)
end
[U][/U]

home.sitemap

Setpoint item=GF_FlurEg_Heating step=0.5 minValue=17 maxValue=28 label="Soll-Temperatur"

Resultat:
In der Visualisierung kann ich den Wert nicht setzen. Mal ist er fest, mal springt er beim Drücken von '+' in Zwei-Gradschritten ins Minus.

Im Log sieht das so aus:

2019-02-10 20:41:38.604 [nt.ItemStatePredictedEvent] - GF_FlurEg_Heating predicted to become 7.5

2019-02-10 20:41:38.620 [vent.ItemStateChangedEvent] - GF_FlurEg_Heating changed from 7 to 7.5

2019-02-10 20:41:38.625 [B][GroupItemStateChangedEvent][/B] - gHeating changed from 14.3 to 14.5 through GF_FlurEg_Heating

2019-02-10 20:41:38.669 [ome.event.ItemCommandEvent] - Item 'GF_FlurEg_Heating' received command 7

2019-02-10 20:41:38.679 [vent.ItemStateChangedEvent] - GF_FlurEg_Heating changed from 7.5 to 7

2019-02-10 20:41:38.683 [B][GroupItemStateChangedEvent][/B] - gHeating changed from 14.5 to 14.3 through GF_FlurEg_Heating

2019-02-10 20:41:38.689 [nt.ItemStatePredictedEvent] - GF_FlurEg_Heating predicted to become 7

2019-02-10 20:41:38.695 [ome.event.ItemCommandEvent] - Item 'GF_FlurEg_Heating' received command 7

2019-02-10 20:41:38.699 [nt.ItemStatePredictedEvent] - GF_FlurEg_Heating predicted to become 7

2019-02-10 20:41:42.677 [ome.event.ItemCommandEvent] - Item 'GF_FlurEg_Heating' received command 7.5

2019-02-10 20:41:42.688 [nt.ItemStatePredictedEvent] - GF_FlurEg_Heating predicted to become 7.5

2019-02-10 20:41:42.707 [vent.ItemStateChangedEvent] - GF_FlurEg_Heating changed from 7 to 7.5

2019-02-10 20:41:42.714 [B][GroupItemStateChangedEvent][/B] - gHeating changed from 14.3 to 14.5 through GF_FlurEg_Heating

2019-02-10 20:41:42.734 [vent.ItemStateChangedEvent] - GF_FlurEg_Heating changed from 7.5 to 7

2019-02-10 20:41:42.738 [B][GroupItemStateChangedEvent][/B] - gHeating changed from 14.5 to 14.3 through GF_FlurEg_Heating

2019-02-10 20:41:42.740 [ome.event.ItemCommandEvent] - Item 'GF_FlurEg_Heating' received command 7

2019-02-10 20:41:42.743 [nt.ItemStatePredictedEvent] - GF_FlurEg_Heating predicted to become 7

2019-02-10 20:41:42.755 [ome.event.ItemCommandEvent] - Item 'GF_FlurEg_Heating' received command 7

2019-02-10 20:41:42.758 [nt.ItemStatePredictedEvent] - GF_FlurEg_Heating predicted to become 7

[maxheartrate]

Kleines Update aus dem Logfile:

Ich glaube, meine "Lösung" gefällt meinem Rechner ganz und gar nicht.

Folgende Fehlermeldung kommt jetzt ständig:

2019-02-10 20:48:07.193 [ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.

org.glassfish.jersey.server.internal.process.MappableException: org.eclipse.jetty.io.EofException

    at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:92) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130) ~[171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:711) [172:org.glassfish.jersey.core.jersey-server:2.22.2]

    at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:444) [172:org.glassfish.jersey.core.jersey-server:2.22.2]

    at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:434) [172:org.glassfish.jersey.core.jersey-server:2.22.2]

    at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:329) [172:org.glassfish.jersey.core.jersey-server:2.22.2]

    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [171:org.glassfish.jersey.core.jersey-common:2.22.2]

    at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [172:org.glassfish.jersey.core.jersey-server:2.22.2]

    at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [172:org.glassfish.jersey.core.jersey-server:2.22.2]

    at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

    at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]

    at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [20:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]

    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) [85:org.eclipse.jetty.servlet:9.4.11.v20180605]

    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) [85:org.eclipse.jetty.servlet:9.4.11.v20180605]

    at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3]

    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [82:org.eclipse.jetty.security:9.4.11.v20180605]

    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3]

    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) [85:org.eclipse.jetty.servlet:9.4.11.v20180605]

    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3]

    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.Server.handle(Server.java:531) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) [75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) [75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) [87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) [87:org.eclipse.jetty.util:9.4.11.v20180605]

    at java.lang.Thread.run(Thread.java:748) [?:?]

Caused by: org.eclipse.jetty.io.EofException

    at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:286) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:429) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:323) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:380) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:798) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224) ~[87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:538) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:790) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:846) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:240) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:216) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:541) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at java.io.OutputStream.write(OutputStream.java:75) ~[?:?]

    at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.write(ResponseWriter.java:320) ~[?:?]

    at org.glassfish.jersey.message.internal.CommittingOutputStream.write(CommittingOutputStream.java:218) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$UnCloseableOutputStream.write(WriterInterceptorExecutor.java:294) ~[?:?]

    at org.eclipse.smarthome.io.rest.core.internal.GsonProvider.writeTo(GsonProvider.java:71) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]

    at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]

    at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86) ~[?:?]

    ... 53 more

Caused by: java.io.IOException: Broken pipe

    at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) ~[?:?]

    at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) ~[?:?]

    at sun.nio.ch.IOUtil.write(IOUtil.java:148) ~[?:?]

    at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:504) ~[?:?]

    at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:266) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:429) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:323) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:380) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:798) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224) ~[87:org.eclipse.jetty.util:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:538) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:790) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:846) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:240) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:216) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:541) ~[84:org.eclipse.jetty.server:9.4.11.v20180605]

    at java.io.OutputStream.write(OutputStream.java:75) ~[?:?]

    at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.write(ResponseWriter.java:320) ~[?:?]

    at org.glassfish.jersey.message.internal.CommittingOutputStream.write(CommittingOutputStream.java:218) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$UnCloseableOutputStream.write(WriterInterceptorExecutor.java:294) ~[?:?]

    at org.eclipse.smarthome.io.rest.core.internal.GsonProvider.writeTo(GsonProvider.java:71) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]

    at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106) ~[?:?]

    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]

    at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86) ~[?:?]

    ... 53 more

[udo1toni]

Dir ist aber schon bewusst, dass der Thread aus Ende 2015 stammt? Bei der Geschichte mit dem Dimmer geht es um einen Prozentwert. Temperaturen werden nicht in Prozent angegeben. DPT 9.001 ist inkompatibel mit DPT 5.001, und man kann sie nicht einfach so gegeneinander austauschen. Die Angabe des DPT dient dazu, dass openHAB versteht, ´wie die übertragenen Bits zu interpretieren sind, also z.B. 8 Bit können ein unsigned Integer sein (0-255), signed Integer (- 128 bis +127 ), Prozent (0% - 100%, Schrittweite ~0.4%) Prozent (0% - 255%), Szenenspeicher (die unteren 6 Bit kodieren eine Zahl von 0 bis 63, das oberste Bit entscheidet, ob gelesen oder geschrieben wird) oder auch eine Gruppe von 8 einzelnen Bits, die alle eine eigene Bedeutung haben.
DPT 9.001 ist 16Bit Float, welches naturgemäß gar nichts mit 5.001 (0%-100%, 8 Bit) zu tun hat.

Welchen exakten Aktor verwendest Du? Hersteller MDT reicht nicht!

[maxheartrate]

Hi udo1toni, der Aktor ist ein MDT AKH 0600.02.

[udo1toni]

Schau mal, das ist die Doku: https://www.mdt.de/download/MDT_THB_...gsaktor_02.pdf

Demnach wäre Deine Liste vermutlich so zu verstehen:

9.001 3/1/9 EG-Flur-Temperaturwert IST - Temperatur (°C)
9.001 3/2/9 EG-Flur-Sollwert Komfort - Temperatur (°C)
9.001 3/2/26 EG-Flur-aktueller Sollwert - Temperatur (°C)
1.001 3/3/9 EG-Flur-Komfortbetrieb - Schalten
1.001 3/3/26 EG-Flur-Nachtbetrieb - Schalten
1.001 3/3/43 EG-Flur-Frostbetrieb - Schalten
1.005 3/4/9 EG-Flur-Frostalarm - Alarm
1.005 3/4/26 EG-Flur-Hitzealarm - Alarm
1.007 3/5/9 EG-Flur-Sollwertverschiebung - Schritt
x.xxx 3/6/9 EG-Flur-Betriebsartauswahl - HVAC Modus
x.xxx 3/6/26 EG-Flur-HVAC-Status - 1 byte
5.001 3/7/9 EG-Flur-Status Stellwert - Prozent (0 .. 100%)

Für die Betriebsartauswahl gibt es in der Doku eine Tabelle, welche Bits welche Bedeutung haben.

Bit  DPT HVAC Status                         Hex-Wert
 0   Komfort           1=Komfort             0x01
 1   Standby           1=Standby             0x02
 2   Nacht             1=Nacht               0x04
 3   Frost/Hitzeschutz 1=Frost/Hitzeschutz   0x08
 4
 5   Heizen/Kühlen     0=Kühlen/1=Heizen     0x20
 6
 7   Frostalarm        1=Frostalarm          0x80

Da kein Typ vorgegeben ist (nur die Breite 8 Bit), musst Du einen Number Channel definieren und einen für 1 Byte sinnvollen DPT nehmen, z.B. 5.010 (8Bit unsigned Count). - Die Umsetzung in einzelne Bits muss man dann in einer Rule machen. Alternativ kannst Du natürlich die drei einzelnen Bits zur Umstellung des Modus verwenden, aber für die Rückmeldung musst Du doch den Modus auswerten.
Die Sollwertverschiebung ist als Bit (Schritt) vorgesehen, eine 0 (OFF) verringert den Sollwert um einen Schritt, eine 1 (ON) erhöht den Sollwert um einen Schritt. Wie groß die Schrittweite ist, lässt sich parametrieren, im Zweifel sendest Du ein ON/OFF und schaust, wie sich die Rückmeldung des Sollwertes ändert.
Oder Du definierst den Channel so wie von mir vorgeschlagen

Type number : EG_Flur_Temp_Soll "EG Flur Temperatur Soll" [ ga="9.001:3/2/9+<3/2/26" ]

Diesen Channel kannst Du problemlos mit einem Number Item verlinken, welches Du genauso problemlos mit einem Setpoint Widget steuern kannst.

[maxheartrate]

Vielen Dank für Deine ausführliche Antwort, udo1toni!

Wenn ich Dich richtig verstehe, kann ich die Soll-Temperatur direkt mit dem Setpoint Widget an den Aktor übergeben, oder? Ich benötige dann keine rule mit einem Abgleich der Ist-Temperatur und einem Wenn Soll höher als ist, dann Heizung aus etc.

Ich habe es gestern Abend nur mit Setpoint in der Sitemap und dem Thing wie von Dir beschrieben ausprobiert. Die Raumtemperatur ist auch etwas gesunken, aber durch die Isolierung und die anderen Heizkreise werde ich keine extreme Solltemperatur von 17 Grad erreichen können, wenn der Rest bei 20 Grad liegt. Deswegen bin ich mir nicht 100-prozentig sicher, ob es funktioniert.

[udo1toni]

Du musst ja sehen, was das Item zurück liefert, wenn Du die Solltemperatur anpasst, muss der ausgelesene Wert entsprechend angezeigt werden.

Tipp am Rande:
Wenn Du ein Item verwendest, welches zum Steuern und als Rückmeldung der eingestellten Solltemperatur dient, kannst Du verhindern, dass openHAB das Item selbst ändert.

Number GF_FlurEg_Heating "Flur Heizung" <heating> (GF_FlurEg, gHeating) ["HVAC"] {channel="knx:device:bridge:generic:EG_Flur_Temp_Soll", autoupdate="false"}

Damit wird der Status nur geändert, wenn der Aktor seinen Status schickt oder in einer Rule der Aktor Status mittels GF_FlurEg_Heating.postUpdate() gezielt gesetzt wird.

[maxheartrate]

Danke für den Tipp. Wird gleich ausprobiert.

[Intenos]

Hallo maxheartrate,

hast du es mittlerweile hinbekommen? Ansonsten schau ich mal nach und versuche die Umsetzung zu beschreiben. Ich stelle per openHAB sowohl den Betriebsmodus um als auch den Sollwert und lese die resultierenden Einstellungen sowie den Stellwert der Ventile zurück.

[maxheartrate]

udo1toni: Danke für Deine Tipps. Die waren korrekt. Das Problem ist gelöst. Es lag nicht an der Soll-Temperatur, sondern daran, dass die Heizung nicht im Komfort-, sondern im Standy-Betrieb war. Deswegen wurden die Sollwerte für den Komfortbetrieb nicht verarbeitet. Das haben wir bei einem Check mit unserem Systemintegrator festgestellt.

[clown]

@udo1toni,

Es ist möglich, dass die Betriebsart anders rückgemeldet wird, als die dazu passende Steuerung funktioniert (das ist z.B. bei meinen TS2plus von Gira der Fall). Falls das so ist, musst Du eine Rule bauen, die die Rückmeldung entsprechend auf das Item spiegelt (deshalb ist die genaue Kenntnis des Modells so wichtig).

Du hast im Forum am 10.02.19 eine Antwort gegeben und den ts2plus dabei erwähnt und das du dafür eine gute Lösung über eine Rule geschrieben hast, würdest Du mir mal ein paar Infos darüber schicken?

Gruß,
clown