@smart
I would suggest to focus on the OpenZWave issue. Once you fix that, HASS will behave normally.
The timeout is in the OpenZWave log and is a ZWave timeout, not actually HASS.
Other systems, like OpenHAB, that use OpenZWave have the same issue with these devices :).
B.
Well as someone coming from openhab I can assure you they don’t have this issue since time ago. I don’t think they use the ooenzwave library but some kind of fork.
I also have zxt and was wondering how we can get a stable and reliable device… IT#s like the devoce is randomly working… what always seems to work is to set temp. each time i get the beep. On / off are more sporadically .
I’m really upset. I bought 4!!! devices and somehow they just wont react to my commands… I just cant figure out what the henk is going on … fact is that i set for example operation mode OFF and receive previous operation mode from zxt.
Is here anybody with a more or less stable zxt running and maybe even setup ?
As far as I understood from openhab community is affecting fast computers. Probably with a saturated pi would work perfect. With 4 of them I would try with a pi zero.
I doubt it has anything to do with speed of the computer to be honest.
The issue is timeout issues. OpenZwave log shows it clearly.
Maybe OpenHAB are using a fork with the patch in it. If I reboot Hass (full reboot not just restart Hass) the device will work properly for one command, then go back to working to change temp only.
That happens no matter what computing device is used.
There are PRs that were not actioned on OpenZwave GitHub indicating a fix, but guessing they were not clean enough to merge.
The issue seems to be a timing issue to when the end “no more data” is sent.
I don’t know enough about the technical side of zwave to guess more though.
Not an expert neither but I remember fast computers send the get signal too fast for the ZXT still working on the previous set command and then ignoring the get. So the timeout.
The patch developed but I’m unable to make it working in HA was a wait time between the set and the get.
Just for info it was working on my PI but when I moved to a fastest laptop stoped working.
If someone more experienced than me would work with me to patch the openzwave and apply locally I could create the workaround manual. Even if nobody can help me and I succeed I will make the workaround manual anyway.
I think @fishwaldo from OpenZWave looked at both the PRs put over there, but then the responses just suddenly stopped.
If you can get in touch with the guy who put in the PRs maybe we can achieve something.
I am using a Pie B+ running Hass.IO at the moment.
Does anyone know if the replacement for the zxt-120, the zxt-600, have the same issues?
I only got 1 zxt-120 for testing, but it is a few years old. My ZXT-120 is the V1. 8
After a lot of mucking around, finally got this thing working 99% of the time. Still get the odd timeout error.
Had to change the Options.xml file. I am not using any other patches or non-standard downloads, and the options changed are ones that are user settable.
In order to report temperature regularly, I had to actually set Z-Wave controller to POLL this device as it does not seem to automatically send status updates. If not polled, the temperature reading only updates when a command is sent to the device.
I used the device_config option under zwave configuration to specifically set polling on the temperature sensor and I also used this to hide the specific entities I did not use.
To minimise the time out errors, that was setting a couple of options in the options.xml file (which is the openzwave options file, normally located in the CONFIG folder in HA).
I set NotifyTransactions to true and RetryTimeout to 40000 and it seemed to work. I haven’t bothered playing with the settings to see if it can be tweaked as all my Z-wave devices are working properly with those settings, including the ZXT-120.
Well, It looks like I spoke too soon. The latest updates have again made this device unreliable with OpenZWave and Home Assistant.
It works okay on other platforms, so it does look like a glitch in OpenZWave.
Anyway, as I only have one of these, I have decided to retire it. The new ZXT-600 is due out in Australia in about a month. It is a Z-Wave plus device and replacement for the ZXT-120.
I’ll try one of them instead. As the ZXT-120 is the only non-plus device I have, maybe it will help overall stability to be rid of it
Hmm is it worth the risk for the 600!? I’ll let you be the guinea pig 
Guess it depends on OZW :).
I have a broadlink RM pro now that does the job. I don’t like using WiFi much, but it is just one device for now.
Hadn’t seen the RM pro before. You have this working through hassio? Is there an addon for it?
I am using HASS.io.
I have it working, though it did take a little bit of time. There is not an official climate component for the Broadlink device, but there is a post on the forum by someone who wrote a custom component and that works fairly well, as long as you have a little patience to setup the IR Codes.
Well,
The ZXT-120 is temperamental at best with OpenZWave, but if you leave the GetSupported at feature 67 false, which means ThermostatSetpointCmd_Get is not reported, it works 80% of the time.
I have now been testing a ZXT-600. The 600 is a vast improvement. It is a Security enabled device as well as being Z-Wave Plus. Although OZW config has the GetSupported at feature 67 false, the device is 100% reliable when using that feature set to true also.
The temp sensor in mine is hugely inaccurate, but I use other sensors for room temp. As far as a ZWave to IR for your AC goes, the ZXT-600 is everything we had hoped the ZXT-120 would be. It just works, even when using ThermostatSetpointCmd_Get.
Just thought I would share that.
thanks Brendan for your report on zxt600 As still winter is yet to come where I live I will wait to see if the new openzwave fork will evolve into controlling zxt120 otherwise I will go with zxt600
Thanks for testing Brendan, you’re a legend. I think i’ll try it.
@ sergi.suarezj
If you have a few ZXT-120’s, then it may be worth waiting.
In the last week I have retired my Raspberry PI version of Home Assistant in favour of using the now officially available Virtual Image.
I run it on an older Core I5 laptop, windows 10 as the Host operating system in Oracle’s Virtual Box with a Virtual UBUNTU install…
With the current Image, the ZXT-120 magically came alive and for the past 4 days has responded to every command. I am currently using the ZXT-120 in FLiRS mode on battery and have not tested it when in always listening mode yet, but (touch wood) so far it seems okay.
I will report back after a bit longer time testing.
Just an edit: 7 days later and the ZXT-120 still works flawlessly with the Virtual Disk Image and Virtual Box.
It still fails if reinstalled on a Raspberry Pi 3 however.
I am not sure what the difference is between the direct connection and the USB Passthrough to the Virtual machine. ZXT-120 works in VM, but not directly on the Raspberry Pi 3.
I moved from Vera to direct zwave integration 5 months ago, during that time I used the heating node, today I tried to turn on the cooling (less than 24 degrees), it set it to the temperature I asked but the AC didn’t start the cooling action, so I tried using the cooling node and it started working properly,
Did anyone experienced that behavior? What is the solution other than creating a script that displays in UI the right node according to the season?
Thanks
There is no solution to this issue, other than having the entity change dependent on the season. This is the way the product is designed. The ZXT-120 (and the newer ZXT-600) create one entity for heating, and one for cooling. This will happen on all Home Automation hubs. I have used the ZXT-120 on HomeSeer, OpenHab, Home Assistant (direct via a Z-Stick) Vera and Fibaro Home Centre. All create the separate entities for heat and cool.
If you change the temperature on the Heat entity, it assumes heat mode and will change the HVAC unit it is controlling to the heat mode. Change temp with the Cool entity, and it will set cool mode regardless of previous modes.
This is a pain when using a voice assistant as “set the living room to 25 degrees” changes both thermostats and you may have the HVAC unit switch modes depending which one responds first.
Unfortunately the only work around would be a WiFi based unit like Broadlink RM pro or the like using a more custom component that creates a single entity thermostat.
The issue with these devices is they appear to be very underpowered, hence often are too busy doing something to respond to anything on the RF side. This manifests itself as “timeouts” in OZW.
The reason I didn’t accept the PR was it was a terrible work around. It effectively made OZW only send a single packet every second (or half second) thus it would slow down your entire communication on the Zwave network.
The reason why it might work sometimes and not others could be due to other factors like what traffic is on the network, other things that HASS or OZW might be doing etc that slightly affect the timings of packets going out.
Unfortunately for you guys, all I can say is while they have some innovative products there implementation is crap. Slowing down OZW (and thus your entire network) is not a solution I accept. They are aware of the issue but refuse to work with me, sighting they don’t support gateways running OZW.
