KNX-Binding not changing Target-Temperature in ETS

Hello everyone!
I have an nearly-stable Openhab 3.0.1 Setup with a RaspberryPi 3B, KNX with MDT-Interface where lights, outlets, rollershutters and status-items like Actual Temperature and Valvestatus are working fine. Rules are triggering fine too. I even got the HomeKit Integration running (only lights, rollershutters an Outlets).

The problem I have is that I can´t find the right way to control the target temperatures. In the forum there are some posts with the same or nearly the same problem, but I can`t find out the missing point in my code. (also see: search reasults)

I hope that there is somebody out there who understands my problem and finds my mistake(s). My further plan is to integrate these target temperatures into HomeKit - but first things first.


ETS SollTemp 2 ETS SollTemp 3


Type number   : BueroTemperaturSollAkt    [ ga="9.001:2/2/1" ]


Group:Number:Temperature:AVG   Grp_Temperatur_EG_SOLL_Akt "Temperatur Soll Aktuell [%.1f °C]"  <temperature>

Number:Temperature  BueroTemperaturSollAkt  "Büro Temperatur Soll Aktuell [%.1f °C]"    <temperature>  ( Grp_Temperatur_EG_SOLL_Akt ) { channel="knx:device:bridge:generic:BueroTemperaturSollAkt" }


Group item=Grp_Temperatur_EG_SOLL_Akt	label="Temperatur SOLL" {
	Setpoint	item=BueroTemperaturSollAkt label="Büro Soll [%.1f °C]" minValue=18 maxValue=24 step=0.5

Sitemap SollTemp

The correct Target Temperature is in the sitepmap. When I click on the arrows, there is no change and in the log comes:

2021-02-11 17:36:23.746 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'BueroTemperaturSollAkt' received command 22.5 °C
2021-02-11 17:36:23.757 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'BueroTemperaturSollAkt' predicted to become 22.0 °C

In the ETC Diagnosis is no appearance of a change of the target Temperature.

If you need more information, please let me know.

This is a number type channel. You shouldn’t freely link it to Number:Temperature type Items,unless the binding supports units (so far as I know,it doesn’t yet.).

Thanks for your answer.
The actual temperature for example and the groups are defined like this to work Fine.
So I think That isn‘t the Solution.

Please yourself.

is not the same as
received command 22.5

Now I got your point. Thanks!
Tested it
Logfile after click on Up-Arrow:

2021-02-12 08:52:02.804 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'BueroTemperaturSollAkt' received command 22.5
2021-02-12 08:52:02.820 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'BueroTemperaturSollAkt' predicted to become 22.0

In ETS Diagnosis there is a grey line with the new target temperature.


  • in the sitemap: no change of the Setpoint item.
  • more clicks on Up-Arrow make no changes on the setpoint item. And the ETS receives only 22.5 with every click.

I guess that means it sends to

There’s still something amiss here, with the mis-matched prediction.
It’s the kind of effect you get from a broken channel - yet we are sending stuff ok.
Do you need to add an address to your KNX channel here, to read the setting back from the device?

Yes, the Item state hasn’t changed from 22.0 so every "more"click is 22.5

Your reply assuming there is something missing in the channel made me curious. So I tried the following line:


Type number         : BueroTemperaturSollAkt    [ ga="9.001:2/2/1+<2/2/0" ]

Remember: in ETS: 2/2/0 was the “Sollwert Komfort”.
Result: Same behaviour:

  • no change of 22.0 in setpoint item in Sitemap.
  • a click on the arrows results in on step up/down to 21.5 or 22.5.
  • Sending one of these Values to ETS.
  • When I click very fast, I can change the target temperature to even 20.5 which is also coming to the ETS.

Now I am a bit lost.

Do I have to use the other possibilities for changing the temperature - in ETS it is called “Sollwertverschiebung über 1 Byte/2Byte”. In this case I need help for things, items, sitemap-code.

I guess that you refer to the MDT heating actors? I use the same actors and when I remember right, I’ve tried to do in the same way than you with having your troubles as well. My impression was, that the “Sollwert Komfort” communication object is there, but there is not much of a documentation or how to use it.

So I went using the suggested standard way in the documentation and only set the HVAC mode via communication object 10 (Betriebsartvorwahl, DPT HVAC Mode 20.102). I’ve added a heating schedule that will change the HVAC mode throughout the day (Comfort, Standby, Economy, Building Protection).

Also I use the nominal temperature value shift using the communication object 8 (manuelle Sollwertverschiebung) as a 2 byte value if my flatmates feeling too warm or too cold.

To have that nicely packaged within a custom widget, I started here:

And got a lot of examples from other people doing the same.

I’m interested if you still get the mis-matched prediction logged, that is meaningful. Meaning there’s something wrong with Item<->channel link(s).
Did you change the existing Item type? I worry this has left a lasting problem. . It might go away after reboot, if not I would then try deleting the link, and re-making.

But it sounds like you may be off on a different approach anyway.

Sorry, forgot that in my post: it´s the same as before:

2021-02-12 13:13:23.862 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'BueroTemperaturSollAkt' received command 22.5
2021-02-12 13:13:23.878 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'BueroTemperaturSollAkt' predicted to become 22.0

item changed as you mentioned:

Number  BueroTemperaturSollAkt  "Büro Temperatur Soll Aktuell [%.1f °C]"    <temperature>  ( Grp_Temperatur_EG_SOLL_Akt ) { channel="knx:device:bridge:generic:BueroTemperaturSollAkt" }

That was another approach I tried - I just had the 3 States (comf, night, frost) to reach a specific state with the right bits are set. That was a rule which did that. The idea is good, but the daily schedule is on onehand easy to code, but it is a very very long rule (did not get it into arrays or something like that). (If there would be a UI to change it by fingertip in sitemap, that would be a pro-tool (days and hours in a diagram)). Also I could not change the temperatures. Maybe I give it another try with CO 10. The other question is, if I can change it in Homekit.App - that is the big target.

That is what I am looking for. How did you solve it in code and what is the setup in the actuator? (MDT)

It’s “interesting” :crazy_face:
I wonder if a ghost link is left over from the edit/change. Using xxx.items files should remove and re-create link, but this could go wrong. I’ve no idea if links themselves have a type, wondering if you might have a link of each type, but seems unlikely.

I think for an experiment I would create an entirely new Item of different name, which you may link to the same KNX channel, and see what that does.

@Friedo Did you solve it in the meantime?
I’m using the MDT actor as well and for me the hint with the unsupoorted type Number:Temperature by @rossko57 worked.

This didn’t work:

Number:Temperature  BueroTemperaturSollAkt [ ga="2/2/0+<2/2/1" ]

This works:

Number  BueroTemperaturSollAkt [ ga="2/2/0+<2/2/1" ]

Thanks for your answer. I already changed to your choice. But no effect on that, too.

Heating saison is starting - and now I’ve got the same problem with knx actor.
This is my channel definition:

  - id: soll_temp_komfort
    channelTypeUID: knx:number
    label: Sollwertvorgabe
    description: ""
      ga: 9.001:0/2/1

this is the connected item

changing the value in ETS works and is displayed in oh-item-state.
changing the value in OH does not update the knx-device in ETS.

What is the recommended way to deal with knx temperatures in OH3?

Yes, you do. You have a Number:Temperature type Item and it isn’t going to work with current KNX binding.

Even after changing the number type there is no reaction on knx.
Nothing in knx-log neither in frontail nor in ETS.

Because it is an edit, you’ll probably have to restart the binding to get channel link sorted out.

I created a new item

connected to this thing-channel

connected to this ETS-group-address

updates in knx are displayed in the openhab item - so the connection seems to work.
But updates of the oh-item are visible in the tailwind-log

but they do not reach the group monitor in ETS.

If enabling loglevel of calimero to DEBUG there’s no outgoing message, too.

(I restarted openhab - is this enough - or what do you mean with “restart the binding”?)

Okay, good. Reboot will do to be sure the binding has implemented thing edits.

Nor should they. Being pedantic, but it is the OH command that should get passed out to KNX. The distinction can be important.

I note previous posters use two ga, but that is the end of my KNX knowledge.