Since a couple of weeks/months, we are in the process to redo 5 rooms @ home (kids are moving from room to another room) and of course, I would need to redo a bunch of device name and room name in Zway..
Is there an easy way to tell openLuup to completely start over fresh without having to delete/rename them one by one in openLuup ?
I hope this is the correct forum – apologies if not!
I have a Raspberry Pi3 with a Razberry Z-Wave card installed. I have installed the Z-Way software and have successfully included a Fibaro Z-Wave switch on the Z-Wave network. I can toggle the switch on and off successfully from my laptop through port 8083 of the Raspberry Pi3.
On the same Raspberry Pi3 I have installed openLuup on which I have installed the Z-Way plugin. I can access this through port 3480 on the Raspberry Pi3 from my laptop.
Here is where I have come to a dead stop. How do I get access to the Fibaro Z-Wave switch from the openLuup application? I can find no documentation that tells me specifically how to do this.
Any help would be greatly appreciated.
_John.
Master Branch: 2020 Release 4.5
Roll-up of recent changes in development branch.
I have an odd issue which seems to be only for Fibaro wall plugs. They come in to Z-Way with two "electric meter" entrys, one "Power" meter and a couple of alarm entrys. In addition to the switch that is.
One of the "electric meters" is KWh and the other one is seemingly Watts, but it stays at 0/-1w. The "Power" meter shows the Watts used right now.
When these come into openluup, the wrong electric meter is selected for displaying the Watts, is there any way to manipulate which one openLuup uses? I see that the sub channel for power also is transferred, but it isn't in the data Veraflux is transmitting to my influxdb..
Haven't used the watts reading for anything before now, now i want to estimate when my dryer is done based on power usage. 🙂
Having some trouble getting the Fibaro TRV device working with the ZWay bridge. The device works in the ZWay (Zwave.Me) Smart Home GUI, and creates a number of devices in OpenLuup, some of which appear to have the right variables in it. Changing the XML and JSON files makes no difference.
I also tried creating a separate child device for Parameter 67 (using the gui for the ZWay bridge, see below), and setting the XML/JSON types for that device (like I've havd to do for a few other devices). This results in a device that correctly displays the TRV setpoint, but chaning the setpoint in the OpenLuup gui does not result in anything being transmitted to/by ZWay.
20490 49-0 D_ComboDevice1.xml zNode #49-0
49-0-113-8-12-A
49-0-113-8-13-A
49-0-113-8-14-A
49-0-113-8-15-A
49-0-113-9-3-A
49-0-64
49-0-67-1
20491 49-1 D_ComboDevice1.xml zNode #49-1
49-1-113-8-12-A
49-1-113-8-13-A
49-1-113-8-14-A
49-1-113-8-15-A
49-1-113-9-3-A
49-1-64
25031 49-1-67-1 D_Heater1.xml Radiator Bedroom
20492 49-2 D_ComboDevice1.xml multi #49-2
49-2-113-8-10-A
49-2-113-8-11-A
25030 49-2-49-1 D_TemperatureSensor1.xml Radiator Bedroom
I expect this document to be dynamic based on inputs from people who try but did not want to completely rewrite it here:
Z-Way/README.md at master · rafale77/Z-Way
Z-Way/README.md at master · rafale77/Z-Way
Zway plugin for openLuup . Contribute to rafale77/Z-Way development by creating an account on GitHub.
Nearly there with the migration ..
Is it ok to use older device files or do they get updated from time to time?
Now that a fresh openLuup is up and running and connected to Zway where's the best place to source device files without vera? I probably have them on another openLuup install but not 100% which ones to copy over.
One of my wall plugs died yesterday, so i had to delete it without exclusion. When I did this, the openluup device switched to this:
7d1a5d39-cfdd-4c25-b2a2-79311736615f-image.png
And some .js issues arrived at the bottom of the screen:
1935b845-ea64-4576-8d40-04489ae10fb8-image.png
What to do?
I've finally gotten the stuff to work together. Now - before I migrate all the vera devices, how do i use this?
How does the variables NameDevices and CloneRooms work? (is there a manual or description of the plugin?)
CloneRooms seems obvious, but is that the best way to go when I have more bridges?
I have an old Z-wave.me wall controller that I still use for turning the espresso machine on and off. The controller controls an Aeotec Micro Switch that for the moment is still on my Vera.
The wall controller has always been a bit tricky to work with on Vera. On my old UI5 VeraLite I managed to get it associated to the switch.
On the UI7 Vera I never got that to work, instead I could use it as a trigger in Reactor to detect when sl_SceneActivated was 1 or 0.
I have moved the wall controller to Z-way and there it is included as it should.
a30b06dd-1f3c-4ca6-9966-b0a6f183de04-image.png
Compared to when it was connected to the Vera it has proper on/off buttons so that it can be controlled from the Z-way GUI.
The command classes are the following:
68a54e6b-b240-40b2-95bb-9696bf7789cf-image.png
In OpenLuup it still shows up as it did in the Vera, i.e. only showing battery.
985acfb7-6af9-4cf0-a426-79d4358baf6e-image.png
Is it possible to change device type so that it get the right properties in OpenLuup?
At the moment it does not have any useful properties except for battery level. It e.g. lacks the sl_SceneActivated variable.
Another step would then be to move the Aeotec switch to Z-way and to then associate the wall controller to the switch in Z-way. It seems as if this can be done in the ExpertUI.
//ArcherS
If a zway device have been manually deleted in openluup, What would be the right way to recreate it, or re-sync with the z-way-server?
Just finished migrating to Zway, Although there are some devices that are being detected as a dimmer when in fact are Shutters.
What would be the best route to properly change how this devices are being detected by the ZWay plugin on openluup?
2f2566ba-1bb8-436e-a107-363bb66a7436-image.png
1a188194-faed-4d5c-8dc8-7a21914209fb-image.png
Hi AK,
I must be missing something but I am having now some devices fail on the bridge due to them running out of battery. Upon battery replacement, they function properly on z-way-server but the failure remains over the bridge. The failure shows up on the parent device and it says that a specific command class has failed. Looking at the return API json, it should not return any command class level failure however so I am not sure where the bridge gets its failed state from...
edit: Nevermind, I figured it out. It is a gap in data alignment between the different z-way APIs. The zwave and JS API got the update that the device recovered but not the smarthome API. Pausing and restarting the zwave app on z-way fixed it.
I noticed the change when I switched from the RaZberry to UZB (During the switch all devices moved to the Room 101 briefly, maybe that had something to do with it). Any idea why this would have happened? Can I easily change them all back to enabled? Also, what exactly does this attribute do? I only noticed because none of my z-wave devices were showing up in Imperihome and when I set the "disabled" attribute back to 0, the device shows up. Thanks.
So I started experimenting by moving some of my wallplugs and power switch zwave devices over from VeraPlus to Z-Way.
In Z-Way this results in different elements for switching, Watts and kWh. Some even have Volts which I never saw on Vera.
But using the Z-Way plugin in openLuup only the Switch element is visible and all other elements of the zwave node are not.
I don't really know to much about Z-Way or the plugin, but am trying to learn on the run.
Maybe someone can give me some pointers what and where to look for to solve this?
Why Migrate to Z-way from vera and how?
-
@rafale77 said in Why Migrate to Z-way from vera and how?:
not too different from renumbering your devices on openLuup except maybe for it to be more intuitive
Couldn’t be easier to rename your devices in openLuup, using the console’s Device Table page. Simply type the new name into the boxes...
-
Ahhh yes the console makes it much easier. The challenge though is to go back and rewrite all the scenes and index devices according to their names instead of device ids.
I just did something in the same idea and was really missing a search/replace for the lua code content of my scenes. I used luaview which was very helpful in reading the code but it is missing the search/replace. Would be a nice feature to add to luaview. @toggledbits.
-
Not sure where to run Zway bridge from - the openLuup system doing all the logic (where the current verabridges are) or on the new rpi replacing vera? Both? Perhaps I won't need openLuup on the vera replacment if it doesn't do any logic?
-
I've run ZWay perfectly happily on an RPi (actually, a Razberry) with the ZWay bridge running on a separate openLuup machine. Equally, I've run them on the same machine. In fact, you can do both simulatneously (ie. with openLuup and ZWay plugin on both machines) if you like!
-
It is either or. Not both. You can decide depending on your hardware. I have done both as well.
My view on pros and cons.
Running zway on the same system as openLuup:
-The z-way bridge runs locally and since it is polling based, you can make it poll at a very high frequency without adding a lot of traffic to your network.
-downside is that you need to setup ser2net/socat which is a little more work. I tweaked my systemd z-way-server command to restart socat every time z-way-server restart to make it a little easier.Running z-way on the remote device... all the above reversed. It also means that the remote device would be a little more powerful. It also means that you will have to maintain 2 systems more often. Not a big deal really but something to keep in mind.
I have opted for the first solution and my remote "Z-host" has not been rebooted in 9 months! No maintenance needed. It is powered by a POE injector and is a passively cooled celeron mini PC running debian consuming a constant 4W. -
@rafale77 said in Why Migrate to Z-way from vera and how?:
It is either or. Not both
To be clear, the UZB can only be on one machine, of course, and the https://z-wave.me/ software. However, you can run multiple versions of openLuup and the ZWay bridge on a number of different machines, including the one on which the ZWay server is running, all accessing the same server.
-
Have a few zwave networks so would need to run zway on the remote device(s) and gradually replace the verabridges with zway bridges. Eventually three UZBs on different machines with their own zway server all controlled by a central openLuup. Perhaps similar to how my veras are operating currently.
Then I read zway can run multiple UZBs! Would the ser2net/socat route work for multiple UZBs with one controller - and make for easier maintenance?
-
@powisquare said in Why Migrate to Z-way from vera and how?:
Then I read zway can run multiple UZBs! Would the ser2net/socat route work for multiple UZBs with one controller - and make for easier maintenance?
...I have NO idea!
-
I just took a good look at it and no it doesn't seem like a z-way-server instance can support multiple zwave radios. You will need one instance of z-way-server per radio so your approach is correct... running the z-way-server on the remote unit with multiple z-way bridges is the way to go.
-
Thanks guys - just one more thing ; ) If I install say a reactor on a remote device running zway server and openLuup - will my central openLuup see this as a device or does the zway bridge only talk to the zway server.
-
Thanks for the heads up on that. Strangely, the forum software seems to have converted plain text to a URL link (to a non-existent domain, so I ended up with a web hosting service offering to sell that domain to me!)
Anyway, it's fixed now, and I edited your quote above to remove the link too.
Thanks again
-
Hey guys, I am just tired of the Vera Z wave setup I have too many devices falling offline randomly and almost all my lock's states are incorrectly reported. Though my network is fairly fast I want to move to something a bit more reliable. I don't want to go the full route of OpenLuup + Z way yet, but I would like to go just the Z way route.
If my understanding is correct Z way is just a Z wave dongle that handles all the z wave tasks, and once configured properly the Vera will still be able to see all these Z wave devices but it just wont be directly controlling them .. instead going through the Z way?
-
Hmm not quite. I was hoping my github readme would be clear enough but apparently not.
Z-way in really meant to be a competing platform to the vera supporting zwave only. It can be made to run all automation etc... They just don't sell a hub. The hardware they sell is only a usb zwave stick (the zwave.me uzb) or a raspberry pi HAT (the razberry). It means that you need to supply your own hardware to run the software. I found it to be relatively easy to migrate my vera zwave network to their uzb stick and then found that the device configuration on the z-way-server software was much easier and transparent than what happens on a vera. This however does not migrate your scenes and plugins. It only migrates the z-wave mesh. The vera cannot control that mesh anymore but potentially you could look at the plugins on z-way to reproduce what you had on vera and redo all your automations on that platform, assuming that you only have zwave devices.
That's not what I and a number of others did. Instead, many of us had already offloaded our plugins and automation to openLuup, a different machine running a luup engine which then connects to the vera, treating the latter as a device hub only. All I did was replace the vera with z-way, switching from the verabridge to z-way bridge. My reason for doing it this way is also because I was heavily invested in vera plugins and scenes and didn't want to start from scratch.
I think the first step to improving reliability on your vera is indeed to get yourself another small machine (I recommend a cheap mini PC based on a celeron for example, I posted links to a few $30 ones on ebay), install a version of linux and openLuup on them and start migrating all your scenes and plugins on it. @akbooer built a number of tools to make it relatively easy to do. This will alleviate all the problems associated with luup reload causing scenes and plugins to go out of whack. It won't however fix zwave network specific issues. You can then run your vera that way for some time and see if it yields satisfactory reliability for you.
Alternatively, before I migrated all my controls to z-way, I started by using z-way as a diagnostic and correction tool on my zwave network. To do this, I included it as a secondary controller to the vera and I would go fix some device configurations in ways the vera would not allow me to.
-
@rafale77 Ah okay that makes more sense. So basically I cannot use the USB stick itself as a the primary Z wave controller for my Vera.
The thing is I am only really have issues with my z wave network, surprisingly my Vera runs pretty well I only get a LUUP reload maybe every 6-7 days. I guess if I do move to OpenLuup it could help with my network since my Vera isn't handling any plugins anymore.
I think I had it backwards, so the possible configs are
Vera (Z wave device hub) - OpenLuup (plugins and automation hub)
or
OpenLuup (plugins and automation huub) - Z way (Z wave device hub)
-
@pabla said in Why Migrate to Z-way from vera and how?:
@rafale77 Ah okay that makes more sense. So basically I cannot use the USB stick itself as a the primary Z wave controller for my Vera.
Actually you can! But that doesn't buy you anything. The problems with the vera is not the hardware. It's the firmware. There is fundamentally nothing wrong with the hardware. My research actually led me to discover than a german company is running the z-way library on a custom firmware on the same hardware as the vera plus quite successfully. I was curious as to why z-way had somehow a ramips (the hardware platform of the vera) release of their software. But I digress.
Yes you understand it correctly now. Migrating all your scenes to openLuup, if you don't have any plugins, would prevent your scenes from being interrupted by luup reloads and potentially extend the interval between luup reloads. openLuup just doesn't crash on its own. Doing it this way I had intervals of 16-20days between luup reloads. The next step is z-way which never crashes.
-
+1 for zway
-
Just chiming in about z-way. I've used it for a good while now, and my only issues have been with functionality that vera never had anyway, and mostly due to my own settings.. Finding the expert panel, and the sheer amount of adjustment possibilities and overview you get of your network was quite a revelation compared to the more "dumbed down" z-wave settings in vera. And it just works, haven't had a crash yet!
The smarthome UI still needs some work to be good in my opinion, but thats a more subjective thing i guess.
-
Yeah the UI is not that great... if you have openLuup/ALTUI, there is no reason to use it. I avoid running anything on that API actually and it is important to understand the original philosophy behind that UI... It was a demonstrator of how one could use the Smarthome API to create an interface and their purpose was to sell the library and the API for other hub/controller to test the capabilities. It has become more over time. There are definitely some quirks/incomplete things. One that comes to mind is the fact that "remote access" is not supported on non ARM platforms... but I don't need or want it to begin with.
Quite a game changer to never have to worry about luup reloads and having to check / maintain the zwave network, looking for communication failures etc... isn't it? Battery operated devices have also seen a dramatic increase in lifetime. My Yale doorlocks for example went from a 6 week average battery life to 10 months. My zooz/monoprice 4 in 1 sensors have gone from 3 weeks to over 1 year... including one I am keeping outdoors. Granted the modifications on the latest vera firmware managed to double-triple the lifetimes but this is just something else...
