In new 226 update, group app has an option of metering. Any idea how does it work? What is the mandatory delay needed for?
I grouped shelly devices with metering, but cant find any power info in group device.
Metering can be used if there are many devices in the group and not all of them are receiving the commands. Metering inserts a delay between the commands sent to each device. The term metering as used here is not power metering as provided by some devices.
4 Likes
How much of a delay? Just curious.
Up to the user, but in testing 50 to 75 ms seems to sort most large Z-Wave or Zigbee groups where zigbee group messaging is not used.
By large group, like more than 20 devices.
1 Like
While I agree that the usage here could be confusing, when used as a transitive verb it can mean "to supply in a measured or regulated amount." See entry 5 here:
2 Likes
Honestly, for me it was confusing. I was happy, thinking that grouping devices with power meter functions will do total power meter for group device and I dont have to do calculation anymore 
.
2 Likes
it wasn't intuitive for me either - figured i'd goodle the new feature - I think they meant it just like our "metering" at the freeway onramp where have traffic lights to put space between cars before they merge onto heavy traffic.
1 Like
I have a question about Group metering. Why was this enhancement not addressed at the platform level instead? If I have a rule in RM that turns off a large list of lights, wouldn't it make sense to abstract the metering option at the platform level vs application level?
Because every system is unique. This can't be done universally, as it depends entirely on the specifics of the case. In my system, I can turn off 50 devices (all Lutron) with one command, no problem. In some people's systems, they can turn off 10 with no problem, but not 12.
If you need metering in a RM rule, it is straightforward to add that. For Groups and Scenes both, there was no other way to do it. Also note that the amount of metering time is quite variable also, and depends on the specific devices. If mesh networks were perfect, this would not be a need. But, the fact is that mesh networks are far from perfect, and can be overwhelmed by message storms.
It's a good answer and I accept. 
If I could go back in time I would have selected lutron for my lighting switches. Offloading these switch commands to a device via telnet that black boxes the wireless signal out to the lutron switches is better than dealing with zwaves mesh jargon over the years.
Despite all this, the group metering enhancement solved a lot of my issues when preventing a flood of zwave traffic resulting in dropped commands. Thank you.
And this leads me to the zwave protocol, why did they not make zwave transactional to guarantee the command eventually is successful or at least some retry logic built in automatically. I guess its a similar protocol to UDP.. Yucky..
Any of which would cause yet more mesh congestion.
And use up batteries faster for devices that aren’t hardwired or plugged in.
