I believe the systemwide default wakeup period is 3600 for the controller. Usually that is adjusted when the controller is added.
I also thought it was known that the device polling period was not being set in JSON. I’m not sure I can find the thread at this point. I make it a point to tweak the 86400 by deleting and then adding a zero to get it into JSON. “Edited” it is the polling period not persisted, not the wakeup. Two different things.
Bob
Correct. And it’s really not an issue if the polling period is not persisted in the jsondb as long as what’s shown in the UI matches what the binding uses as the default.
It was really a bit of a revelation for me today when I couldn’t understand why there was so much traffic on a small 25 node network when I thought the polling period was 24 hours. 
I have the zniffer set-up periodically monitor traffic.
I could be wrong, but unless the battery device wakes up more frequent polls will not be sent, it will take both the wakeup and the poll to be at a short intervals.
Anyway glad it is sorted for you 
.
Bob
Yes, that’s correct. But most of my nodes right now are mains powered, so they all were getting polled every 30 minutes. Definitely not what I wanted… 
Nope - it was “always” been the same. At least 2.5 is set to 1800 and this code hasn’t changed for a long long time. Possibly the way the core handled configuration may have changed - I’m not sure.
It’s only possible to communicate with a battery device when it is awake. This includes polling - until the device wakes up, the poll requests will just be queued. If there are multiple polls between wakeups, then there will still only be 1 poll sent.
I was pretty sure myself, but hedged since I saw you in the chain I also suspected that only one poll was sent, but thanks for the confirmation.
Bob
I’m still confused about this. And I apologize if I’m misunderstanding something. I’m not too familiar with config description providers as I’ve never used them in any of the bindings I wrote.
In the config description provider here the binding creates the poll period parameter with a default of “86400”. In the past (before the config validation changes in core) wouldn’t this parameter have been persisted in jsondb when the thing was created? (Edit: And this might explain why I thought it was being defaulted to 86400 in the past).
And, now, since the parameter is defined as an INTEGER, won’t the config validation fail because the default value (as well as the options) are being passed in as strings?
And, would this not explain why wakeup_interval is being persisted (not using strings) and binding_pollperiod and binding_cmdrepollperiod are not being persisted (both are using strings)?
It is exactly the same as the config descriptions defined in the XML - the core is just providing a config description provider in the same way as the binding.
Not as far as I know. Configuration is only persisted if you save the configuration through the UI - or explicitly by the binding. Why do you think this would otherwise be saved?
It is ONLY possible to provide this as a String. In the same way as data is provided from the UI, via the REST interface as Strings, it is also provided here as a String.
/**
* Set the default value of the configuration parameter
*
* @param defaultValue the default value of the configuration parameter
* @return the updated builder instance
*/
public ConfigDescriptionParameterBuilder withDefault(String defaultValue)
Wakeup interval is specifically persisted - as are other device parameters if they are received from the device. It has nothing to do with the config description provider.
Thanks for the clarification. I’m just trying to understand what I perceive as a change in behavior, the source of which I can’t explain.
Until now. Please bear with me as I try to explain…
So, this whole thing started when I couldn’t understand why all my devices were being polled every 1800 seconds when the UI was showing 86400 seconds for all those devices.
I originally had speculated (maybe hypothesized is a better word 
) that the cause had something to do with when the node thing was added from the inbox. But, with your explanation above, I realize that wasn’t it. Thanks for clearing that up because it made me look elsewhere.
When you add a node from the inbox, as you point out above, the pollperiod config parameter is not persisted in the jsondb. This behavior is consistent between 2.5 and 3.x.
Normally, when I add a new node, it’s common for me to immediately change the label of the thing to something more descriptive of the node’s function. In 2.5, when you save the thing config, even if it’s just a simple change to the thing label, the pollperiod parameter is persisted to the jsondb using the value that’s shown in the UI (86400). In effect, this changes the polling period from what was the binding default of 1800 seconds to 86400 seconds.
I guess I had grown accustomed to this “side effect”. 
Because, in 3.x, when you change the name of the thing, the pollperiod is not persisted to the jsondb. Only when you explicitly change the poll period will it be persisted.
Your PR from yesterday resolves the issue, since now the binding will use the same pollperiod that’s shown in the UI.
I knew something was different. I just was a matter of getting to the bottom of it. I feel much better now that I understand the issue. Thanks for your patience while I sorted it out.
I think there was a change in the UI a while ago that stopped sending configuration (and therefore persisting it) if it was set to the default value. At least I recall having a discussion around this a few months back - I’m not completely sure it was implemented, although from what you’re saying it does sound likely.
Yep, I’ll bet that’s it.