Applying fix in openzwave to get Remotec ZXT-120 working with HASSbian


I bought a Remotec ZXT-120 (Z-wave-to-AC IR Extender) and I am trying to get it to work with my Aeotec Z-Stick Gen5. Like others (Remotec ZXT-120 AC controller issues and Z-wave IR air con extender: or hassbian?), I’m experiencing problems with setting parameters, which often fail due to a timeout issue. It’s incredibly frustrating to try and work with a device that only occasionally responds to my commands.

Now as pointed out by others (here: Remotec ZXT-120 operational questions + my script - #13 by turbokongen), there is a fix made by jokatar that never got merged. A somewhat uglier version of this fix is ‘simply’ adding one usleep line into cpp/src/Driver.cpp in OpenZWave.

I’m trying to edit Driver.cpp and use it on my Hassbian installation. I found out that Hassbian relies on python_openzwave, so I figured I’d uninstall that, pull openzwave from github, edit the Driver.cpp file, make & install openzwave, and reinstall python_openzwave using the ‘shared’ flavour. I didn’t get errors, but the issues with the Remotec ZXT-120 haven’t disappeared.

So my main question is: how to patch my openzwave installation with Jokatar’s fix such that Hassbian changes its behaviour?

To get there it would already be a huge help if I could confirm that edits I do in the source code end up being applied. For this purpose I tried editing the Message transaction complete log entry

Log::Write( LogLevel_Detail, _data[3], " Message transaction complete" );
Log::Write( LogLevel_Detail, _data[3], " Message transaction complete I was here" );

And wrapping the usleep(5000) line in log entries
Log::Write( LogLevel_Detail, GetNodeNumber( m_currentMsg ), "Me: start sleeping" );
Log::Write( LogLevel_Detail, GetNodeNumber( m_currentMsg ), "Me: done sleeping" );

So far I’ve seen no evidence of these edits in the zwave log I can pull up in HASSbian , which makes me think that the openzwave that HASSbian relies upon is unaltered…

Who can help me?

Details of how I’ve been editing openZwave so far:

  • Login via ssh as user pi
  • Stop homeassistant
    sudo systemctl stop [email protected]
  • switch to home assistant user
    sudo su -s /bin/bash homeassistant
  • activate virtual environment
    source /srv/homeassistant/bin/activate
  • uninstall python_openzwave
    pip3 uninstall -y python_openzwave
  • switch to pi user
  • Clone github openzwave
    git clone
  • Edit Driver.cpp using nano
    nano /home/pi/open-zwave/cpp/src/Driver.cpp
  • Go to the resporitory folder
    cd /home/pi/open-zwave
  • compile and install openzwave from the source you’ve just edited
    make && sudo make install && sudo ldconfig
  • switch to home assistant user
    sudo su -s /bin/bash homeassistant
  • activate virtual environment
    source /srv/homeassistant/bin/activate
  • install with python_openzwave with shared flavour
    pip3 install python_openzwave --install-option="--flavor=shared" --no-deps
  • switch to pi user
  • start openzwave
    sudo systemctl start [email protected]

Hassbian Zwave log results when I try to set a parameter:

2018-04-02 14:56:03.022 Info, Node014, Sending (Send) message (Callback ID=0x1f, Expected Reply=0x04) - ConfigurationCmd_Get (Node=14): 0x01, 0x0a, 0x00, 0x13, 0x0e, 0x03, 0x70, 0x05, 0x1b, 0x25, 0x1f, 0xbf
2018-04-02 14:56:03.031 Detail, Node014, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2018-04-02 14:56:03.031 Detail, Node014, ZW_SEND_DATA delivered to Z-Wave stack
2018-04-02 14:56:03.048 Detail, Node014, Received: 0x01, 0x07, 0x00, 0x13, 0x1f, 0x00, 0x00, 0x03, 0xf7
2018-04-02 14:56:03.048 Detail, Node014, ZW_SEND_DATA Request with callback ID 0x1f received (expected 0x1f)
2018-04-02 14:56:03.048 Info, Node014, Request RTT 25 Average Request RTT 412
2018-04-02 14:56:03.048 Detail, Expected callbackId was received
2018-04-02 14:56:09.180 Detail, Node014, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x0e, 0x03, 0x80, 0x03, 0x55, 0x29
2018-04-02 14:56:09.181 Detail,
2018-04-02 14:56:09.181 Info, Node014, Response RTT 6158 Average Response RTT 6553
2018-04-02 14:56:09.181 Info, Node014, Received Battery report from node 14: level=85
2018-04-02 14:56:09.181 Detail, Node014, Refreshed Value: old value=85, new value=85, type=byte
2018-04-02 14:56:09.181 Detail, Node014, Changes to this value are not verified
2018-04-02 14:56:09.181 Detail, Node014, Notification: ValueChanged
2018-04-02 14:56:13.023 Error, Node014, ERROR: Dropping command, expected response not received after 1 attempt(s)
2018-04-02 14:56:13.023 Detail, Node014, Removing current message
2018-04-02 14:56:13.023 Detail, Node014, Notification: Notification - TimeOut

1 Like

@5HomeAssist Did you ever get the zxt-120 working.
I have 6 of them I plan to migrate over from SmartThings. I wrote the Device handler on SmartThings so I am pretty familiar with how this device works but from the threads I am reading it seems there are a lot of issue using it on HA. So I am reluctant to remove them from SmartThings.

Did you get any hint on this_

I’m having a problem with a chinese switch that I believe can only be fixed with a OZW patch.

Nope :’-( no progress so far…

I guys,

Another one with same issue running on Docker and with an Aotec ZWave stick Gen 5

I found a work around to get the another zwave device to work in HASSIO that may work for you.

I cloned the OpenZWave git repository to a local directory accessible by home-assistant. I then modified my configuration.yaml file to use this new config_path for zwave.

  1. git clone
  2. Update to configuration.yaml:
    usb_path: /dev/ttyACM0
    config_path: /zwave-config/open-zwave/config

Seems great!
Would you mind to expand your solution?
I’m really interested.

I’d definitely be interested in a fix for this also. I have the exact same time out errors as the OP in my log. Temperature changes work, but all other functions time out for me.
I am running Hass.IO, latest production build.
I saw a couple of people working on similar issues on github, but it seems each one only got to a certain point and then was abandoned for long periods of time.

Any assistance would be appreciated, especially for Hass.IO running on HassOS.

Thanks @chuckit! I think I’m actually communicating with my AC now :scream:

This is what I did:

1 Change configuration.yaml (obviously don’t change the USB path if you have something else there)

    usb_path: /dev/ttyACM0
    config_path: /home/pi/open-zwave/config

2 Clone jokatar’s openZwave at the above defined config_path

  • Login via ssh as user pi
  • Stop homeassistant
    sudo systemctl stop [email protected]
  • Go to the folder where you want to put open-zwave (this defines where config_path needs to point)
    cd /home/pi
  • Clone jokatar’s openzwave from github
    git clone
  • Edit zwcfg_xxxx to include PacketDelay, before starting hassbian. Just leave the terminal open, but change the zwcfg_xxxx file from the same folder as where the configuration.yaml is (via samba or whatever method you prefer). In my case the node has id 15, and I just added PacketDelay=“50000” to the end, which gave
    <Node id="15" name="" location="" basic="4" generic="8" specific="6" type="General Thermostat V2" listening="false" frequentListening="true" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Complete" PacketDelay="50000">
  • Start homeassistant
    sudo systemctl start [email protected]

I also tried a variation of the above by pulling the official open-zwave repository and then editting in a usleep line and some log statements. None of the log statements made it to the log, but the AC sort of seemed to work. However, since it has been sort of working every now and then before, I was hoping to get some solid proof. By pulling jokatar’s version and getting pretty reliable behaviour all evening, I guess I have my ‘proof’. I only wish I knew why I can’t write to the log :no_mouth:.

Anyways, it works!

Hope this helps others too!

This is great instructions, I have to give this a try now.
Does anyone know what exactly was fixed on GitHub - jotakar/open-zwave: a C++ and DotNet library to control Z-Wave Networks via a Z-Wave Controller. for the zxt-120?

I still find it a little strange to switch the open-zwave to some random (maybe not so random) clone of the repo. How would we know what this will break for other zwave devices? I would prefer to know the fix that was applied to the open-zwave so I can clone the version of open-zwave that HA uses and just apply the fix. This way when HA upgrades I can just merge the upgrade with my clone and keep the fix until the day that this change is actually included in HA :slight_smile: then I can drop my clone.

This is why I was considering making a separate HA instance just for my zxt-120 devices. Then I know the hack is working for them and not breaking anything else.

The other issue I have with this approach is that I have another device which also requires I replace open-zwave software with someone else’s clone. So unless I know the commits that fix the issue and merge them into one clone myself I don’t see how I can place both devices on my system.

Good news I will take a look later. I tried to change the code myself but probably it’s better to download the code changed.

Thanks for the info and manual.

Unfortunately it didn’t succeed the make operation

    i/dockers/hass/config/open-zwave/cpp/src/Node.h: In constructor ‘OpenZWave::Node::Node(uint32, uint8)’:
/dockers/hass/config/open-zwave/cpp/src/Node.h:375:18: error: ‘OpenZWave::Node::m_PacketDelay’ will be initialized after [-Werror=reorder]
     uint32       m_PacketDelay;
/dockers/hass/config/open-zwave/cpp/src/Node.h:373:12: error:   ‘std::__cxx11::string OpenZWave::Node::m_nodeName’ [-Werror=reorder]
    string  m_nodeName;
/dockers/hass/config/open-zwave/cpp/src/Node.cpp:119:1: error:   when initialized here [-Werror=reorder]
cc1plus: all warnings being treated as errors
/dockers/hass/config/open-zwave/cpp/build/ recipe for target '/dockers/hass/config/open-zwave/.lib/Node.o' failed
make[1]: *** [/dockers/hass/config/open-zwave/.lib/Node.o] Error 1
make[1]: Leaving directory '/dockers/hass/config/open-zwave/cpp/build'
Makefile:20: recipe for target 'all' failed
make: *** [all] Error 2

Just look at the original link I posted: . There you can find all the changes + commentary. As far as I can see the code doesn’t do much else other than introducing a delay for a specific node that has a packetDelay assigned to it. As such, there shouldn’t be any problems with other devices, and so far I’ve experienced none.

Hmmm you’re in docker, so not working with hassbian but with I tried that and gave up :frowning:

No. The offitial homeassistant-homeassistant docker. I guess is hassbian but for sure it’s not

Ok, I never tried that :slight_smile:

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=''>
  <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