@akbooer
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.
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-WayZway 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.
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
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
55a457fe-101e-4cb7-bced-3693d9f280c4-image.png
e9deae5c-79f1-407b-adb7-718663ab0149-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?
Just wanted to point out and start the topic of the following:
We are working on a project that will allow to use Z-Way library as the core of Z-Wave in Home Assistant. First releases will be around June/July I believe
Additionally there are ways to support Z-Way from HAss via HTTP requests. This is a community project and we have no deep knowledge about it.
С уважением,
Полторак Сергей
Z-Wave.Me
Why would that make you reluctant? It doesn’t seem to be any different from any other local startup supporting funds in other countries.
Help with Z-Way plugin
-
I see this has a new device number, so if device #5 is still there, then delete it.
I'd like to see the startup log and the openLuup console page Scheduler > Plugins
It really, really, shouldn't be as much of a pain as this. I don't have a clear picture of quite how things went wrong in the first place.
-
@rafale77 said in Help with Z-Way plugin:
Did you check that the file exists in the /etc/cmh-ludl folder?
Actually, it won't be there. Only L_Zway2.lua is a physical file. All its other device files are part of openLuup's virtual storage system.
-
No, the problem is not openLuup, and openLuup is not like Vera. You simply don’t need to tear everything down and start again.
- verify that you have the latest openLuup system from the development branch. The Plugin page should show 20.5.3b, or thereabouts.
- delete any ZWay plugin device
- check there are no devices lurking in room 101 (delete them if they are)
- install ZWay once again from the master branch, from the (Alt) App Store.
- send me a Startup log, so that I have something to go on.
- don’t forget to login to the ZWay plugin using the Login action of the plugin.
-
Yes, I did. So you have the latest openLuup and ZWay plugin now.
You need to login in to your ZWay system through the plugin. If you go to the ZWay device control panel (by clicking on its icon on the Devices page) you will find the Actions menu (in blue) and there, right at the top, should be the login action. You need to enter your ZWay system admin username and password and then press the blue Login button.
Returning to the devices page, you should see that the ZWay device is suggesting an openLuup reload. Do that.
-
No, this is all my fault. The original ZWay plugin was prototyped four years ago, but in the last six months , with the way Vera was going, we ( @rafale77, @DesT, and some others) had a bit of a push to revive it and make it really functional. In the process, of course, documentation was not done.
My fault, too, that when you said
@JMK said in Help with Z-Way plugin:
On the same Raspberry Pi3 I have installed openLuup on which I have installed the Z-Way plugin.
...I assumed that it had all gone according to plan.
So now you see your Fibaro switch, and it works...?
-
Yes, I can see the Fibaro switch and I am able to toggle it. The reason I am going through all this is I also have just about had enough of Vera. I had small configurations (10-15 devices) at two locations that had worked flawlessly for 6 years on Vera3s when it looked like support for the Vera3 would end because of EOL I decided to migrate to VeraPlus. Big mistake. Devices dropping offline, scenes behaving strangely (triggering when they shouldn't, not triggering when they should). At the remote location I had to spend over $200 dollars to replace devices that had worked perfectly on the Vera3, and so on...
Because I cannot afford to loose the automation here locally I am transferring one device at a time from the VeraPlus to the openLuup system - that's my plan anyway.
-
I updated my Z-way plugin to the latest Maser version (v20.4.5). In order to get the plugin to get updated I had to delete the existing Z-way plugin and start over. I had a really old v18.7.16, however it was working ok. I am on OpenLuup20.5.6, so that should be ok.
I now have the latest version of the Z-way plugin, but I need to change IP from the default 127.0.0.1 to the right one (192.168.1.xx), on which my Z-way is running (not the same as my OpenLuup). However when I try to change IP via the "Variables" tab it does not stick, it reverts back to 127.0.0.1 after Luup reload. I have tried both via AltUI and via the OpenLuup (unsure where I should do this) but get no result either way.
Any ideas?
//ArcherS
-
I had a disaster yesterday - my Raspberry Pi SD died and looking at it i think it may have been a Sandisk fake, the labeling and fonts just do not look right. Anyway, I had to re-install Z-Way, openLuup... and this time I decided to put cmh-ludl in etc rather than in my home directory. I noticed that in the manual it says "be careful with permissions". So what are the 'correct' permissions? As you can see I am not too familiar with Linux
