Honestly, I haven't figured out a need for it in any of my automations. Just metrics on power usage for various light fixtures - I use influxDB/grafana combo to keep an eye on things.
On smartthings, there was a default device called Zigbee Switch Power that worked great with these devices.
Being an automation driven platform, our first priority is supporting automations, we haven't spent much time dealing with data collection.
Data collection typically works best with fixed, known sample rates, in an event driven system this would potentially generate events that serve no automation propose and potentially consume needless resources, possibly to the detriment of automation execution speeds.
Fair enough, it's not a big deal as I recently purchased an Aeotec HEM and plugged it into my breaker box for whole home energy monitoring. I'm glad the zigbee outlet drivers at least have power monitoring - I actively use these for my automations (example, to figure out when my TV goes on and off and trigger automations accordingly).
As to your point about data collection, what sampling rate do you recommend to keep the Hub running smoothly? I currently have the HEM reporting wattage every 10 seconds.
I actually have one that I have hooked up to my landscape lights and I was just curious about how many watts they were drawing as I switched out the lamps to LED, it really was no big deal to just check the amp draw with my handheld multi meter, The other switch I have hooked up to a hydroponic towergarden and I have the pump cycling on and off every 5 minutes via rule, from there I wanted to use the power monitoring variable in case the pump fails during it's on cycle, I could then be alerted. I had not even thought about the overhead on the system... That was my intended use.
If you are using power readings for automations I would switch to threshold based reporting if possible, that way you are actually generating an event of interest, vs an event every 10 seconds over 24 hours.
Any automation that's looking at the power value change will load every 10 seconds.
If you use threshold reporting on the driver, the driver will only produce a single event when the that threshold is breached.
I have a use case for any form of power reporting from a switch:
I'd like to control those semi-smart fans that will run based on humidity, and that can also be "forced" to run when the power is toggled off/on. If I could see the power draw of the device, I could tell if the fan is running full-speed (off/on toggle) or at a lower speed (humidity sensor), and from that determine if I need to do an off/on toggle to get it full-on, or if it is already full-on at present.
The SmartThings pocket-sockets get assigned the Generic Zigbee Outlet driver, which offers threshold reporting sufficient for my needs, but this driver won't report power for a GE/Jasco Zigbee switch that did report power on SmartThings. I tried porting the SmartThings DTH, but unfortunately the power reporting commands seem to be lacking some entry points:
groovy.lang.MissingMethodException: No signature of method: com.hubitat.zigbee.Zigbee.simpleMeteringPowerRefresh()
groovy.lang.MissingMethodException: No signature of method: com.hubitat.zigbee.Zigbee.electricMeasurementPowerConfig() iIs there any chance that the Generic Zigbee Switch & Dimmer drivers could be updated to include threshold power reporting for the GE/Jasco switches (and dimmers)?
Yeah, I can add that
I would like to setup power usage thresholds to generate alerts that something might be wrong with my pool pump. For example, a power usage below "normal" would indicate that there is little or no load on the impeller. That could mean a low water level, broken pipe, or something caught in the water intakes. The automation could shut the pump off and notify me to check it. (I recently destroyed a pump because it ran for a few days without any water. Burned up the pump shaft and bearings..... )
Just a thought.
Hey, Mike - any idea when we might see Power Reporting for Generic ZigBee Switch devices, like this Jasco/GE device?
It's not mentioned in the 2.1.5.119 release notes...and doesn't work on 2.1.4.130
Thanks!
Might as well add the 45857 at the same time 
can you try that device with the generic zigbee outlet driver?, let me know how reporting works with that driver.
Yes, I have tried that, even after the latest HE update. Unfortunately I don’t get any power data.
Interesting, ill have a look.
dedicated drivers for the switch and dimmer with power reporting are included in platform 2.1.6, be sure to click configure after swapping drivers.
I found what looks to be an interesting bug in the new GE Zigbee Dimmer driver: if you have Attribute Reporting Interval enabled (either 1s or 5s), the device always sends one or two level() events AFTER it is turned off.
Normally this isn't an issue (the light doesn't turn back on), but if you are using the Mirror Me app, this causes the "slave" lights to turn back on, because the level() event is reflected as a setLevel() event to the slaves.
Now, I can stop the extraneous level() report by disabling the Attribute Reporting Interval - but unfortunately, this defeats the purpose of Mirror Me, because now the current level is never updated, unless I manually do a refresh.
(EDIT - I spoke too soon - the same thing happens if I use the Generic Zigbee Dimmer driver - so Mirror Me seemingly won't work correctly with ANY Zigbee dimmer device as the master.)
EDIT #2 - Sometimes the Generic Zigbee Dimmer doesn't send the extra level events - I haven't figured out when or why...
This should be fixable for the GE driver, the Generic driver configuration is set to not have the device report level changes, however if the device initially joined as the GE, then you switched to the generic and didn't click configure, the reporting changes from the GE would still be active, maybe that's what's going on?
I'm generally pretty good about clicking Configure after changing drivers. But, just to be sure, I just tested it again, and despite my clicking Configure after switching from the GE Zigbee Dimmer to the Generic Zigbee Dimmer, the problem is still there.
Note that my complaint is about extraneous LEVEL reports after the devices are turned off - nothing to do with POWER reporting.
FWIW, I ultimately solved this by using Switch Bindings from Joel Wetzel (available here) instead of the built-in Motion Lighting. I changed Joel's code to use a single Master device, and to ignore level setting commands received from the Master when the switch is off (you might consider a similar change to Motion Lighting, BTW).
FWIW, the pattern of the extraneous Level reports is suspicious - say I have the Master lights set to 50%. When I turn them off, I can clearly see the Level display change to 49 momentarily, and then back to 50%. These two events appear in the Event log for the device, both occurring AFTER the switch.off is logged.
Also, I tested this using my Jasco Plug-in Zigbee Smart Dimmer (45852 ver 1.0) using the GE and Generic drivers - it does exactly the same thing. I also tested many of my Z-Wave & Z-Wave Plus dimmers, and I haven't the problem with any of them. So, something suspicious in the Zigbee Dimmer drivers (plural)...
EDIT: Interestingly, SmartThings with the Jasco 45857 in-wall dimmer has the exact same occurance - after the light is turned off, there are (usually) 2 level events posted after the switch.off is logged. So, "working as designed" maybe - in that case, you might want to fix Motion Lighting instead of the device driver...
Yeah, this is yet another feature of this dimmer, in any event it's fixed in platform 2.1.7...
Thanks @mike.maxwell for the fix, and @storageanarchy for discovering this. I had given up on using my bypassed GE dimmer as a master due to lights coming back on after shutting off (and not very consistently I’ll add). Figuring that it wasn’t designed for this purpose and I didn’t have time to deep dive into why it didn’t work properly I just removed the rule and stuck a Hue dimmer beside it. It will be nice to be able to put it back into service and repurpose the Hue somewhere that will be less confusing for the family.
Great that the driver will be fixed, but you might also want to tweak Mirror Me to ignore those extra commands, for those users who are using the Generic Zigbee Dimmer driver and who probably won't know:
why Mirror Me turns the lights back on after turning them off, and
that they can "fix" the problem by changing to the GE Zigbee Dimmer driver...
Thanks again, Mike!
Download the Hubitat app
