-
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. 🙂
-
What's the "logic" behind zway plugin about renaming ? Are you always renaming when starting openLuup ?
-
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 -
@akbooer, I just woke up to a z-way bridge token expiration again forcing me to login again and reload openluup. It appears to happen once a week. It doesn't appear that the auto renewal of the token is working?
-
I expect this document to be dynamic based on inputs from people who try but did not want to completely rewrite it here:
rafale77/Z-Way 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.
-
Master Branch: 2020 Release 4.5
Roll-up of recent changes in development branch.
-
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.pngAnd some .js issues arrived at the bottom of the screen:
1935b845-ea64-4576-8d40-04489ae10fb8-image.pngWhat 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?)
Set up rooms and names in Z-way? No rooms in z-way, and distribute them in openluup?
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
-
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.
-
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?
-
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.
С уважением,
Apr 19, 2020 Official Z-way integration request Official Z-way integration request
Полторак Сергей
Z-Wave.MeWhy would that make you reluctant? It doesn’t seem to be any different from any other local startup supporting funds in other countries.
Why Migrate to Z-way from vera and how?
-
I expect this document to be dynamic based on inputs from people who try but did not want to completely rewrite it here:
rafale77/Z-Way
Zway plugin for openLuup . Contribute to rafale77/Z-Way development by creating an account on GitHub.
-
Ahhh I was going to suggest this as a topic. Almost tempted now as I have some time on my hand but....
C
-
What is holding you back? We are here to help!
-
WAF more than anything else, plus time and hardware
And I do know you'll help!
C
-
WAF is exactly what forced my hand... couldn't stand the maintenance and random delays/failures anymore.
It does take time (short heavy investment for long term greater return) and some hardware though.
-
I'm not furloughed, and have a couple of new projects on the boil, so don't actually have a great deal more time than before (and my students still want on line classes so even my evenings are used some of the time)
<Touches wood> Currently my set up is stable. Would love a gradual migration. I can buy the kit but it seems a bit big bang.
C
-
So to get this straight in my own mind can I
- Go buy a Pi 3 B+ and SSD
- Install Debian / OpenLuup / Reactor
- Make the Vera Z-wave dongle available to OpenLuup
- 'Migrate' all my reactor instances 'off' Vera onto the Pi
- Use the Pi to create and new Reactors and replace the final couple of scenes I have
- Then think about migrating all my devices to a new Z-wave hardware.
Trying to make this a small steps as possible
Cheers
C
The Ex-Vera abuser know as CatmanV2.....
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
- Make the Vera Z-wave dongle available to OpenLuup
If, by this, you mean using openLuup's VeraBridge plugin to access its existing ZWave devices, then, yes, I think you have the sequence correct.
It sounds like a lot of steps, but they're not too difficult... I know almost nothing about Linux / Debian, but seem to have managed thus far.
AK
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
So to get this straight in my own mind can I
- Go buy a Pi 3 B+ and SSD
- Install Debian / OpenLuup / Reactor
- Make the Vera Z-wave dongle available to OpenLuup
- 'Migrate' all my reactor instances 'off' Vera onto the Pi
- Use the Pi to create and new Reactors and replace the final couple of scenes I have
- Then think about migrating all my devices to a new Z-wave hardware.
Trying to make this a small steps as possible
Cheers
C
Pretty much the exact steps I took. Steps 1-3 I had done maybe a year ago. At that time most my logic was in Pleg so I needed to move everything to reactor. Step 4 was the decision maker to completely ditch Vera. Once I did that, no more vera reloads where I was left in the dark because some logic did not execute or a light did not turn on. Step 6 I just did over the past 2 weeks and is well worth the effort. I feel like I have control over my z-wave network now with the "expert ui" of z-way.
-
Thanks. So can I backup Reactors from Vera and restore to OpenLuup?
C
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
Thanks. So can I backup Reactors from Vera and restore to OpenLuup?
C
Yes. But you will have to manually change the device numbers of devices used in the Reactors. For example, device 25 on vera will be 10025 on openluup through the VeraBridge. Then again, with z-way, the device numbers will change. Z-way uses node # so If device 25 on vera has a node ID of 12, its z-way device number will probably be 20120.
-
I've not switched yet, but I was thinking about a script that could:
- get the device ID from the Vera (using nodeid and parentid)
- alter the device number in openluup+Zway, in order to reflect the old number
- migrate scene accordingly
I'm running openluup+Zway (as secondary) since a couple of weeks, and this should be doable, from my finding. I just have to figure it out a plan for scenes.
-
To move from vera bridge to zway, I wrote a script that retrieves the backup reactor file, finds all devices that are referenced in the 10000's, determines there node ID#, generates z-way device numbers in the 20000's based on the node id, and provides a new reactor backup file with the 10000's replaced with the new 20000's. It worked pretty well and saved me a lot of time. Some devices were not fully correct as child device numbers do not seem to be standard. I will share if somebody wants it but I am hesitant because it is not full proof and I am not an expert in lua.
-
There is a built-in VeraBridge GetVeraScenes action which migrates scene timers and actions (not triggers) changing the device numbers accordingly.
-
@akbooer the pain for me is in the triggers, since scenes are mainly calling code with an indexed table for devices. I could probably just migrate them to variable watches before. We'll see.
I've been using the new openluup console and I must say I like it a lot!
--
Vera+MQTT+HomeAssistant+my own framework all orchestrated via MSR
70+ Zwave Devices, a bunch of ZigBee light strips and a lot of codeMy Luup Plug-ins => https://github.com/dbochicchio/vera
-
Well all my temperature sensors dropped out again last night at about 2120 local. I should have worried when I got a 'Device is responding again' notification for the Fibaro Universal when I never got one that it wasn't responding.
It sounds like simpler might be:
- Buy the Pi and the SSD
- Install Raspbian, Openluup, Z-wave bridge
- Restore and edit reactors
- Kill all the remaining scenes (for me this is probably not an issue and in fact would be a good place to make sure Reactor is working on Open luup)
Now at that point, vera is doing really nothing at all other than accepting Z-wave commands from OpenLuup?
C
The Ex-Vera abuser know as CatmanV2.....
-
@therealdb said in Why Migrate to Z-way from vera and how?:
the pain for me is in the triggers
Yes, I know. I never implemented the Vera-style triggers because their implementation was so flawed (along with the definition of events, etc.) AltUI Device Variable Watches work fine, but migrating the would require some editing of the WatchedVariables AltUI data structure (and it hardly seems worth it.)
I've been using the new openluup console and I must say I like it a lot!
Thanks for that – glad it works well for you! I have a plan for native openLuup triggers (easily defined from the openLuup console.) Their implementation is the main area where openLuup is deficient (along with the real-time updating of the devices page, and ...)
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
Now at that point, vera is doing really nothing at all other than accepting Z-wave commands from OpenLuup?
It's actually still using the Luup layer to translate between HTTP and ZWave commands, but in this mode it seems to stay up for reasonable amounts of time. You'll still suffer from the fundamentally flawed ZWave stack implementation, though, as I'm sure @rafale77 would agree.
-
Hmmm so only a partial solution.
Razberry or USB? Razberry is about half the price and would fit nicely on the Pi?Any other benefit to the dongle?
C
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
Hmmm so only a partial solution.
Razberry or USB? Razberry is about half the price and would fit nicely on the Pi?Any other benefit to the dongle?
C
Check out this post with some discussion.
