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.
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.).
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”
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.