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?
Changing device type for wall controller
-
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.
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:
In OpenLuup it still shows up as it did in the Vera, i.e. only showing battery.
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
-
Hi,
Yes the variable "zway_Remote_16-0-1-B_LastUpdate" changes when activating the wall controller.
In HomeWave using a 3-value control you can also see that it represents date and time for each change correctly.Also "zway_Remote_16-0-1-B" changes, it toggles between "on" and "off".
//ArcherS
-
I had a very long PM conversation with @DesT in the other place discussing how to use controllers like this on ZWay/openLuup.
Aside from a string to specify what scene to run, what doesn’t it do for you (OK, no switch.)
A way to use this as it stands is to create an AltUI scene with a device variable watch on either the date or the state variable. But with a bit of code change in the plugin we might be able to do better. The problem is not to compromise other devices which also present in this manner. Given that you’d be writing a scene, there’s no need for the device itself to actually have a switch (because you could run the scene directly.)
-
@akbooer Yes a scene or a Reactor could of course work. This is what I did on the Vera in a Reactor and it worked quite ok. I will give it a go again in OpenLuup. The on/off switches on the controller in the GUI do not really matter that much I think.
Regards
//ArcherS -
@therealdb Thank's, I will have a look at that.
//ArcherS -
Hmm, when looking at this again after another day of working from home as most of us these days, something strange seems to be going on.
I created a Reactor to test the two variables and to get them to update as they should I have to restart the Reactor. I tried them both as conditions and as expressions, e.g:
getstate( 30160, "urn:akbooer-com:serviceId:ZWay1", "zway_Remote_16-0-1-B" )If I do not restart the Reactor the variables stay not updated. Just to double check I changed the condition in the Reactor to "on/off" for a wall plug that is included in z-way and then it works the way it should.
The same when looking at the variables via the Variables tab for the wall controller they only update after a ctrl-F5 refresh.
I tried to create a scene with one of the variables as "watch" with "(old==off)and(new==on)" as expression, but I could not get it to work. Unsure if the expression is correct to be honest.
So I guess I have to alter my answer to the question if the variables updates, sorry for the confusion. Any ideas on what could be the problem?
//ArcherS
-
Ah yes, I think know what that is. Those variables are actually set 'silently' so don't (shouldn't) appear in the log. They are, in fact, only there to help with testing the plugin. Actual, Vera-like device variables should, if the device is correctly configured, appear with proper serviceIds and names, from which you can trigger.
We have two options:
- I can try and tweak the device configuration code
- I can make those variables trigger.
I'll take a look.
I assume that all you need is a variable from which to trigger, but do you have a list of the variables that such a device on Vera creates? By way of comparison, one of my 4-button Aeotec miniMotes shows this:
-
@akbooer sorry, no I do not have a complete list of the variables created in Vera. I forgot to check that before excluding.
By the looks of the controller I am quite sure it is the one in this old Vesternet guide APNT-44
In fact if I remember it correctly that guide is what I used on my VeraLite on UI5 many years ago.
On the UI7 Vera I however used "sl_SceneActivated".
I also think that "LastSceneTime" was present on it. (These represent the "zway_Remote_16-0-1-B" and "zway_Remote_16-0-1-B_LastUpdate" at present I assume.)You are correct that all I would need are those two variables as triggers, because then I can use the on/off as one trigger and the time as a trigger as well. I think I may need the time to capture e.g. if you press the "off" button and the controller already was "off". I tested this and the time is updated.
Thank you very much for your time and effort.
//ArcherS
-
-
@ArcherS said in Changing device type for wall controller:
It has been a bit finicky to work with over the years with Vera
It was the very first device I paired with Vera, and, indeed, the reason I got Vera (although I subsequently set a direct association to another switch...!). It was a nightmare to get going, but has served me well for around 7 years. Probably still one of the most-used switches I have.
The batteries are weird. I have to chop up a small 9V cell to give me six of them.
Happy days.
-
Yes unusual batteries, AAAA type. They are a bit rare, you can buy them in some places here in Sweden. Creative to chop up 9V cells, I will try that next time they run out.
It was significantly easier to include into Z-way than into Vera anyway... To be honest most devices so far seem to be.
-
You should find that the latest ZWay plugin development branch v20.5.12 fixes this by giving you a scene controller just like you had in Vera.
I haven't been able to test it independently (my device of that sort is currently firmly attached to my Vera ZWave network) but it shares code with other scene controllers, so should (might?) be OK.
You will need to delete that specific ZWay plugin child device so that it is recreated and configured correctly after an openLuup restart. As usual, this should take almost no time at all.
AFAIK, it should raise no problems with existing device configurations.
-
Now it works!
I created a Reactor that uses the two variables "zway_Remote_16-0-1-B" (for on/off) and "zway_Remote_16-0-1-B_LastUpdate" (for the time the wall controller is pressed).The Reactor has two conditions for triggering "on" and two for triggering "off". This is to handle the case that the wall controller e.g. could be in "off" when I want to turn the Aeotech Switch off (e.g. when I have turned it on from HomeWave directly).
To make this work I created two expressions "TimeAtOn" and "TimeAtOff" in which I store the time when the controller state changes from on->off and vice versa.
Just as a note, I also checked the variable "LastSceneTime" and it also gets updated with the time stamp. The variable "sl_SceneActivated" however always remains "null" for some reason. I do not know if this is intentional or not.
Thank you very much for your time and patience!
//ArcherS
-
Glad it works!
I have definitely only done a partial job here. My goal would have been for you not to have to use either of the zway_Remote... variables. The sl_SceneActivated variable is blank because the switch doesn’t present a scale variable. I could set a default of 0 or 1 for example.
I’m not a Reactor user myself, so that all looks beyonds me. In fact, my normal modus operandi is simply to use scene controller buttons as toggle switches, so on/off state is not an issue.
