Yeah… I wasn’t sure if I deleted them or if that functionality was added into the binding. I know it was discussed in a PR, but thought the decision was to not include it. I figure I deleted them while testing after the merge, and hadn’t fiddled to get them back until now.
Ruh-roh. Initialization is getting stuck. Looking at the logs now.
Getting stuck on the WAKE_UP_INTERVAL_GET, which I know the device doesn’t support. I wonder if sonething changed in the DB.
@chris See two previous posts. If getSupported=false, why would the binding be sending a WAKE_UP_INTERVAL_GET on the WAKE_UP command class?
I don’t think this is the correct thing to put in the database. I think it’s meant to be NOGET - I’ll check.
The db has…
Is the ccAdd necessary? ie does this device report this in the NIF? If not, that’s probably the issue - when the getSupported is set, it probably doesn’t have the command class set yet, so it doesn’t set the option.
IIRC, it doesn’t announce the WAKE_UP CC in the NIF.
There’s a discussion somewhere where we decided to add ccAdd back into the DB. I’ll look for it.
Not in NIF…
Ok, then I think this is likely the problem…
Here’s the start of the discussion…
Unfortunately at the moment cloudbees seems to be down and has been all day, so I can’t rebuild…
1 Like
Thank you, Chris! This seems to have fixed it.
Thanks - did you delete and start again - just to be sure? I suspect that the reason it might have worked previously is if things are run a couple of times, then we could get the CC added and saved into an XML, then on another start, it could then successfully set the no-get option…
I’d just like to be sure it starts from fresh?
Thanks.
Chris
Things and xmls were deleted, discovered, devices not recognized, after a wakeup the devices were recognized. I think it was clean, but I’ll try it again later today.
1 Like
I just included a Minimote after doing a factory reset. It was discovered and initialized just fine.
The other issue I had (command repoll) is working too.
Thanks!
1 Like
It seems that the development version has issues with qubino shutters feedback.
Opposed to the stable version the dev version does not correctly update the thing once it’s complete. In the logs I see messages like “pretending to go up/down” and like 2 secs later it’s changing shutter value by about the value of ‘3’.
So it changes from 100 to 97 when going down or it changes from 0 to 3 when going up. But it does not change to 0/100 when it’s finished going up/down. The stable version did not have this ‘pretending’ message and early updating.
Interestingly after 30 minutes (polling time) the status get’s updated to the correct value so sequence of events is:
- receive command for example down
- logs says zwave is pretending to go down
- logs says changing value from 100 to 97
- wait for polling…
- logs says changing value from 97 to 0
Is this a bug in the binding (as stable works) or a matter of settings on the qubino shutter?
Please provide the actual logs so we can see the actual messages- I don’t know what these messages are.
Also, please ensure that you exclude and re-include the devices so that it is reinitialised.