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.
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.
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.
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.
Certainly don’t understand that.
Oh, yes, maybe I do. Is it in Room 101? Delete and try again. Sorry.
In testing, I regularly delete all child devices and they are recreated without problem.
I am going to let mine run without rebooting for a couple of days. (Zway has been running for 3 days without me rebooting it or fooling around with it). Now that I am done with all my plugin and scene optimizations.
I guess we learn things everyday… So I figured I would share here:
This is my noise level chart from z-way on my zwave radio.
Noticed the step function down around 21:00 on both zwave channels? It corresponds to the time I unplugged a hue 2 hub which was located inches away from the zwave dongle. I then located it a little further away, on the other side of a wooden panel and reconnected it at 22:30 and you can see the noise step back up slightly before settling back down.
Well turns out the zigbee chip on the philips hue hub also transmits in the 900 MHz range (Zigbee channels 1-10) even though it is really not using any of it and practically no zigbee devices use these channels any more. This makes me wonder if the vera plus/secure, collocating zigbee and zwave on the same device may have the same effect and could be causing problems.
I would think that 10dB S/N is worth having anyway.
I just realized that zway resets this chart when the log rotates.
I have tinkered with my environment using some leftover amazon gift card packaging boxes and putting them at the right spot… I managed to further reduce the noise level. On channel 2 it looks like the sampling frequency decreased but it didn’t. It is just that there is a lot of “not detectable” level after I added my MacGyver shields so a lot of datapoint were skipped.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules
