Radio Thermostat CT101 Question

“this completely broken and non-standard, non-compliant device”

…oh, well, when you put it that way. It makes me wonder how it worked close to perfect in 2.4 being so broken, non-standard and non compliant. Seems like it might must have checked one or two of those boxes. But I get it and expect nothing here

Sorry, but the device is absolutely non-standard and non-compliant. This was confirmed by Sigma a few years back. That doesn’t mean that it can’t be made to work - clearly it can, but it’s a really nasty kludge in one of the major interfaces to get this to work. The patch did that, and the devices can be used - that’s fine, but it doesn’t change the fact that the device doesn’t comply with the standards.

You win Chris - I’m wrong to be unhappy with the downsides of the upgrade from an unpatched 2.4. Have a great day

Sorry - I’m not trying to “win”. I’m just trying to explain the situation. I’m sorry that the patch doesn’t work - really - and I’d suggest to discuss it with the author. Maybe they can get it working.

Please feel free to apply to our accounts department for a full refund :wink:

1 Like

You are free to update the patch.

Personally if I had to use an unofficial patch that would be an indication that I needed to consider replacing the devices before they stopped working or find some software that worked without patching. Cheap hardware is attractive but usually has its own “quirks”. I have some cheap Chinese sensors like that.

Thanks Bruce. Truly insightful, wow

Awesome response Chris. Thought so. Still talking “patch” when it worked in 2.4 no patch. Done here, you should be too

Sorry, but that device didn’t work with 2.4 without the patch. It has a major flaw where it responds with a wrong command. There may have been a compiled version kicking around that worked, but it wouldn’t have been the released 2.4 version unless you have a different version of the device. I personally do not have the device so have no way really to help here - sorry.

Holy %$^&*, it worked until yesterday when I upgraded you .

OK, moment to cool off now. Wow, you’re calling me a liar too, nice.

There is a lot more than money at stake here as you should know as a developer. There is the time to create and tweak a set of routines, to understand to timing of opening doors and shutting off HVAC if they are not shut. Timing ancillary AC units to sync with main units, shut off units seasonally, etc. I have spent a lot of time on OpenHab understanding, developing a system, dealing with idiosyncrasies like the UI tasks not starting. This also includes updating your zwave repository when I could. This whole experience drives home that OpenHab is only a system useable for tinkerers. Honestly, at some time in the near future I will need to sell this place. There was a time when I imagined I could do so with OpenHab running it but it is becoming obious that I should absolutely convert to a commercial platform based on the upgrade fiasco each time alone. However, and this should be clearly understood, your flippant attitude towards this situation demonstrated in your last couple of posts is something I could never defend to a perspective buyer.

It worked in 2.4 Chris, stock, nothing but entries in my /etc folder. The old patch worked when that area of the code (2.3 I believe) was simple and not broken out into a bunch of classes. I could spin up Maven and Eclipse and get to the borttom of it too, but the spirit here seems to be to FO with the “non-compliant, whatever adverb” device because it’s like Chinese junk (which BTW, Bruce, is where the best electronics come from too these days). I switched from Vera to this, and OpenHab has been marginally better until this week…

Sorry, but if you’re going to take that tone, I’m really giving up. I have NEVER called you a liar or insinuated such!

The OPEN PR to resolve this was NEVER merged. As I said above maybe your issue is a different issue - I don’t know since you’ve not actually provided any information.

Please chill - there’s really no need for the attitude. I won’t be replying further and will disable my notifications on this thread.

1 Like

Yeah cool Chris please do whatever is easiest rather than dealing with the fact that a device so non-compliant worked perfectly in 2.4. There was a lot said that really should be dealt with and understood in that post because if OpenHab is only for tinkerers what is it’s value, but go shut this post down. It seems nothign to you to infer me a liar, but prefer to silence me instead, go ahead it makes total sense, if my effort to date means absolutely nothing. As admin you will have the final word as to who has attitude here, I admittedly do, you do too

I’m one of the original people who worked on the patch. I can confirm that OH 2.4 without the patch didn’t work for my setup with 5 of these non-compliant CT101’s. There’s no way I could afford even a single z-wave thermostat but with the deep discounts available on these ones they were way cheaper than even non-zwave programmable thermostats and I bought enough to go around, knowing very well they need hacking to work. I think I’m actually running a “2.5” version of the z-wave binding now, and I think I needed to make some tweaks to the patch so it applies cleanly. I just can’t remember what I did right now so I can dig it up and post the new version, if it helps others. Chris has made it very clear there’s no way he’s merging the patch as a pull request though, so I’ve stopped asking :slight_smile:

It did work for me (sans humidity) without your patch which, from the only version I saw, would not have worked in version 2.4 as the classes had all been renamed and the code heavily reorganized. I did use it in, I believe, 2.3 - so thank you.

