Sending configuration values when already set

Trying to send a config value from REST API. Works fine when I am changing the config value.
If the value is already set to what I want (I just want to send it again) the system ignores it.
Is there any way to force the system to send it again?
This is what I get in the log stating that it has been ignored:
2019-11-12 21:10:10.781 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Configuration update received 2019-11-12 21:10:10.783 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Configuration update ignored config_2_1 to 0 (BigDecimal)
(P.S - Sorry I cant seem to assign this question to the zwave tag. It keeps saying internal server error)

I set the Z-Wave tag for you. Sorry I do not have the answer though.

Ok thanks Bruce.
Hoping somebody does! :slight_smile:

Chris is away on vacation in Japan until the middle of next week but tagging as Z-Wave alerts some other knowledgeable users too.

No - there’s not.

Originally, when I wrote the binding, it always sent config values that were sent to the binding to the device, and HABmin only sent updates to the binding that had been changed by the user. However then PaperUI came along, and it always sends ALL configuration data to the binding which causes problems on some devices, and can cause a lot of network congestion on devices with a lot of configuration. So, I had to add this check to prevent resetting some devices.

Unfortunately the only option is to configure it to something else, and then configure it back. Personally I don’t like this, and I think my original implementation is much better, but given the problems this causes and openHABs policy with sending all configuration, I don’t see any option.

1 Like

Hi Chris,
Thanks for the reply!
Yes I’ve currently used that method which produces random results but achieves what I want in the end.
Is the binding able to detect where the configuration request came from?
Just wondering if it would be possible (in the future) to allow this function through the REST API, but not through HABmin or paperUI. That is, of course, if they don’t use the REST API to update the configuration!

Thanks

No - it just gets a single call - it has no information about where it came from.

Anything is possible, but it still requires support from PaperUI and when I discussed this a couple of years ago the theory was that openHAB wanted to always send all the data. At that time, the concept was that this was only meant to be used for configuring openHAB - not for configuring devices, and there would be a new interface provided to configure devices…

Well, time marches on, and things have changed, and there’s still no such interface.

Just a bit more flavour around the problem with not managing it the way I do…

Some devices (most Aeon devices for example) have a config parameter that when set to a specific value will reset the device. If this ever gets set, then the configuration is saved, and then the next time any configuration is updated the device is reset again since the config value is stored in openHAB, and PaperUI will send all configuration parameters again.

Thanks for the info!
I was wanting this for a lock I have on my front door.
You can set a config parameter to stop it from auto locking, but if you pull up the handle the lock goes back into autolocking mode and doesnt update OH.
If I want to put the lock back into autolocking mode, I need to send the config parameter again.

The lock does send back data on whether the handle is pulled up etc but this doesnt resolve to a mapped switch/number or anything. Is there a way to read this extra data in a rule?
I had asked this in another post here which includes a little more info:

P.S, hope your enjoying your time in Japan!

No - not at the moment. We could probably add a channel for this information though (I have the same lock here). I’ll take a look at your other message…

Unfortunately “enjoying” is now “enjoyed” as I arrived home last night :frowning: . It was however a really good time - 2 weeks of near continuous blue skies and mostly warm weather other than up in the mountains. I’d recommend it.

1 Like