I recently went thru an exercise to get a build of the test branch working so I could use the security features.
In doing so - I lost the hacked build of the normal binding I was using to run these thermostats. When I cloned the test code line to re-apply and compile after getting the garage door into secure mode… I see that the ZWaveMultiInstanceCommandClass in test is significantly different from the snapshot.
Before I hunt down the location where I need to place the conditional for my particular tstat in the test version of the binding… and since this is a one-off hack until official support comes along - Is there any reason I shouldn’t just unpack/pack the jars and move the class file over to the test build I already have working? Or has enough changed between snapshot and test implementations of that class’s functionality to make that a fools errand?
I am new to openhab and have been testing homeassistant vs OH. I really like OH but without my ct101 working I can not use it. Anyway you can share your jar file and let me know what I need to do to install that binding for my ct101 to work? Any help would be greatly appreciated.
I’m just getting around to re-visiting this - in a post just above I mentioned moving to the test branch of the zwave binding to get my garage door working and I lost the fix for the thermostats in the process.
Looking at the code - it’s markedly different. The multi encap code I had previously pasted the above solution into is all commented out. If I were to recreate the “if” condition @jschmidt put forward above - what method is handling the delegation where an error handling a HandleMultiInstanceEncap can try to process it as a HandleMultiChannelEncap?
Hey @walterj – just so you know, I have never looked at the test version of the zwave binding. I’ve never used it either, but I understand why it’s something you would want (me too eventually!). Unfortunately @chris may need to be the one to answer that question.
I have the Iris Version of this thermostat I was able to join it to my Z-Wave “network” (not 100% sure if that is correct term). I am able to control the target temp, but nothing else seems to work. I’m a little lost after reading this thread as to how to move forward. I saw that someone came up with some type of a work around, has this been added to the binding or do I need to implement that code myself. If I do need to implement the code, how do I go about doing that. Pretty new to OpenHab, just started with it this week. Thanks in advance.
@marcusb I’m in the same boat as @Jarred_Youngblood and can’t find the file location. Running openhabian on the pi – not sure if I missed something in the folder structure or just over looked it.
I have two CT101 thermostats talking to OpenHAB using an Aeotec 5th Gen Z wave stick and it sure acts like it wants to work!
I tried pulling data from both temperature sensors and the humidity sensor on both CT101 (I believe they are the Iris version) and no data is displayed.
I would love to test your patch, but need some guidance.
I did alot of research, if im not mistaken because we used paperui the zwave node might not be built in the same location or at all. That’s the best I can make of this.
@skifire Hi, I’m not sure what file location you are referring to, but the only way the Iris CT-101 will work currently is by building the zwave binding from sources with the PR branch (“mvn package”, install the resulting jar file into openHAB).
If you are unfamiliar with building Java projects then this will be a little difficult.
This is what @marcusb referred to as the “PR,” above. That’s a pull request for the patch to be merged into the mainline zwave binding, after which all users would simply be able to use CT101’s without any special handling. @chris, I know you don’t like it very much, but there is user demand to make this work. Can you have a look at the updated PR against the new code base and re-consider merging it in?
@marcusb – it’s been a while, but I have built packages from source before. Which, I don’t mind doing but it would be nice to know if that patch will be merged into the main binding. If so, I’ll wait to keep things consistent with the main branch. If not, I’ll put the time into getting these things working.
@jschmidt - I agree, there does appear to be some level of support for using these. As other have mentioned, the price is really attractive and it is much faster, safer and probably even cheaper than a DIY thermostat option. But, do we have a quantifiable amount of people to justify putting in code that deviates from the norm?
Personally, i’d be delighted to see this put into the main branch. However, I see this from @chris point of view as well. Adding additional maintenance to anything is a pain – even more so when it is to offset a manufactures shortcomings.
@chris is there anything that we can do or help with that would make this change more justified?
Let me take a look at it in a week or so. It’s a really nasty hack which I’d prefer to avoid, or at least make a bit more configurable so that other environments can choose not to include it.
I’ve really no idea how this device was ever certified - I suspect it wasn’t really as ZWA stated it was non-compliant and IMHO they really should have recalled them
Appreciated, thanks Chris. I agree with you, the device is faulty, but I have asked the manufacturer about it and got no reply at all. I suspect they don’t care, and other zwave hubs (“like” Vera or HS, but I don’t know if those specific ones are included) have implemented a workaround. The only one I can see publicly is openzwave, which has recently merged the workaround into their codebase.
I’d like to add my voice here asking for this to be implemented. I was lucky (foolish?) enough to get one of the Iris CT101 thermostat at a great price.
