People at work distracting me… One momento …
Voila !
Ah, I think I’ve found it. The new firmware is presenting a controller device with an id of “0”. This creates something of a problem. Anyway, try this.
Much Appreciated AK, that was it…
Ah, great news. You’re back in business.
Thanks, as ever, for the excellent diagnostic information along the way.
As always, you did all the heavy lifting so you sir deserve all the thanks …
[quote=“akbooer, post:85, topic:193746”]Ah, great news. You’re back in business.
Thanks, as ever, for the excellent diagnostic information along the way.[/quote]
My frustration with my veraplus and it’s recurring habit to miss untrip messages from my motion sensors, to omit some devices when sending on/off commands (at least one or two of my blinds stay open/closed EVERY time I run a scene, but always different one’s) ,the painful “cannot detect device” message and the fact that some of my battery powered door sensors will simply fall off the grid after while has made me pull out my Razberry board I have tested about a year ago.
I updated it’s firmware to 2.3.7 and included a spare Fibaro roller shutter. I was pretty surprised after configuration to see it come up with two sliders for positioning and changing the tilt for venetian blinds. This is currently only working on openhab, not on Homeseer and certainly not on Vera.
Z-way seems to have matured in device support quite a bit (still not so much in terms of usability and documentation).
This makes me think: openluup + AltUI + Razberry board would make for a very competitive HA hub.
@CudaNet
are still using your Razberry as part of your production system? How is it going?
@ak @amg
Am I correct in assuming that the low level zwave stuff is handled by Z-way and that the ZWay/RaZberry plugin on openluup is responsible for the devices that were included via RazBerry board to show up on openluup/AltUI?
Am I correct in assuming that the low level zwave stuff is handled by Z-way and that the ZWay/RaZberry plugin on openluup is responsible for the devices that were included via RazBerry board to show up on openluup/AltUI?
Yes, that seemed the best approach. It’s far from perfect, but the basics are there. Beats Vera for reliability, anyway.
ak, would it be possible to make a controller shift from vera to razberry or would you recommend building the zwave network on the razberry from scratch?
Also, would it be possible to shift the network from the razberry back to vera, just in case the razberry wouldn’t perform as we hoped for?
You’d have to ask someone with more Zwave nous than myself… I only wrote the ZWay plugin! The whole point of using the ZWay product was that I didn’t have to get into the depths (too much) of Zwave complications. I’m sure the native ZWay software and firmware accomplishes a controller shift.
I would anyway recommend just trying it out with a few modules to check that it has your needs covered. Once that works, consider how best to migrate.
I will definitely test with more devices how they behave on Zway before trying to migrate. Thank you.
one more question,ak.
Can you please explain what the Zway plugin and what the RaZberry plugin does?
Do I actually need both?
[quote=“pls90, post:92, topic:193746”]Can you please explain what the Zway plugin and what the RaZberry plugin does?
Do I actually need both?[/quote]
Both @amg0 and myself set out at about the same time to investigate Razberry. The ZWay software has multiple APIs. @amg0 and I went for different ones. He went the all-singing, all-dancing (and somewhat complex) route! I went for the easy option.
They are entirely independent (although we collaborated on some things.) Neither of us have done development of these very recently, AFAIK, and we’re not in competition, it’s just different approaches. Although it’s on my roadmap for openLuup, it doesn’t have a timescale attached.
RAZB aims to accomplish everything through the AltUI interface. ZWay relies on the native SmartHome interface for device inclusion and configuration.
One of the challenges for these plugins is to make the motley collection of Zwave widgets for each device look like a Vera device. This is hard without a comprehensive (and ever changing) manufacturer-specific database. This has been one of Vera’s own bug-bears too. My plan would be simply to abandon even trying, and present every device as a parent device with multiple children, one for each switch/sensor/etc. You could hide the ones you weren’t interested in. But that is for the future.
I have been testing RaZberry/Zway.
@akbooer your ZWay plugin is working quite nicely so far. Speed is EXCELLENT!
Still, I am afraid I have a few questions.
For every element on Zway should there be one equivalent device on openluup?
For most of the devices I have tested this seems to be true, except for some this is not.
Among others which don’t pose much of a problem I have an issue with a Fibaro Multi Sensor.
The only element which seems to not be mirrored is the motion part which is rather crucial for a motion sensor ;-). Temperature, Lux level are working fine.
A Aetec Multisensor is working perfectly with every single element being carried over as expected.
Also, a Fibaro Roller Shutter is behaving strangely.
I have two of these modules included, a very recent one with FW25.25 and a 4 year old one with FW22.22.
The new one shows a dimmer element to change positioning as expected. The older one shows only a scene controller element, but nothing else.
I have high hopes to use Zway and your plugin to finally step away from Vera completely without having to start from scratch in a completely new environment.
Do you have any thoughts on the missing elements/devices the plugin seems to be skipping?
Thank you!
Always good to hear.
Still, I am afraid I have a few questions.
Inevitably.
For every element on Zway should there be one equivalent device on openluup? For most of the devices I have tested this seems to be true, except for some this is not.
The answer to this is as I mentioned previously…
I do need to take a look at this, but my immediate priority is a new master release of openLuup, rolling up many recent (and not so recent) changes.
Among others which don't pose much of a problem I have an issue with a Fibaro Multi Sensor. The only element which seems to not be mirrored is the motion part which is rather crucial for a motion sensor ;-). Temperature, Lux level are working fine. A Aetec Multisensor is working perfectly with every single element being carried over as expected.
It’s all to do with the low-level Zwave device and sensor definitions. Different manufacturers do things differently. There are multiple ways to define things. Who said “the nice thing about standards is that there are so many to choose from” ?
Also, a Fibaro Roller Shutter is behaving strangely. I have two of these modules included, a very recent one with FW25.25 and a 4 year old one with FW22.22. The new one shows a dimmer element to change positioning as expected. The older one shows only a scene controller element, but nothing else.
Well, again, this is clearly a firmware difference. Any chance of updating the old one?
I have high hopes to use Zway and your plugin to finally step away from Vera completely without having to start from scratch in a completely new environment.
Me too.
Do you have any thoughts on the missing elements/devices the plugin seems to be skipping?
My best chance is to go ahead with my proposed changes to the Zway plugin. During development, I’ll simply be supporting two implementation files: the current one, and the next attempt. So you can easily switch between the two if there’s a problem.
please let me know whatever info you need regarding the devices which don’t behave nicely yet (log files from zway etc.)
And thank you so much for taking this on!
I finally got z-way up and running:
Question: is there an advantage in picking one the zway plugin vs the razb plugin?
In terms of device support?
In terms of refresh rate? Also vs the verabridge?
Now that I moved all of my zwave triggered automation to openLuup, I am often seeing slight latency in the triggering of the scenes.
My weekend project is going to run a controller shift from the vera to the uzb stick and then join the zwave devices back into openLuup unless there is a major drawback of the zway setup and plugin.
I am considering creating automation scripts on the zway to update openLuup rather than to wait for a poll. Not sure it is necessary.
[quote=“rafale77, post:97, topic:193746”]Question: is there an advantage in picking one the zway plugin vs the razb plugin?
In terms of device support?[/quote]
Different developers… both excellent 
In terms of refresh rate?
Not sure, but this is easily changed at some small expense to cpu and I/O load.
Also vs the verabridge? Now that I moved all of my zwave triggered automation to openLuup, I am often seeing slight latency in the triggering of the scenes.
There’s no interaction between ZWay and VeraBridge. The polling delay is a consequence of Vera’s data_request?id=status&MinimumTime=… HTTP request parameter. It can be changed but the impact here is mostly on Vera and it’s quite likely to crash more often.
My weekend project is going to run a controller shift from the vera to the uzb stick and then join the zwave devices back into openLuup unless there is a major drawback of the zway setup and plugin.
Very interested in the details of how this is done and how it goes. I’ve never done it myself.
I am considering creating automation scripts on the zway to update openLuup rather than to wait for a poll. Not sure it is necessary.
Can you clarify? You mean a script on Vera triggered by a variable watch?
Can you clarify? You mean a script on Vera triggered by a variable watch?[/quote]
Yes similar to it. Because I do not have plugins (except the site sensor plugins for the devices which do not need instant status) to poll home assistant and my Xandem hub, I am already doing the opposite: I have both send commands to openLuup to update status of virtual devices I created.
I am thinking about doing the same with Zway. I am not doing it on the vera but one could do it quite easily by creating a luup variable watch and using a function to update openLuup immediately the same way I am using the other 2 controllers. It could be done in the startup lua.
I understand there is no interaction between the 2 plugins but I did not know the poll rate was a variable one can change. Is it the same way on the zway plugin?
Shamefully, it’s hard coded on line 647 of the L_Zway.lua file:
luup.call_delay ("updateChildren", 2)Worth changing 2 to 1. In openLuup, luup.delay() can take a fractional parameter. Monitor the CPU load and see what it does.
I should point out that the ZWay plugin (and, I think I can speak for @amg0, the RAZB plugin) were fairly rapid developments done about 2 years ago, and really just proof of concept. They’ve not been developed recently, but pressure is certainly growing to change this!
1 Like