I have the above device and believe it is working properly however on startup in Debug I get the following about an unknown command class:
The Habmin attributes are;
Is this cause for concern? I’m on Zwave binding 2.5.2
I suspect posting the generated xml file could help too.
My guess is this is a log display issue, but it’s hard to tell without seeing a log file.
Well I’m out of my depth. Are you looking for the log file unprocessed by the Zwave log viewer or something else?
The only thing I found (with my very limited knowledge) is that in CT101 Device database has a Multi_Instance class in the Endpoint 0 section and it seems from the log it is looking for it in the Endpoint 1 area. I do not know if that is a problem.
The answer is in the official documentation for “when things don’t go as planned”
The extract above was produced with zwave in Debug mode as per the docs. However, I did filter the results to the node in question. The reason I thought this was okay was I did this on start-up and was actually looking for something else to happen (long story) and the file was over the max. I cut some of the start-up stuff and here is the unprocessed log file. Both node 30 and 31 are CT101’s.
openhab.log (880.7 KB)
Chris has said many times filtered logs are useless for troubleshooting.
I think that this is the standard issue with the CT101. This device is not ZWave compliant and has a major bug.
1 Like
Ok. Thanks for looking at it.
1 Like
To wrap this up-
First the GitHub issue you posted does seem the same as I was getting. Second, the devices seem to work anyway and have for several months until I stumbled across this issue on a DEBUG start-up (I was looking for something else). Lastly, I contacted the company about non-compliance and they responded:
So there does seem a difference of opinion between GitHub and the Z-wave Alliance positions on compliance. Don’t do any work on this for me (as I know you are very busy). They work fine for me as is. Just wanted you to know and others that may come across this posting.
Again thanks.
No - this was confirmed by the ZWA. Unfortunately the site where this was confirmed (which is linked from the Github site) has been taken down since Silabs took over ZWave.
There are newer versions of the CT101 which are certified, but the version that you have with this bug, while it may be certified, is non-compliant to the requirements (so it does beg the question as to how ZWave are certifying devices).
To be clear - you have version 9.0, while the certified version on the Alliance site is for 9.7.
1 Like
Great answer. It was supported with a patch in 2, an upgrade killed that. 2.4 supported everything but humidity, but in 2.5 you are SOL. Every upgrade is a PITA because of new code, what worked does not and “to be clear” the alliance site is good enough when you want it to be an excuse for letting your customers down
Chris is migrating from reverse engineered standards to the actual specification. He is a talented programmer and engineer working in the space industry. Just because somebody makes a cr*p device does not mean you need to disrespect the great binding work here.
If you really want to see a mess try any of the solutions based off openzwave. From personal experience, I can say they are a disaster.
Yeah it goes well beyond. Every upgrade seems a disaster 2 -> 2.4, 2.4 -> 2.5.
Old devices that used to work but don’t anymore is just icing on the cake
There were HUGE OH architectural changes from 2.4 to 2.5
Other than the device database and possibly adding support for additional classes I do not think there were any major binding changes.
OH 3 will be another huge architectural change and, I think, require Java 11.
There has been very little change in recent versions so this should not be the case at all.
The CT101 version that is fault has a major bug that makes it very non-compliant. It’s a total bodge to fix it in the binding and people were recommended to return them to the manufacturer.
I know that the manufacturer then sold them super cheap, but then why expect them to work 
Like what devices? Generally speaking, all older devices should work just fine.
1 Like
Chris - My point about the three ct101s that used to work was through a patch - it then worked 100%. The 2.3? version revamped the binding so that the patch didn’t work, but it worked again in 2.4 sans humidity. 2.5 showed it immediately not working and so I found this post - which simply dismisses my thermostats as POS.
I get it, you are not paid for this, and I’m not going to ask for any support given your dismissal. I will re-image the OS and rebuild the current disaster of an upgrade as seen in the screenshot above. Upgrade costs: 3 thermostats & 2 days and counting…
Was it Chris’ patch? If not, your gripe is with the patch developer for not updating it.