My power monitor returns data every 3 seconds and is flagged a "spammydevice". What update frequency is considered "spammy"? I know this diagnostic is relatively new. Is there a parameter to disable (or change) the diagnostic for specific devices? Data events every 3 seconds shouldn't overwhelm any controller from this century, so I'm confused why the threshold is so low.
1 Like
@joe What power monitor?
Do you need the data every 3 seconds? If not then turn it up higher to the level that will be acceptable for your purposes.
2 Likes
Can you screenshot your device setup page where it shows how you set up power configurations?
The power data is from an MQTT message generated by my power utility's meter (Powerley Energy Meter DTH). The data is updated whenever the meter decides to spit out a new number. I could spend time adding a filter, a clock/counter, and conditional logic to reduce the frequency, then iterate until I find the magic update rate that doesn't flag it. But currently, the DTH overhead is less than 1% of total time (from log), so it shouldn't be hurting anything. I'd like to understand how it works before I spend time trying to fix something that may not be broken.
Oh, way out of my league on that one!
In general (with a physical device at least) the issue seems to be when you have many or various types of reporting enabled, and possibly is misconfigured for too low thresholds, so you are getting multiple reports at once.
For example, in my Zooz device, I have 6 different power reporting settings that could all be on at the same time. People turn on wattage % change report, timed wattage report, wattage reporting by threshold, volts reporting, current reports, and energy reporting. Those can easily swamp the Zwave mesh with just those reports alone.
My personal suggestion in these cases is to limit to 1 or maybe 2 reports and to up the interval as far as you can and still get the information needed to (for example) announce the wash machine is done.
300 events per hour. The threshold is rather arbitrary.
Not at this moment, but it's under consideration.
In our experience, people who have chatty devices tend to have a bunch of them. It's a common thread with support inquiries. A settable per-device threshold is the way to go, and I'll add it to a future release.
3 Likes
Thank you. That clears it up. To be clear, I appreciate diagnostics such as this are essential for a robust platform. But I also appreciate the ability to disable it when appropriate.
2 Likes
Perhaps it needs a bit of further refinement. I have a rule that monitors the poop level in our Litter Robot, modeled after inspiration by Jared Zimmerman’s (@jared.zimmerman’s) original thread. Our under-vanity lightstrips are green, yellow, red depending on the poop level. When the poop level gets high enough to break an IR beam in the litter drawer, things get critical, and the lightstrips start flashing red at a rate of two seconds on, two seconds off (repeat loop toggles the lightstrips every 2 seconds).
In one sense, the lightstrips are not “spammy devices” - they are just obeying the rule. If you want to call it a “spammy rule”, well, ok, but it’s doing useful work, alerting us to the fact the litter drawer is completely full and needs to be emptied.
However, as presently designed, this behavior is being flagged as problematic because the flash rate pushes the edge of the envelope.
Is not what one device does to your hub, but what many devices pounding the hub at the same time do. Based on support tickets, for every "chatty" device that is using a built-in driver, there are several others that might use a custom driver and their activity goes undetected, yet they are hitting the radios, resulting in "locked hub" effect. So while I agree that events from one device every 3 seconds wouldn't hurt the hub, ultimately it increases the risk of frequent concurrent events that could lead to overwhelmed radios and/or hub's main database.
One very simple thing you can try is to truncate the number of decimal places for the "Energy" field to just 1 decimal place (or 0 if that works for you.) Doing so, before the driver make the SendEvent() call, will allow the Hubitat platform to automagically de-duplicate events, thereby preventing an excessive number of Hubitat 'device events' from being generated, which are what causes apps to wake up and have to process them.
Plus, who wants to see 10 decimal places of precision on accumulated energy? 
4 Likes
@joe - I just looked through that Powerley Energy Meter driver, and it does have a lot of custom attributes that are updated every time new data arrives. It might be a good idea to simply comment out the following four lines, as I doubt they are useful, but they do generate an excessive workload on the hub, for no real value, IMHO.
sendEvent (name: "lastPowerTime", value: parsedMessage.time, isStateChange: true)
sendEvent (name: "lastPowerValue", value: parsedMessage.demand, isStateChange: true)
and
sendEvent (name: "lastEnergyTime", value: parsedMessage.time, isStateChange: true)
sendEvent (name: "lastEnergyValue", value: parsedMessage.value, isStateChange: true)
and if you comment those four lines out, then please also comment out the custom attribute lines as well
attribute "lastEnergyTime", "number"
attribute "lastEnergyValue", "number"
attribute "lastPowerTime", "number"
attribute "lastPowerValue", "number"
There may be some other code that references some of these custom attributes, so you'd need to clean that up as well. If any of that data is needed, it may be better to store it in a "state" variable, instead of a custom attribute.
7 Likes
@ogiewon , I love that you took the time to find the custom driver he’s using and offer suggestions for @joe
It’s helpful people like you (and too many others to mention without this getting out of hand) that make this such a great community and Hubitat such a great home automation platform.
7 Likes
Interesting that you mention this. I did exactly this last month and it reduced the communications, but not enough to not being considered chatty.
I agree. A recommendation is that the diagnostic flag high aggregate chatty process load instead of individual signal frequency. This would alert the user abusing the hub with overloaded data, but would allow a few high speed signals that do not adversely affect performance.
I agree that for this particular device, many things that can be done to prevent the diagnostic, but the concern is the occasion when I must update every 3 seconds. The diagnostic should be smart enough to look at the overall process load from interrupt signals and only flag when it risks affecting performance or reliability.
I have a Samsung SmartThings GP-U999SJVLDAA Smart Outlet. I use it to monitor power to my TV. I turn on the bias lighting when the power is >0 (someone is watching TV). I want to turn the bias lighting off when the power is =0. I am having difficulty getting the settings adjusted to accomplish this task without spamming my network. I wish the device would only report when power is >0 and when power is =0. I am using the "Generic Zigbee Outlet" driver. Suggestions?
This shot is with the power reporting at 100W. But this will often miss when the power drops to 0. So the bias lighting won't turn off.
What I do with mine is watch how fast the wattage changes from 0 to a higher usage, that is above the ping /healthcheck that the TV does on regular basis. For example, my TV occasionally wakes up and goes up to about 30 watts when not in use. Also, when the screen is on, the power consumption is at least 100W. Thus I set the minimum report on 100W. The rule would be > 100 for on, < 100 for off. My TV goes from 0 to 100 in a matter of milliseconds and stays above 100W while watching the TV, the moment the TV is turned off, goes back to below 100. So lights come on and off as expected within one second. I can certainly live with that instead of spamming my hub every second.
Also, based on your screenshot, you shouldn't even be getting any power reports, so that might be the reason you are missing the = 0 report. Set the power reporting to a higher level, then click save in preferences. You may need to click Configure after changing the preferences to apply the change.
1 Like
Yes, the screenshot is after I changed it from 100W back to disabled. Sorry. Even when set at 100W, the screenshot above that shows that my power fluctuates wildly, thus spamming my network. Correct?
Are you sure you are monitoring a TV and not a heat pump ( 
had to say it ). None of my TVs use as much as 537W. Looks like you can go up to 200W for min reporting.
1 Like
