Got it, will do. Thank you Chris.
I checked and it appears there’s no option to update firmware for the CT101. (Someone please prove me wrong…) In the meantime it looks like others have had success with a workaround. See here: https://github.com/OpenZWave/open-zwave/issues/1179
Got the same issue. CT101 would not be recognised. But a full node xml file was created.
I have a slightly different type iD though:
Type:ID = 6501:000D
I have submitted a ticket to have it implemented in the database.
paillo can you post a link to the ticket you submitted?
chris - any chance of convincing you to consider implementing a workaround? This is worth Real Money as the CT101 IRIS thermostats are half price compared to the CT100s. I can still return the one I bought as an experiment, and I need two thermostats in total. Therefore the savings to me would be about 2x$50 if these ones worked. Do you take donations/bounties for development work?
Hi jschmidt,
The ticket was only to be able to update the database. The database is now updated with the node.xml file I got from openhab2.
I tried the z-wave binding build from the 08/10 but it doesn’t seem to have been implemented yet.
The version I have has got a slightly different type id though. It might be an update with the corrected firmware. It would be good to give it a try though.
This isn’t something I was planning to “fix” in the binding as it’s really very specific to this device, and not something I would expect to find in any other device (or in fact any device that has been certification tested). I know this isn’t “nice”, but what I want to avoid is adding hacks to the binding that compromise the code, or impact other devices.
I could potentially be persuaded to look more at this if you fancied making a donation to the beer fund 
.
1 Like
Hey Chris, that’s exactly what I was suggesting. I have two options right now:
- Return the one CT101 I bought and buy two CT100’s (or other zwave thermostat).
- Get the CT101 working in OH2 and buy a second one.
Option #1 differs from #2 by $100, which I am totally willing to offer up as a donation. I’m not sure how that amount compares to the work that might be involved. I am also concerned about the potential impact to the binding or impacting other devices.
I have until Oct 20th to return the CT101. What would you say if I sent you a small amount to have a look at what might be involved, and then let me know (before the 20th ideally) if you want to proceed or abandon the effort.
… Or maybe if Radio Thermostat has corrected the firmware then I should just return mine and see if I can get one of those. Paillo, where did you purchase yours from? I got mine from Amazon com.
Thanks!
i also just purchased this thermostat off Amazon.ca for the same reasons and would appreciate it being implemented in the binding. How much beer are we looking at to get it done?
I purchased mine from Amazon, it is the radio thermostat version not the iris version.
The fact that it created a node xml file is an improvement from the previous firmware version and give some hope to have it working with openhab2.
But I don’t know anything about the z wave binding.
If it generated the XML, then I would say it is probably updated firmware… I guess the obvious question is “does it work”? .
Unfortunately we are talking about two different products. I’m not sure if I can paste links to Amazon listings in this forum, but mine is the CT101 “IRIS” version ($50), and I think paillo’s is the original CT101 ($100). Maybe it’s enough to get the node XML file into the database to get his working, but I still have the same issue with the non-standards compliant zwave firmware in the IRIS variant (detailed earlier in this thread). Enabling the OH community at large to be able to purchase the half price thermostats is worth a look 
When I did network inclusion OH2 found the new thing and added it into the list, however since then it (~24Hrs) it only shows up as “Controller Offline”.
On the CT101 it shows that it is connected to the network (Tower with Link below and “1” beside tower). So not sure why the thermostat and my newly installed light switch wont show up normally like my other 2 sensors and outlet do…
I tried re-adding it into the network last night as well but remained offline like the first time.
Mine is a Radio Thermostat but in the manual it says “…has built in zwave radio…to communicate with the Iris* System…” and it did show up in OH2 with ID’s and all that just wont allow status and control, almost like it didn’t quite complete the recognition process even though it recognises it as a thermostat class thing,…
I have tried with the snapshot binding from the 10/10 and the device is properly recognised. All the channels are available.
I have not tested all the functionalities but I can read the temperature, humidity, set the target temp, thermostat mode, fan mode. So looking really good so far!
Type:ID = 6501:000D is good to go!
Thanks
1 Like
I’m going to take a chance and post an Amazon link, hoping that’s not against the forum rules. This is the IRIS version of the CT101 that I bought: https://www.amazon.com/gp/product/B01MZG4TX7/
The biggest advantage is that it’s cheap! The biggest disadvantage is that it doesn’t implement zwave correctly… Anyway, I’m glad that paillo has his CT101 working now but I’m still wondering if I should return mine and buy the standard CT101 for 2x the price. Chris, please let me know if you’re up for some hacking
@paillo, where you downloaded the build?
I have the same issue and I hope it will solve it for me too.
Thanks
@alfredosc8, I downloaded the last build from the openhab2 repo:
https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastStableBuild/org.openhab.binding%24org.openhab.binding.zwave/
I take it that’s a “no” for attempting the workaround. No worries, I will return the CT101-IRIS to Amazon and order the “regular” CT101 instead. It’s too bad about the buggy firmware. The HA community deserves a cheap zwave thermostat
I decided to take a stab at it myself, and appear to have achieved some level of success! I got the temperature reading at least. More testing WIP. Here’s the patch so far:
--- a/src/main/java/org/openhab/binding/zwave/internal/protocol/commandclass/ZWaveMultiInstanceCommandClass.java
+++ b/src/main/java/org/openhab/binding/zwave/internal/protocol/commandclass/ZWaveMultiInstanceCommandClass.java
@@ -210,8 +210,19 @@ public class ZWaveMultiInstanceCommandClass extends ZWaveCommandClass {
CommandClass commandClass = CommandClass.getCommandClass(commandClassCode);
if (commandClass == null) {
- logger.debug(String.format("NODE %d: Unsupported command class 0x%02x", getNode().getNodeId(),
- commandClassCode));
+ if (this.getNode().getManufacturer() == 0x98 && this.getNode().getDeviceType() == 0x6501
+ && this.getNode().getDeviceId() == 0xc) {
+ logger.debug(String.format(
+ "NODE %d: DEVICE BUG WORKAROUND, handling MULTI_INSTANCE message as MULTI_CHANNEL",
+ getNode().getNodeId()));
+ handleMultiChannelEncapResponse(serialMessage, offset);
+ } else {
+ logger.debug(String.format("NODE %d: Unsupported command class 0x%02x", getNode().getNodeId(),
+ commandClassCode));
+ }
return;
}
edit: removed useless debug print from patch
Nice one. I don’t think it’s too hard to make this work - it’s harder to do it nicely in a way that isn’t a hack and that’s what I would like to avoid in the master binding.
1 Like