KNX-Binding not changing Target-Temperature in ETS

Tags: #<Tag:0x00007fc8fc112f98> #<Tag:0x00007fc8fc112de0>

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:


ETS SollTemp 2 ETS SollTemp 3

KNX.things

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

KNX.items

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" }

Home.sitemap

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.

BUT:

  • 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 KNX.now.

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:

KNX.things:

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.