openLuup Z-Way bridge: Version Log
-
Master Branch: 2020 Release 4.5
Roll-up of recent changes in development branch.
-
So am I correct in saying that this bridge allows the UZB to be accessed via Openluup as opposed to via Z-way software and front end?
I guess we still need the software and licence
C
-
No, not quite. It uses the ZWay software via one of its three APIs to provide Vera-like presresentations of its ZWave devices.
Yes, you still need the ZWave licence key and the software.
-
@akbooer said in openLuup Z-Way bridge: Version Log:
No, not quite. It uses the ZWay software via one of its three APIs to provide Vera-like presresentations of its ZWave devices.
Yes, you still need the ZWave licence key and the software.
Cool, thanks!
C
-
Development Branch: 2020 Release 7.14
- correct CC91 variable:
sl_CentralScene
- correct CC91 variable:
-
Development Branch: 2020 Release 11.24
- add
category_num
to devices
If the device type is recognised, the
category_num
is set appropriately (subcategory_num
is not currently set.) - add
-
Hi akbooer,
have in your plans or request to develop for openluup a bridge to other z-wave stick (aeotec z-stick, vera atom ezlo v2) or rpi daughter cards (aeotec z.pi 7) ?
Is the actual z-way bridge stable as far as you konw ?
I'm looking for a stable zwave sw/hw solution on rpi/openluup.
tnks
donato
-
The ZWay stick (and Razberry board) and plug-in are the best I can offer so far, and pretty stable AFAIK. I definitely won’t be doing anything for Ezlo. The Aeotec stick API was a bit of a nightmare last time I looked, I don’t recall if anyone else did anything on that.
I wonder if anyone else has any thoughts?
-
tnks akbooer,
I'll try the zway stick or board .
did you try the razberry board version 7 ?
-
The version I have is rather old, so I guess not. But the API should be the same.
The board should come with a licence, but the stick may require it as an additional purchase?
-
There is an additional license for the Z-Way software, but I would say it is well worth it. My experience is that it's extremely stable (haven't crashed once in the years i've had it), and the control of the network through the expert panel is probably the best you can find.
The "Smart Home" UI is not great, but it doesn't matter much if you're using openLuup. -
tnks PerH for your info.
I'll update you as soon as possible about version 7 (board and stick).
-
I've installed z-way UZB stick (most recent version) on rpi4 with bullseye os 32 bit and z-way controller (it doesn't run on 64 bit yet).
It seems all ok. I've at moment added a fibaro switch and it's running ok.Just a question about the openluup device page : is the status of devices refreshed automatically after a command from the browser page (for example a click to turn on/off a switch) ? it seems not
-
No, the devices page (or any other in the openLuup console, except the Lua Test pages) does not update, it has to be refreshed.
This was an early decision that made the console much simpler, and went with the assumption that AltUI would be the de-facto interface. The console evolved over time to be much more complete and now it would benefit from a complete rewrite to make it update in real time. Not likely to happen in the near future. Is this a problem?
-
no akbooer, no problem . I have to control the device via sw (lua).
p.s. excuse if I use this post to ask another question about openluup console : can you confirm that isn't possible to define a device trigger variable through your console (trigger table -> create) ?
-
Yes, that's true. Sadly, that page is only a stub at the moment (in fact it shows the session cookies, which isn't much help to you.)
AltUI has its own device watch triggers, of course, and openLuup has its own (currently hidden) way of triggering from variable changes, which would make it possible to use even in the absence of AltUI, but the console pages to do this haven't yet been finished. There didn't seem to be much demand for this.