OK Bruce. …yet it worked without said patch in 2.4, now it doesn’t. Came here and see I am on my own
I’m not familiar with the patch. We’re not trying to stop the patch working - the patch was provided by someone so I guess it can be changed, but the binding can’t really be made compatable with any patches out there that people make - there are quite a few “non-standard” feature versions floating around I’m sure.
I think the point is that I’m not familiar with the patch. I didn’t change the binding just to break the patch to annoy you. Non-standard patches would of course need updating if there are changes made to the binding. I can’t keep compatibility with stuff I don’t know about and isn’t in the binding.
I develop software myself - I get it. I have been in conversation with the forum about this patch in the past and you were included. In fact, I remember your discarding “hackish” comment about it. Yet it worked. Then when it worked in 2.4 without a patch, I thought cool - but it was an accident, apparently.
Maybe I’m just being a jerk here but the 2.5 upgrade has destroyed my working system and pretty much ensures I need new thermostats to continue to do the things I did just fine in 2.4, …assuming the rest works better than it is showing now. Yeah, no - it sucks at the moment
Sure - I’m aware of the existence of the patch, but that doesn’t mean I am supporting it or that I am going to (or even able to) guarantee that future versions of the binding will be compatible with any patches people make. I’m sorry that this unsupported patch doesn’t work with newer bindings, but I don’t see how I can be expected to take responsibility for that?
It’s not part of the binding, and I have absolutely no way to test this completely broken and non-standard, non-compliant device. (again - sorry all the same).
“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 
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 
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!