[KM200] Buderus-Binding - Changing item state works via REST-API (curl) (= "change from ... to ...") but not via Sitemap (Setpoint) (= "received command ...")

Add-ons Bindings
1

Hello,
I am on OH 2.5 - Milestone 1 and I like to alter the value of the “Sommer-/Winter Schwelle” (Summer-/Winter Threshold).

I can change the item state via the REST-API web interface:

image
image.png1286×1308 87.4 KB

Here is the log output from the REST-API procedure:

21:14:41.159 [INFO ] [smarthome.event.ItemStateChangedEvent] - istBudSoWi changed from 19.0 to 20.0

But it fails when I try to alter it through the sitemap:

      Setpoint item=istBudSoWi minValue=17.0 maxValue=20.0 step=1.0 label="Sommer-/Winter Schwelle [%.1f °C]" icon="temperature"

When I use the arrows to change the value it shortly changes the webview but then falls back to the previous value:

image
image.png1056×152 4.63 KB

Here is the log output of the Setpoint procedure:

21:12:09.113 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'istBudSoWi' received command 20
21:12:09.115 [INFO ] [smarthome.event.ItemStateChangedEvent] - istBudSoWi changed from 19.0 to 20
21:12:09.809 [INFO ] [smarthome.event.ItemStateChangedEvent] - istBudSoWi changed from 20 to 19.0

It seems that Setpoint works with "received command 20" and the REST-APIworks with "changed from 19.0 to 20.0"

What is the appropriate way to manipulate an item state with “change from … to …” instead of “receive command …” ???

Thank you for any advice or guidance!

Cheers
Justus

2

What, if anything, is this Item linked to? What is the Item definition?

It is important to note that in the REST example you are updating the Item. This changes the state of the Item but only internally to OH. When you command an Item, the Item may not change state depending on what it is set to. Commands are used to go out to the device and ask it to do something. I looks like the device is ignoring the command and reverting back to the old state and telling OH that it did so.

3

Sorry that I missed to pass this information. It is a simple number definition linked to one of the channels of the KM200 binding …

Number	istBudSoWi			"Sommer-Winter Schwelle [%.1f °C]"  	(gHeating) 	{km200="service:/heatingCircuits/hc1/suWiThreshold"}

And in the initialization of the binding you see that this channel is “writeable” (corresponding line of the log output of the binding initialization:

1;1;0;0;floatValue;/heatingCircuits/hc1/suWiThreshold;17.0;;9.0;31.0

1;1;0;0; means:

readable=1 means readable = yes
writeable=1 means writeable = yes
recordable=0 means recordable = no
virtual=1 means virtual = no

Important is in my case the second digit as it confirms that this channel is writeable, meaning that it can be changed.

Ah ok, this means that I change the state in OH only but it does not get really passed to the device.

Is that then an issue of the binding? Because there are other channels that accept changes via the command path.
Is there someone I can ask to check if the binding behaves correctly?

4

Anything beyond this looks like it will be dealing with the binding. Put the binding in debug or trace logging and see if something comes up. It looks like you issue the command, the Item changes state (because autoupdate=true which is the default), and then the device says “no” and changes the state back.

I know nothing of this binding so will be of no further help.

5

Thanks for your advice. It late evening over here. I will set the debug level tomorrow and start collecting the data and looking into it.

6

Just putting @Markinus into the loop, he´s the author of the binding.

From what I understand it can take a while until the heating accepts the data sent to the interface.
So it may be that in the meantime the item will still be fed with the old value.
Setting values in my experience is not working 100%, some items work, some do not.
Tried multiple time, but got no pattern out of it.
I currently only read values as this is enough to feed my graphs.

7

I think the nomenclature of the channel definition in the binding is confusing as the second digit claims that this channel is writeable meaning to me that it can be changed via OpenHAB.
I did some testing and now it seems to me that the channels with the third digit = recordable set to “1” allow writeable access to the channel. So I am wondering what writeable flag stands for … :thinking: ?

It would be very helpful if @Markinus would be able to bring some light into this, whether the writeable (second) flag is configuring the channel to accept changes or if my observation is correct that only the channels flagged recordable are accepting changes.

During my tests I did not see that any channel with the writeable flag was able to accept any changes. Even not with some delay. It never accepted my change. The recordable flagged channels accept changes immediately with no delay and very reliably!

Before I decided for OpenHAB I have also studied the functionality of the integration of the KM200 in FHEM. And in FHEM the users are even creating time and day schedule strings and pass them to the binding to configure the individual heating programs leveraging the channels flagged as writeable.

So, please @Markinus share your knowledge and explain the confusing behaviour. THANK YOU !!!

Cheers
Justus

8

Hello Justus,
Has your problem ever been solved?
I have the same challenge. Would be great if you could share your solution.

9

No, unfortunately not as the attribute of an channel being writeable or not ist given by Buderus and defined through the binding. If you set the log level for the KM200 binding to DEBUG then you will get the list of all channels that are accesible by the binding and the available attributes. And unfortunately the suwiThreshold is not writeable :frowning:
Only Buderus could fix this and they most likely won’t as they would need to update the gateway firmware which we all do not want as they then might possible close the backdoor that we are all using to access it :wink:

Sorry that I can’t provide you a better answer …