Another thought: Would be nice for the Verabridge to be able to report the number of failed devices and which device from a vera. I have quite a few battery operated devices so I would like to know when they run out of battery.
Otherwise I implemented all my previous requests and sent them to akbooer on github.
One more suggestion: Trigger lua.
I know the triggers don’t work and use a variable watch instead. It would be nice if a lua code could be assigned to specific variable watch events so that we can avoid having multiple nearly identical scenes due to variations in the trigger. ALTUI already supports this entry in the trigger line on the vera.
Not quite sure what you’re after here.
The bridge shows you the battery status of all remote device which have batteries. There are plugins which monitor these variables and report. The device status is also supported by the bridge, so you get AltUI showing you failed plugins, etc.
Not quite sure what you’re after here.
The bridge shows you the battery status of all remote device which have batteries. There are plugins which monitor these variables and report. The device status is also supported by the bridge, so you get AltUI showing you failed plugins, etc.[/quote]
I was after a summary page kind of like what is available on the vera at the top of the dashboard. Might be more of an ALTUI feature than openLuup though come to think about it.
Ah, now this can be done and is on the list. The functionality is already there in AltUI (it works on Vera, AFAIK.) It’s part of the task_status processing which needs yet to be fully implemented.
This is not quite as straight-forward as you might expect. The problem is not HOW to implement, but WHAT to implement:
[ul][li]exceptions do include bridged variables, but others too (eg. Zway plugin)[/li]
[li]should LastTrip be set as well?[/li][/ul]
The fact is that any native openLuup sensor devices are managed by their own plugin code. The built-in I_openLuupCamera1.xml code is one such example, since it creates its own child motion detector. I’m happy to implement this for all such devices, but there may be unintended consequences for specific plugins.
Suggestions/comments welcomed.
If it helps, based on much playing with my various plugins that implement SecuritySensor1, Vera’s semantics for [tt]ArmedTripped [/tt]are this:
[ul][li]If [tt]Armed [/tt]= 1, [tt]ArmedTripped [/tt]follows [tt]Tripped[/tt] (at edges, see below);[/li]
[li]If [tt]Armed[/tt] = 0, [tt]ArmedTripped [/tt]is not changed when [tt]Tripped [/tt]changes;[/li]
[li]If [tt]Armed [/tt]= 1, and [tt]Tripped [/tt]= 1, and [tt]ArmedTripped [/tt]= 1 (per above), if [tt]Armed [/tt]is set to 0, [tt]ArmedTripped [/tt]does not change (it remains 1). Likewise, if [tt]Armed=0[/tt] and [tt]Tripped=1[/tt], and [tt]Armed [/tt]is changed to 1, [tt]ArmedTripped [/tt]does not change to 1. So [tt]ArmedTripped [/tt]is set only on changes to [tt]Tripped[/tt]; it is not unconditionally kept equal to [tt](Armed && Tripped)[/tt].[/li][/ul]
And of course, [tt]LastTrip [/tt]changes any time [tt]Tripped [/tt]is set to 1; the state of [tt]ArmedTripped [/tt]does not affect [tt]LastTrip[/tt].
Yup, saw your other post, thanks.
Will probably implement in the way that Vera does (which I don’t really see as a bug.) How many times DO you actually change to Armed when Tripped is set, anyway?
As I wrote my other post, I spent a bit more time thinking about this than I clearly had before, and I actually see a benefit to it and I, too, am going to follow Vera semantics (remove my override of ArmedTripped when Armed changes). It’s easy to test for both Armed and Tripped being true at any time, if one needs to know that, but it is MUCH harder to detect edges of Tripped when Armed is true, so having ArmedTripped behave as it does (Vera semantics) makes this very easy.
@akbooer: I actually created a version of this which I am currently using for some of my devices in the pull I submitted a while ago on github. At the time I created a new virtual implementation file… Feel free to use the logic. I avoided touching the bridged device but implementing only for devices which use this file.
Can’t be done that way because it needs to work for arbitrary implementation files and also for devices which don’t have any implementation at all.
As I said, there’s no difficulty in how to implement it. It’s already done.
One potentially crazy idea: Have you ever thought of integrating OpenZWave into openLuup? I see that there is a lua wrapper for it on github but it appears quite old.
I looked very carefully at this and all the other options, and eventually settled on the Zwave.me stick (and/or Razberry board) because of the simplicity of its ZWay API, when I was looking for a Vera replacement.
My only use for Vera, now, is as a Zwave gateway, accessed through the VeraBridge plugin. Similarly the Zwave.me USB stick has the ZWay plugin. In like manner, it would certainly be possible to write a plugin to interface to any OpenZWave hardware, but it would be a fair amount of work.
My priority is actually to rewrite the current ZWay plugin to make it more comprehensive and more like the VeraBridge in functionality, including rooms and scenes, plus the potential for multiple ZWave networks from a single controller.
Thanks AK. I can see that it would be quite a bit of work.
Having had OpenZWave and Z-way up as secondary zwave controllers on my network, I am finding that they each have their pros and cons. OpenHab, Homeassistant and a number of others actually use OpenZWave as their zwave api. It seems to be a lot more active and is open source unlike zway. The big advantage I found with it is the secure class key which can be manually configured. Zway currently does not support this and therefore cannot control any of my secure class devices on my network. Only OpenZWave and Vera can. I have been struggling to get any support from the zway forum. It has other advantages though in terms of UI but homeassistant/openzwave is catching up fast. One can now manually assign associations like on the Zway.
Out of interest, did you manage to extract the Security key from Vera? Or configure Vera with a different key from a different network?
Yes, I extracted the key from the vera. I opened a ticket with CC and one agent was kind enough to point me to where it is.
Care to share the method? By PM if needed … I’ve been trying to do this to allow my ZNiffer to decode Secure device communications, but couldn’t see the key in any obvious locations.
Care to share the method? By PM if needed … I’ve been trying to do this to allow my ZNiffer to decode Secure device communications, but couldn’t see the key in any obvious locations.[/quote]
Will send you a PM
On and off, for a very long while now, I’ve been considering the best way to address asynchronous I/O.
In keeping with the platform-independent nature of openLuup, I’ve wanted to stick with pure Lua code and minimize links with particular OS libraries (especially, I still want this all to work on Windows.)
For HTTP(S) requests, it seems that a very good option would have been this library:
BUT, alas, I read in the documentation:
lua-http is pure Lua code with dependencies on the following external libraries:cqueues - Posix API library for Lua luaossl - Lua bindings for TLS/SSL lua-zlib - Optional Lua bindings for zliblua-http can run on any operating system supported by cqueues and openssl, which at the time of writing is GNU/Linux, FreeBSD, NetBSD, OpenBSD, OSX and Solaris.
One of the biggest users of this would be the VeraBridge plugin, which actually spends quite a while polling Veras, so it would improve response times to Vera events considerably.
So no Windows solution yet. Thoughts anyone?
I’d say leave it up to Windows users to make the dependencies work. You’re talking about an environment where Windows curl barely functions!! Getting anything to work out of the box cross platform is almost impossible without some sort virtualization. And that’s coming from someone who uses Windows for most computer related work.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules