Did max zwave wakeup interval change?

Why won’t it let me change the wakeup interval to be more than 3600 seconds? Did something change recently? I’m on build 2793.

@chris Any idea what’s going on.

Edit: Ok, so this only seems to be happening on the Aeon ZW100. So there must be something specific to this device that limits the wakeup interval to 3600 seconds.

Edit 2: But I can’t find where this limit is defined.

The binding uses the value returned by the device to set the min/max values. Maybe something changed in your configuration and this got screwed up - you could try changing it in the XML file for the device, which should be what the binding uses to set the value (make sure the binding isn’t running before changing the XML though).

Ah, yes, now I see it in the node.xml file. I should’ve thought to look there. Maybe I should leave it alone if the device thinks that’s the max.

I also saw some other weirdness with the polling interval. After an openHAB restart, all my devices initialized to poll every 1800 seconds (which I believe is the default). When I looked in the UI, it showed the polling interval was 86400. But when I looked in the jsondb, there wasn’t a “binding_pollperiod” config parameter. So I tweaked all the devices (incremented by 1 to 86401 seconds) and there’s now an entry in the jsondb for all the devices, and after a restart they now are initializing with the expected polling interval.

I wonder if this is a side-effect of the recent changes to config validation? Otherwise, I have no plausible explanation for the behavior.

I guess so, but I’m not really sure why the polling would have changed. What did you have it set to previously? Was it out of range (although max is set to 10 days, so I’d be surprised)?

I had it set to whatever the default is when you accept the thing from the inbox. I assume that’s 86400, but I don’t recall for sure. I’m not really sure how long the parameter has been missing from the jsondb. I only noticed it today when I was looking at the logs and saw all the polling activity.

I have a few backups that I can look at.

I looked at a backup from 2 weeks ago.

I have a total of 24 nodes in this network.

Three of the nodes I must’ve explicitly changed the poll period because these are the only 3 occurrences of binding_pollperiod in the jsondb.

org.openhab.core.thing.Thing.json:          "binding_pollperiod": 43200,
org.openhab.core.thing.Thing.json:          "binding_pollperiod": 86401,
org.openhab.core.thing.Thing.json:          "binding_pollperiod": 14400,

The remaining 21 nodes have no binding_pollperiod parameter.

I have some older backups, but those were from before I added any zwave nodes. So I guess it’s inconclusive whether there ever were poll periods set for those other nodes.

I’ll be adding some more nodes to this network, but it won’t be for at least a few more weeks (it’s at another house). Now that I know what to look for, I can check whether the poll period is being set when a new node is added.

Ok, even though I’m not at that house at the moment, I can VPN in.

So, I deleted one of the nodes, then ran a scan to rediscover it. I added it from the inbox and can confirm that it was added without a binding_pollperiod config parameter.

      "configuration": {
        "properties": {
          "config_7_1": -1,
          "group_1": [
            "controller"
          ],
          "node_id": 19,
          "switchall_mode": 255
        }
      },

Based on that I believe there’s definitely something wrong.

Edit: Well that is assuming that that parameter SHOULD be added when the node is accepted from the inbox. I’m making the assumption that it should be added, but I don’t know for sure.

I’m not sure that it will be added to the json unless you save it - although I’m not 100% sure of that as this is not handled by the binding - it’s all core code.

Yeah, I’m not sure either. But it’s definitely confusing. After adding the thing from the inbox, when you look at it in the UI it shows a polling period of 86400. But since there’s no parameter in the jsondb, the binding defaults to 1800.

The same might be true for the command repoll period, but I haven’t looked at what the UI shows versus what the binding defaults to.

Ok, that’s clearer to me - the default in the binding is not the same as the default in the configuration. I can easily change this.

Is it? But doesn’t the binding add properties to the discovery result? And, if so, is the pollperiod one of the properties it adds to the discovery result?

Or does that happen later as part of initialization…

Yes, but it doesn’t systematically go through and set all configuration. It sets a few things like the node ID - everything else is just in the config description, and unless it’s written to jsondb, it won’t be there.

Yes, but what will you change it to? :wink:

I would vote for 86400. :smile:

I will ensure that the two things are the same - ie the binding uses the default from the config description.

1 Like

I saw the PR. :+1:

This is what is set in the config description, so this will be the value.

Looks like the command repoll is ok. The UI shows 1500 and that’s what the binding uses as a default.

Thanks for the quick fix. :clap:

But I do wonder why it doesn’t get written to the jsondb if it’s in the config description.

BTW, the default poll period in the 2.5 version of the binding was 86400. So, somewhere along the line it got changed to 1800.