As does mine, although I am using a Razberry board.
I do have a UZB too, but couldn’t get it to work on my BeagleBone Black (my main HA controller.) I’ll be trying it again sometime on a new RP4.
On the beaglebone… it is likely a platform problem. A bunch of new platforms showed up on the compilation list. The rPi is a little particular and a more generic armh is offered now. After fiddling with all these arm boards at ~$50 a piece, I just decided to go with something much more powerful and easier to support long term by going x64 for $150. Unbrickable, much easier on storage and OS support etc…
I just found my ZMEUUZB1 ill probably look into purchasing the license soon and do have openluup running on my unraid server in a docker. and also HA but I haven’t been using them much
@akbooer Are you handling the device name from zway now ? I mean, if I renamed a bunch of stuff, are you getting the new name ?
Currently, the device name is copied from ZWay when the device is initially created… thereafter, it’s independent.
Could be done differently, but that’s how VeraBridge works too.
Right now in Verabridge, when I renamed a device in Vera, it get renamed in openLuup btw! Never got this issue with verabridge!
OK, yes, you’re right. I can make ZWay work the same way.
I would be very careful and especially more precise about this because z-way handles names on several layers unlike the vera which only exposes the virtual device layer:
The stable constant layer on z-way is the “expert UI” which has a device list and information by node.
The vera does not expose the equivalent of this layer on the GUI.
The problem is that when you rename nodes on the EUI layer, the name is not transferred to the virtual device layer. The only way to know what the virtual device refers to is by looking at the node number inserted as a suffix to the name.
The issue with this virtual device layer is that, like the vera, devices get added and removed according to interviews (similar to vera configurations) so it isn’t a very stable list. Every time a new interview is done, the device gets deleted and readded and its name gets reset. So I would recommend to pick up the name from the EUI API and to not update it unless the bridge detects that it needs to create a new device. The Smart Home layer is much too flaky to rely on for naming.
@akbooer thanks 
@rafale77 I rename all my “node” in the expert mode AND I also rename all devices in the other interface with all the childs too!
So for me, I will prefer to have the name I put on the non-expert interface so all the child will have the name I choose…
Yes I did that too but this is the issue: If you go back reinterview a node… the Smart Home device gets renamed back to “manufacturer-device_type-(node)” format. I would not even spend any time renaming devices in the Smart Home layer.
Maybe, but it will be a pain to have all the child with just the factory default name as “manufacturer-device_type-(node)” … I would prefer to rename them again and have “my” name in openLuup!
Interesting.
When I try to rename a device in Starthome, I get:
Smarthome - UI ERROR
Unable to update data
However, the virtual device name DOES change on their UI, and also in the reported vDev data from the API.
I have just updated my prototype ZWay2 to follow ZWay device name changes on the fly (no restart required.) It seems to work fine… (very cool, in fact.)
…but perhaps said too soon? I am loathe to restart ZWay to try this, but perhaps they do all get reset? What’s your experience here?
1 Like
Ok I ran a test on my zway:
- Rename a virtual device (I get the same error as you do but the name actually changed as you reported)
- Run a forced interview
- Observed the virtual device move from it’s location to the bottom signifying that it got reconfigured/recreated.
- The name sticks.
I did this on both a battery operated device and an AC operated one.
So I stand corrected. The virtual device does get deleted if the interview does not complete but when it does complete, the old name comes back and does not get reset. It is much better done than on the vera I have to say so I was wrongly presuming that the name would get reset.
It is worthwhile to get the name from the smart home layer and to update according to it.
1 Like
Zway has been up for over 10 days now without any interruptions in spite of me fiddling with a couple of device configurations. No memory leak. On Friday, I will be swapping the controller node ID with the vera and make the vera the secondary for a one day test to monitor zwave command queue behavior as primary.
I still have not heard back from my vera tardy logs I sent weeks ago and am getting delayed events every time my house gets a little more activity… Time to migrate.
If you want, I can also be a beta tester and switch over to test as I’m having issue with my vera and looks like Customer support are not working very hard on that issue!
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…
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…