Good points @chris. Based on my research, a good example of what youâre describing is the Fibaro FGS-224, which now brings S2 security and âSmartStartâ to a module based on the 500 chipset. This means that an integrator (or end user) can pre-include (or re-include) devices to a new controller without having to take rediculous, unfriendly steps, like open up wall-box lightswitches to push a little button on a module inside (across the entire network).
Z-Wave v7âs ARM core, faster CPU, and larger on-SIP storage is not likely so important to OH users since most logic is implemented externally in OH. I imagine it will make life easier for HW developers who want to implement more complex functions internally, such as a Thermostat that needs complex logic internally for calculations of dead-band, stage offset, reset curves, scheduling etc.)
The difference in v7 power draw seems relevant ONLY to battery-powered sensors, since MOST of the power consumed by a mains-powered module is the low-voltage power supply itself, and not the z-wave chip.
Thus, in my mind, the indispensable v7 feature is the improvement in range. While sensitivity in v5 can be improved via an optional SAW filter, the broadcast power canât be improved. Naturally it takes 2-directions to have a radio conversation.
Personally, my biggest peave in smart lighting is latency and non-deterministic behavior. My observation that: if an untrained user flips a switch, and the related thing doesnât do its ONE job in less than half a second, every time, then that user will conclude: âthis system is crappyâ.
According to that metric, my experience with v5 is that Z-Wave goes from crappy to fabulous if you can just get endpoints to be within ONE hop of the controller. Thus, one would conclude that v7 could improve on that, seemingly significantly by way of its better range.
What I am curious about (if I even understand v5 correctly) is whether v7âs more capable ARM core will allow for a better/smarter command processing, such as a command queue depth of greater than one. If I understand it correctly, it could make the relationship between signal degradation and network âcrappinessâ (as defined above) to be more of a linear relationship, not the exponential one that I observe. Currently I observe Z-Wave performance decreasing to the square of the decrease in signal quality (i.e. hope count). Presumably this is due to the interaction of the two factors: increased number of hops (and related acks) combined with a command depth of just one.
If there could be multiple on-the-fly commands, it seems like it could decrease both the growth in latency and variance in latency as hop count increases. If anyone can speak to this Iâd be very interested in understanding it better.