No sense in arguing though as I have found the solution. Researching Home Assistant turned up the same issues with the ct101 in those forums. Instead of being viewed as “broken, non-standard and non compliant” they described it as being compliant except for the humidity sensor data. That was promising. When I loaded up their server and connected my z-wave stick it immediately recognized the thermostat, its quirk, and dealt with it - giving me all the data including humidity. It might be worth bringing Home Assistant up as a secondary controller to control these thermostats rather than porting your patch. I’ll defer to Bruce, undoubtably an expert from the “buy new stuff” advice he gave, who expressed that my upgrade woes (outside of these thermostats that belong in a landfill) were due to HUGE OH architectural changes. More are to come, apparently, in version 3 when they are ridding themselves of the janky Java version they currently use. Why bother porting it when the lead developer of this binding doesn’t care to know about a patch and then:

can’t keep compatibility with stuff I don’t know about

As a developer of 25 years it seems that the Home Assistant developers are doing a better job of error checking based on their initial reaction alone, not to mention caring about the experience of others developing patches to the system. Regardless, I am done here, I am paying the price completly switching over to Home Assistant and still currently porting my automation code, at least all of my devices are recognized and stay online today.

Good Luck

Hi there. Just a data point - the patch in my PR, referenced above in the thread, works just fine for me on OH 2.5. I’m happy to rebase it on the latest 2.5.x branch if that’s needed.

I still believe the patch should be merged, as it’s a 1-line change that fixes a big problem for a bunch of users who are stuck with these thermostats. In my opinion, the whole point of open-source hardware projects is that you can do “hacks” like this and get some mileage out of devices that would otherwise be unusable. If I wanted the “sorry it’s unsupported” treatment, I would stick with an off-the-shelf home automation product.

Still, I respect that Chris is maintaining this codebase and has made a different decision. It’s trivial to rebase the patch on the latest branch and build it yourself. Or download the jar file from the PR build and drop it in your openHAB install. Share and enjoy!

Patch applied to 2.5.x branch, for your convenience

As the original question asker I have been copied on the responses. My question in Post #1 was whether the Debug “unknown command class 01” that I accidently stumbled on was cause for concern and the discussion veered off the rails from there.

I bought these for much the same reasons as @jschmidt and my non-z-wave programmable thermostat had died. I liked the cost, Zwave functionality, that they could be powered from the HVAC (with battery as a backup) and were programable using OpenHAB rules. Also without Z-wave they can be programmed just like my old thermostat, so are not dependent on OpenHAB. I didn’t care about the humidity sensor or even know about it until later.

I think the answer to my original question can be derived from the last post by @sphillips containing the comment “…compliant except for humidity sensor data” is “No cause for concern”. These devices have worked well for me in both winter and summer at controlling temperature (and as I updated OpenHAB over the last 7 months- currently on 2.5.5).

However, as a tinkerer, but with very limited programming skills I would like to try your patch, but need some clarification. I downloaded the zip file from git hub and extracted it into a folder with files and more folders. Do I put all this in the OpenHAB addons folder? The other files in my addons folder are .jar files, but I don’t know how to get from what I have to .jar. Also do I need to uninstall Zwave in paperUI before I add this patched version in the addons? Hope this makes sense and thanks for your efforts.
Bob

Here were my notes on patching the system, my apologies if anything is left out, hopefully they might help you:

Install Oracle Java 8 JDK

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer

Install Maven

sudo apt-get install maven

Install git

sudo apt install git

Install eclipse environment for openhab in a development machine
(eclipse is optional, no instructions to install, look it up)

git clone https://github.com/openhab/org.openhab.binding.zwave.git

(make changes)

mvn clean install (from base of project)

scp to production
copy to /usr/share/openhab2/addons
Remove the existing zwave plugin
Restart openhab
The system will automagically load the new plugin at that point

Perhaps you could make a PR on GitHub so others could benefit in the future. Otherwise if the binding is rewritten according tompublishednZ-Wave specifications instead of the current reverse engineered binding, things could break again.

I know Chris has been very busy at work lately. I know I moved from Home Assistant primarily because many of my US devices were not supported without me patching the binding every update. OH supported my devices and Chris helped me through my migration issues.

I’m pretty limited in java/Linux skills so I thought I would try your patch as a shortcut to the process above since you already made the java changes to getting the humidity reading to work on the CT101. Piecing together various threads on creating an executable jar I did this:.

sudo git clone https://github.com/marcusb/org.openhab.binding.zwave.git
jar cf org.openhab.binding.zwave.jar org.openhab.binding.zwave
sudo chmod +x org.openhab.binding.zwave.jar

However after deleting the binding from Paper UI and placing the above .jar in the addons, and restarting Openhab it did not work. I could send the full error file, but I’m thinking I did not create the jar file correctly rather than there is any issue with your file. (I did attach a snippet of the error log, in case that helps)

2020-06-27 10:41:43.967 [ERROR] [org.openhab.core.thing ] - bundle org.openhab.core.thing:2.5.0 (185)[org.eclipse.smarthome.core.thing.internal.ThingManagerImpl(155)] : The addThingHandlerFactory method has thrown an exception
java.lang.NoClassDefFoundError: org/openhab/binding/zwave/ZWaveBindingConstants

any ideas?
Bob

So I finally faced my fears about editing a java file buried deep in the zwave hierarchy (using VSC) and after a few stumbles of my own lack of knowledge, followed your instructions (mostly) and the edits from Marcus Better and have a working CT101 humidity monitor on 2.5.6-2. It wasn’t quite as daunting as I thought. Thanks. I marked as solution.

Bob

1 Like