openLuup: ZWay plugin for ZWave.me hardware

Most of the work for the migration will be to modify all my automation involving device id and assigning all the devices to their rooms… with a couple of hundred scenes… That’s why I will want to wait for zway2 to before running the full migration since now the device ids will change.

The Devices Table page in the openLuup console (not AltUI) is perhaps the fastest way to move devices between rooms. It provides a pop-up room menu against each device and you can just rush through them.

Under the hood, there are also utility routines to change device numbers automatically in scene triggers and actions, as used during migration of Vera scenes to openLuup. These could get a similar API.

1 Like

Yes I saw one of your previous postings showing and pointing me to use the console rather than openluup. I will certainly do that for triggers and I will have to change a lot of lua code in scenes too…

The cloneroom idea was very good after all:

With Async polling now implemented, the bridge rocks.
I have been working on some peripheral things, learning how zway work on the way. The 4 APIs interacting at different levels of the device data model is quite interesting and I was able to improve the response time of triggers from doorlock manual actions, making them practically now instant by enhancing a zway plugin. I have also been looking at resetting of security sensors “tripped” status which I really needed with the vera (due to ghost trips and missed untrips) but have not yet with zway. I found it to be actually quite complicated since it requires going down to the command class level of the data base. They have done so many years without it that I must assume that nobody must have deemed it necessary… Yeah, the network is this much more reliable…

As not everything is the same and vera had implemented some interesting enhancements to their device specific handling, other platforms may not have, I am finding out some areas needing some work. The big difference is this though… The fundamentals and stability are solid and I am discovering that the APIs are so complete, though not very well documented, that we have full flexibility to make these tweaks ourselves if and when necessary.

(Re)Including an S2 security device now… which vera couldn’t support…

Are you using the latest version from the development branch? This should be good for many devices including locks and thermostats. If not, then I need to know!

For using the CGI, it should be as easy as ticking the boxes against those command classes that you want as individual children and then returning to the top of the page and pressing Commit. Restart openLuup and the new devices should be created.

Using only the Zway portion from the development branch . didn’t think I needed to upgrade the entire engine. I did change the device implementation file from L_Zway.lua to L_Zway2.lua . Been testing a basic light switch that report power consumption (Volts/Amp/KWH) and Z-wave to IR thermostat from remotec ZRX-120 . But both device create a bunch of children for the different aspects they monitor or control.

The children generally match what you see on the smarthomeUI and correspond to their dedicated command class if recognized. What unwanted children are you seeing?

There have been some engine changes to support the bridge. Do try with the latest openLuup development.

They are not unwanted, they are wanted … although they simply don’t get recognize by the plugin properly. For example:

The thermostat is recognized as one Temperature sensor and four children for controlling Cool and Heat and other two the Cool and Heat Setpoints, If device_type on children within openluup is changed to match the real device type the action do show up but on request the actions are not executed.

For diagnosing recognition problems it would be very useful to get a list of all the zway... variables in the device in question.

It will really help us to fix such issues.

Alternatively if you can post a screenshot of the bridge cgi breakdown of the child devices for these problem devices, the device recognition could be a quick fix.

The switch to z-way with this bridge has been night and day for my whole setup.
Instead of spending all my time chasing zwave network issues, device configuration and memory corruptions etc… I am now back at creating new automations and plugins.

I totally undertand, We even went as far as creating a OpenZwave plugin for openluup but We faced many difficulties, specially in the zwave queue (Commands were getting cloageg) and was taking us too much time to debug and get around them…

If We can get ZWay to be as friendly as Vera I’ll be the first to dump vera and swap em’ all

Anyhow, not much to see in the screenshot, @akbooer has shared that the particular thermostat in this setup does not offer command class 64 and for that reason not getting correctly recognized by the ZWay plugin and can be easily fixed. The Smart Plug is a different story.

2 Likes

I don’t think this should be a problem either. Thanks for posting this. I am sure @akbooer will have a fix for this soon. It is, I think, just a matter of moving the power meters into the switch device.

Yes, thermostat fix is straight-forward – I had simply assumed that all thermostats would have class 64, but apparently not. This is exactly why a wider range of devices will be great to try.

The switch has already identified as a “switch +” type (which is the recognition you added, @rafale77, to get @DesT devices operating correctly. So there shouldn’t be anything wrong here. The switch should work as a child device. However, I will automatically create it as a switch, along with its child alarm.

I’ve just pushed development branch v20.3.23, including an updated CGI file (should not be necessary to use often.) I’ll look at merging pull request #21 subsequently.

1 Like

I’ve downloaded the latest changes on the Zway development branch (2020.03.23) and reinstalled the plugin.

The Smart Plug looks perfect now but the thermostat looks weird.

The plugin auto created the temperature sensor “25001” and “20040” ComboDevice does not seem to have all the variables for a regular thermostat.

:thinking:

OK, I think you should just delete that child device and restart openLuup.

Deleted the temperature sensor child “25001” , also uncheck the child on zway_cgi.lua. restarted the engine but the thermostat was not recognized. I tried manually setting the “20040” device’s attributes to:

device_file: D_HVAC_ZoneThermostat1.xml
device_json: D_HVAC_ZoneThermostat1.json
device_type: urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1

without luck.

No, I meant delete 20040 and restart. The device should be recognised automatically.

After deleting the parent device “20040” and restart the engine, the device did not get re-created and it disappeared from zway_cgi.lua list.