Hmmm you’re in docker, so not working with hassbian but with hass.io? I tried that and gave up 
No. The offitial homeassistant-homeassistant docker. I guess is hassbian but for sure it’s not hass.io
Ok, I never tried that 
But now I see you’re trying to ‘make’ - suprisingly enough, I didn’t… I just pulled and let things be, no compiling etc.
OK thanks, I was under the impression that there were other commits necessary for the zxt-120 to work and not just this one.
Also looking at the comments for this Patch it seems it may not be a safe patch.
turbokongen commented on Dec 22, 2017
I gave this a shot, and here is my findings:
The timeout works good for making the ZXT-120 respond like it should. However, if I try to include a new node with this patch running, it get’s stuck.
That has me a little concerned. Are others finding their system works fine with this change?
Still don’t work for me but I have made a test with OpenHab in a new container and works perfect so now I’m planning to keep OpenHab to control ZWave and mqtt to share coomunication between openHab and Home Assistant.
But do you know other home automation systems that can work? This is because openHab is a machine to eat resources.
I finally got my ZXT-120 working reliably.
I have not downloaded anything additional. I am just using the standard HASSIO build and open-zwave that comes with that.
I did modify the “options.xml” file though. I have the options set as follows.
<Options xmlns='http://code.google.com/p/open-zwave/'>
<Option name="logging" value="true" />
<Option name="Associate" value="true" />
<Option name="NotifyTransactions" value="true" />
<Option name="DriverMaxAttempts" value="5" />
<Option name="SaveConfiguration" value="true" />
<Option name="RetryTimeout" value="40000" />
To be honest, I have no idea which one of the options made it work, but it is now reliably responding every time I send a command whether it be a temperature setting or changing the auto swing.
Before I could only ever get it to change temp and all other functions gave a time out error.
Just as a note, after I changed the settings I also deleted the zwcfg_*.xml file. That is the settings cache file. OpenZwave recreates it at startup if it is missing.
I agree with you! Changing this file made the trick!!!
I didn’t delete the zwcfg file and worked anyway
I’m almost crying
I am glad I was able to help.
I’ve been fighting with the ZXT-120 for a long time.
I have one with razberry on RP3. It works ok. Is openZ-wave smth another and do not need razbery? Why do you use openZ-wave? Is it cheaper? You can buy cheap rf module, not razberry, whitch costs ~80$?
Open Z-Wave is the software library side of the operation. It tells your controller what the different devices are basically. My Z-Wave controller hardware is a AEOTEC Z-Stick Gen 5.
The options.xml file are software options for the Open Z-Wave software.
This is great! I haven’t tried adding my zxt-120 yet because of this thread but now I will.
Where did you find an options.xml file?
I can’t fine one across my entire filesystem.
“sudo find / -name Options.xml -print” finds nothing.
I suspect from the code that was changed by others that the RetryTimeout does the trick because the code changes folks have been attempting add delays so signals get through. A retry with a long limit should work the same.
You replied to my post but didn’t quote so I have no idea what this comment is in reference to and honestly I don’t understand what you are saying. Open zwave is the open source code used by HA to support zwave. If you use zwave component in HA then you are using open-zwave.
The options.xml file is sitting in the CONFIG folder, on my setup. I use just the default location.
If you have set a path in your config.yaml to point to a particular zwave config file location, it will be in that location.
B.
OK I found it on my main HA system. I was looking on my work instance and I didn’t see it. I have to check there again tomorrow. It was just in the .homeassistant folder. Thanks again!
At first these settings didn’t work for me. I had decided no to change NotifyTransaction when I read the purpose of this setting here.
I was about to post the changes don’t work for me when I realized perhaps it was the setting I didn’t change. So I changed it and now my zxt-120 is working fine when I issue commands they get sent.
This seems to be the Key setting!
<Option name="NotifyTransactions" value="true" />
The only problem I have is the UI isn’t changing correctly to reflect the changes I am making.
I change the temp to 75, it sends a signal and changes from red to black. But the sensor still reads current setting as 79.
Another problem I have is changing the temp before setting temp sends the signal and the AC turns on but the “Operation” remains off. So to turn it off now I have to change the dropdown to Cool and then back to Off.
I guess once I automate this it will not matter so much because it will set the cool mode, then temp but it would be nice to improve the UI.
I have that same issue and I believe it is because the ZXT-120 does not support ThermostatSetpointCmd_Get command.
In the OZW_log.txt file I will see this line.
2018-08-12 20:32:48.738 Info, Node002, ThermostatSetpointCmd_Get Not Supported on this node
Node002 is my ZXT-120.
I am guessing that is because it uses infrared to communicate with the Air-Con / HVAC and therefore can not verify what temperature that unit has set as target as InfraRed is one way communication. This is the same reason you end up with 2 entities, one for heat and one for cool. If you call to change temperature via the heat command, it sets that temperature in heat mode and via the cool it sets it in cool mode. This would be due to not being able to confirm the units current settings due to it being via infrared.
All I can think of is using a separate card with a variable that stores the last set temp. Obviously if someone was to use the HVAC’s original remote to change the temperature, then it would again be wrong.
I found that adds an entry in the ozw_log file.
2018-08-12 21:11:26.793 Detail, Node002, Notification: Notification - MsgComplete
The notification itself likely isn’t the key as much as the small delay added by the extra command before the next command is sent. That seems to be the key for the ZXT-120, to ensure the commands are not sent to it too quickly.
Good catch. I fixed the issue.
- shutdown ha
- edit zwcfg_XXXXXX.xml file
- Change the following to getsupported=“true”
<CommandClass id="67" name="COMMAND_CLASS_THERMOSTAT_SETPOINT" version="1" request_flags="4" getsupported="true" innif="true" base="0">
- restart ha
It wasn’t the zxt-120 that didn’t support get, it was the configuration from Open Zwave was wrong.
I had the exact same thought. It’s also possible that the notification isn’t what I reads like. Perhaps it means for the open zwave to wait for notification ? In either case with that setting it seems to be working pretty well.
@smart
Can you get the change to the zwcfg file to stick after a restart?
It seems to be overwritten at a reboot for me.
Dam, your right. It isn’t working again. I see two options.
- write start script which edits the file before startup (YUK!)
- editing open-zwave and setting it correctly in config/remotec/zxt-120.xml will make it stick.
I tried #2 and it works. I think I will lose the changes next time I upgrade so I have to look into the steps I have seen to use your own OZW build.
But here is what I did. I edited two files I found.
pi@hassnuna:~$ sudo find / -name zxt-120.xml
/srv/homeassistant/lib/python3.5/site-packages/python_openzwave/ozw_config/remotec/zxt-120.xml
/srv/homeassistant/lib/python3.5/site-packages/python_openzwave/ozw_config/config/remotec/zxt-120.xml
I changed the following in both. I commented out this line…by adding
<!-- RRG Yes it is damit....
and
-->
around
<CommandClass id="67" base="0" getsupported="false"/>
It looks like this when done.
<!-- COMMAND_CLASS_THERMOSTAT_SETPOINT get is not supported -->
<!-- RRG Yes it is damit....
<CommandClass id="67" base="0" getsupported="false"/>
--->
@smart
Looks like something we will have to do manually for now.
I wonder if it is worth logging it as a bug on OpenZWave and seeing if the developers will correct the error.