Elk/ViziaRF/VRCOP, 2 way monitoring/control

Damn. I know its only $70, which is a pittance compared to the 20-25 devices i'll have, but it is annoying given that I could just set CQC to poll (aka don't use the Elk).
 
Definitely use instant status if you can. Z-Wave just isn't fast enough to support reliable polling of very many units at a rate that keeps latency low enough to be generally useful. If you set up for async reports, the driver will just ping the module every couple minutes to make sure it's still alive, but otherwise depend on async reports, which vastly reduces Z-Wave network load and makes everything work a lot better.
 
how much is too much? To me, I don't need to know the instant a light is manually turned on for most of my lights, there's really only a few that matter. If I could set 20 lights to poll every 2 minutes, 3 devices to poll every 30, and 2 devices to poll every 5 seconds, that would be adequate.
 
I mean seriously, what type of automation are people doing that they need to know the second <light x> is manually modified for 95% of their loads?
 
(i'll likely still get the USB stick since its <5% of the cost, but the question remains)
 
Generally it would be in order to have something happen in response to the change I imagine. Though, even if you are just displaying current status, having the change not show up for two minutes would make it kind of semi-useless I guess.
 
Dean Roddey said:
Even if you are just displaying current status, having the change not show up for two minutes would make it kind of semi-useless I guess.
 
That all depends on the use-case.  For me, if I know that at the longest, 2 minutes ago light <x> showed (on or off) on a GUI, that would be fine. I'm in the house, I know generally where people are.  And, if nobody is home, I know that within 2 minutes nothing has changed.  The only exposure is for when i'm not home and I look at the lighting status. But in that case, I could look to see if TV is on/off or other devices (or motion) to see where people are.
 
which gets me back to my initial point:  What use cases do people have for most of their lights that they need to know in seconds vs 2 mins whether a light is on or off? 
 
Other folks can speak to that. But I don't think that the argument for using async reporting so much rests on that, though it does provide the means to implement immediate reaction and the like.
 
I think that the real argument is more the technical one, that the Z-Wave never was really never designed for polling, since it was never really designed to integrate with automation systems for that matter. It's a low baud rate network, and the automation system and all local interactions have to share that network. Reducing traffic just allows everything to be quicker to respond and minimize the chance of multiple things possibly going on at once, which would require that both back off and try again. It also allows outgoing commands from the automaton system to feel more responsive because it's a lot less likely that it's currently out trying to poll a module's state, which has to complete before it can issue the received command.
 
Using async reporting basically just minimizes traffic, which decreases latency all around. So it's just generally a good thing.
 
IVB said:
how much is too much? To me, I don't need to know the instant a light is manually turned on for most of my lights, there's really only a few that matter. If I could set 20 lights to poll every 2 minutes, 3 devices to poll every 30, and 2 devices to poll every 5 seconds, that would be adequate.
 
I mean seriously, what type of automation are people doing that they need to know the second <light x> is manually modified for 95% of their loads?
 
(i'll likely still get the USB stick since its <5% of the cost, but the question remains)
 
It may not be that relevant for simple lights, but is much more useful for keypads, because you will want to do something based on a key press right away, and not at some random time later. However, in some cases you may want to know the correct status of a light to condition based on that status. For example, when motion detected in a dark room, turn on the LED light. If there is another light on in the room already, and that is why you need a status, do not turn LED light on. Or you are watching a movie and a phone rings or something else, and you use your phone to turn the lights on for a second, then try turning it off, but it won't for 2 minutes, etc.
 
picta said:
It may not be that relevant for simple lights, but is much more useful for keypads, because you will want to do something based on a key press right away, and not at some random time later. However, in some cases you may want to know the correct status of a light to condition based on that status. For example, when motion detected in a dark room, turn on the LED light. If there is another light on in the room already, and that is why you need a status, do not turn LED light on. Or you are watching a movie and a phone rings or something else, and you use your phone to turn the lights on for a second, then try turning it off, but it won't for 2 minutes, etc.
 
There's only one use case that requires knowledge of the current state, which is "do not turn a light on if there's a light on in the room already".   But thats a serious stretch as there's no huge issue with turning on a second light if the first light was turned on less than 120 seconds beforehand.
 
For the others you don't even need a 2way protocol, 1 way would do (turn on light if keypad, turn on light of motion, turn on light if phone rings, turn off lights a few seconds after you used your phone to turn it on)
 
Don't get me wrong, i'm not trying to be argumentative, but for 95% of loads I still don't see the need for instantaneous vs 2 min delay. The generic "its a good thing" is too fuzzy; I could use that argument to describe anything I want.  
 
btw, despite all my trash talking, I just ordered one from amazon. Knowing that I have instantaneous something or other but not using it is...annoying ;-)
 
Back
Top