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.
Hi @chris, afer upgrading openhab all my switches (TKB home TZ65D) appear in the INBOX with wrong type - as TZ35S.
I have three kinds of TKB Home devices - TZ65D,TZ65S,TZ66D. Before updating openhab their type was correctly determined by openhab. But now all of this devices was appeared as TZ35S in inbox.
What is the difference between these devices? Often manufacturers use the same IDs for multiple devices.
If the devices are different, then we need to resolve this so that the correct channels are provided. If they are actually different versions of the same device, then I’m not sure that it matters?
I would suggest if this is really a problem to start a new thread so that the conversation is not hidden here as we’ll need to find other users of these devices to try and sort out the different versions.
Main difference is count of association groups:
TZ65S (as TZ35S) has group 1
whereas TZ65D has 3 association groups
Hi @chris, my tkb home devices still appeared as TZ35S.
I think my trouble related to TZ35S reporting as TZ65D
I also have a device ID 0808:0808
ii openhab2 2.5.0~S1608-1 all openhab2
ii openhab2-addons 2.5.0~S1608-1 all openhab2-addons
I can’t set addition channels.
Yes, this was my point earlier and why we need to look at the differences between these two devices.
Sorry - I’ve just realised this is a repeat conversation of another thread - it’s best not to cross-post so I won’t continue replying here.
Where can I download the latest 2.5-SNAPSHOT build of the zwave binding?
I need to pick up the latest device xml files.
If you want the XML files, it’s it best and certainly easiest, to get them from Github?
That works. Wasn’t sure if there were code changes that go with the XML changes