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.
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.
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?
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
Why would that make you reluctant? It doesn’t seem to be any different from any other local startup supporting funds in other countries.
Z-way token Expiration
rafale77 last edited by
Need to make sure that it is the token issued to openluup and not to your browser. There should be as many as login sessions you have opened in the past week. Then you need to figure out whether the "no expire" indicator is actually on or off. It isn't the most intuitive.
Given my experience with it, it works perfectly fine so I doubt there is a problem with the z-way.
i think i was, the token i put "no expire" on had the name "LuaSocket 3.0-rc1"..
Its definately not intuitive, no.. and you may find out that you have to push the button, but you also have to press "save" on what seems to be the table of settings above the connection table.. well, we'll see if it sticks this time!
It sticked for over a month, now i'm suddenly thrown out again.. @akbooer: I see in the log that the bridge knows its not logged in (says so in the reply to commands), could you set a variable for this, so reactor can be set up to notify me when this happens?
Seems to be an issue on the z-way side..
rafale77 last edited by rafale77
I'm pretty sure it was there, and there was still "not logged in" in the log.. two days since last luup reload (added some sensors)..
Further to your request for a variable flag, there already is one, of course...
DisplayLine1shows "Login required", then it's lost the token.
I'm pretty sure it didn't, and "commfailure" was zero as well? Thats why I went to the openluup log to find out what had happened.
I'll see if i can reproduce this state..
Confirmed. If I remove the active session for AltUI in Z-Way, i get this situation.
2021-01-13 16:51:01.685 luup_log:198: ZWay: http://127.0.0.1:8083/ZAutomation/api/v1/devices 2021-01-13 16:51:01.686 luup_log:198: ZWay: Not logged in 2021-01-13 16:51:01.686 luup_log:198: ZWay ASYNC callback status: 401, #data: 13 2021-01-13 16:51:02.722 luup_log:198: ZWay: http://127.0.0.1:8083/ZAutomation/api/v1/devices 2021-01-13 16:51:02.722 luup_log:198: ZWay: Not logged in 2021-01-13 16:51:02.722 luup_log:198: ZWay ASYNC callback status: 401, #data: 13
No visible "not logged in" in GUI, and commfailure is 0?
Yes. It’s only set at startup.
Ok, and to update DisplayLine1 when the openluup log is told "not logged in" should be an easy fix? I'll see if i can do it myself.
@akbooer, Is this the correct way to get DisplayLine updated if 401 is replied for a command?
Line 1761 in L_Zway2.lua:
function _G.ZWay_async_callback (status, response) local delay = POLLRATE debug ("aync callback size: " .. #(response or empty)) if status == 200 and response then local d = json.decode (response) local vDevs = d and d.data and d.data.devices if vDevs then updateChildren (vDevs) end -- delay = POLL_MINIMUM end -- yes, ask for another one soon... -- init = '' -- ... without initialising data version elseif status == 401 then setVar ("DisplayLine1", 'Login required', SID.AltUI) else luup.log (log: format (status or '?', #(response or ''))) end luup.call_delay ("ZWay_async_request", delay, '') -- schedule next request end
There's a few problems introduced here:
- there's also a synchronous request which perhaps need to be changed as well
- you've lost the output to the log in the case of 401
- it doesn't change the CommFailure variable or device status
Although I suggested it as a quick-fix, I don't think that useing the DisplayVariable is a particularly good way of flagging the error to a scene trigger (CommFailure would perhaps be more appropriate.)
Is this still an ongoing issue for you (ie. are you losing the credentials on a regular basis?)
No, haven't seen it since i mentioned it here.
I agree that commfailure should be set, and as long as something can tell me why shit stopped working without me going into AltUI (cursing), i'm happy.
If this is a viable way to do it, i'll use commfailure instead, and copy the log() line to the elseif and to the sync function.
The reason why the line drops should offcourse be addressed, but I think this is an important feature nevertheless, as there might be bugs in z-way and it seems to take a while between updates there..
I don't think i've had a single luup reload by the system since I was running Vera..
If this is a viable way to do it, i'll use commfailure instead
No, it’s not sufficient to do that, since device status and last failure time will not be set.
You need to use
There need to be a few more changes to the ZWay module in the plugin too.
I’ll post a new version shortly, so that it’ll be in the baseline.
ZWay development branch v21.1.19 has a fix.
As well as setting
CommFailure, it also sets
CommFailureTime, and the internal device status, which turns the plugin's device banner red on both AltUI and the openLuup console interfaces.
As I've said many times, this whole plugin was just a prototype and it seriously need rewriting to improve maintainability... but, nevertheless, it does work quite well.
PerH last edited by PerH
It definately does. (work well, that is) Thanks!
Token lost again today..
The z-way-server.log seems to be about z-wave communication only, wonder if I can find traces of wtf is happening with the token somewhere as well?
Is this exactly 7 days after it was refreshed?
nope. 9 days..