I’ve practically already made up my mind and purchasing MCV Vera Lite with a few (likely Fibaro) components to build my first home automation system - starting small, though.
What’s still unclear (and a key question) is regarding the lag: I’ve heard that such thing as execution lag exists. Now, how bad is it really - are we talking about 0.5 seconds, or 5 seconds?
My initial scenario is to build a LED based lighting controlled by MVC Vera Lite, Fibaro Motion Detector, and Fibaro RGBA Controller, where the idea is that they work also as night light for the kids when they to bathroom, that is, motion detector senses the movement, and Vera turns (immediately!) LEDs on at 5% strength. After a few moments without movement, they dimm away.
Now, what sort of lag can I realistically expect for this “motion detected” → “LEDs turn on” event, where Vera works as the middle-man? 0.5 seconds, or 5 seconds?
How would this be affected by the number of other nodes in the network?
I’m really just looking for rough estimates & experiences.
If there’s significant lag, or even noticeable lag, then there’s something not right with the network. If you genuinely have a small, closely spaced network, then all should be fine. If you have an extensive network, then this is also fine as long as it is sufficiently dense.
It is, of course, very hard to quantify these statements, but starting small and growing is a good idea. Fibaro, also, plays well with Vera and offers instantaneous reporting of device status, so this all adds to the perceived responsiveness.
I have a fairly large network, in fact, three separate ones. I sometimes have delays in the one I use for development where Vera is being restarted often. However, some devices I have set up with direct associations, switches to lights, etc. with no Vera middleman. These work very crisply indeed.
Your biggest lag is likely to be from the motion detector itself IMHO.
more like milliseconds for direct associations. For some of my secondary remotes, it’s perhaps 100 mS.
What could this "something not right" be? Any examples?
Transmission problems due to bad signal to noise ratios arising from interference or bad location of modules. A not sufficiently dense network. Hardware failures. Errors in routing information in the network. Configuration problems in controllers, ...
Sounds like a long list - I’m sure there’s more - but these are simply things which can happen, not necessarily things that do happen very often. Mostly, people who play with HA systems are their own worst enemies.
Ok, based on this I understand that even with MVC as the middle-man the reaction chain “motion detected” → "MVC Vera " → “LEDs illuminate” would happen immediate without any noticeable delay or lag. Which is good.
[quote=“AgileHumor, post:7, topic:181421”]I have 15 Z-Wave nodes on a primary Vera. Then I have 80 Z-Wave devices (mostly light, wall, and security sensors) on a “bridged” Vera.
Z-Wave - I have a normal lag of 1-3 seconds with 1.5 being the norm.
Z-Wave Motion Sensor (Primary) → PLEG (Primary Unit) → Turn on Z-Wave Lights (Bridged Vera)
Non-Z-Wave (Philips Hue Lights) - In same scene as Z-Wave
Z-Wave Motion Sensor (Primary) → PLEG (Primary Unit) → Philips Hue Plugin 0.5-1.5 seconds with 1 being the norm.
I don’t know if the extra second delay is the bridged Vera or Z-Wave[/quote]
Very interesting, thanks for the insights! Anyone else, anything?
I’d be eager to understand this whole lag thingy in a bit deeper manner. Like - in a case described by AgileHumor above - to be able to really break the total lag down per component & communication; and then naturally see if there are ways to somehow optimize these.
I used to bridge all three of my Veras and this introduced all sorts of delays and problems, so I don’t do that now. A decent control app (HomeWave) controls multiple unbridged Veras, and data logging (EventWatcher / DataYours) also works on unbridged machines, so no need to do it.