I'm thinking in terms of devices that can be chatty, like power monitoring plugs. Would just turning off logging, even just info class, help with mesh congestion? Should it just be turned on, even info, when needed?
I'm not having any problems, yet, knock on wood, just wondering.
Since the logs are just recording events that happen whether the logs are turned on or not, I would think that logging in and of itself would not cause mesh issues. The chatty power monitoring plugs generating the logs will though, especially on zwave. I imagine there is some additional hub load associated with logging, especially if lots of things have debug logging turned on, but I haven't seen it be a problem on HE. I have, however, on other things, see advanced logging actually bring the service down!
There must be a reason why, seemingly as a specified design requirement, debug logging is turned off after 20 minutes or so on most drivers.
Could be the load, but the logs are of limited length. Leaving debug on for too long would fill the log quickly with the output of just a few sensors.
Doesn't it just overwrite the oldest? Then, there's live vs past.
edit: but yes, that could be the reason.
Yes it does... so if you have debugging set on for a couple of devices and the log rolls really quickly you might miss stuff you to see.
I seem to remember at one point in the past I turned logging off for everything and then then just turned it on for what I wanted to check. At some point that got left behind.
I still try to do that. What really gets my goat is when there's a custom app or driver that doesn't have the ability to configure the log level. I usually end up going into the code and commenting it all out.
I use the "log" command within RM to generate log entries of my own, particularly when my rule handles an error of some sort. For instance, I have a rule that automatically arms my alarm system under certain conditions and then checks to be sure it really did arm. If it didn't I write a custom log message and try again. But I want to know of the failure for review later. (If repeated attempts still fail, it sends a pushover message so I at least know the system is not armed.)
I've only recently gotten into RM, so I'm not too advanced at that. I didn't realize there was a 'log' command in RM. That could be handy.
I do have an Aeotec whole house monitor updating every 5 seconds. Logging is turned off in the driver, and I don't even know it's running except if I look at my "power monitoring" dashboard.
On the other hand, I still have info logging on for 17 power monitoring plugs. I've been using logging just to try to tweak the reporting parameters and review some erroneous readings. With a electrical varying load, things can get chatty even with parameter adjusted to the minimum, on the plugs I've been using.
Still no issues though, knock on wood. And 13 of those plugs are on S2 for its better error checking.
I'm surprised you arent seeing the effects of all that power monitoring on your zwave mesh... but that has more to do with how often the device is sending events, less with the actual log settings.
Interesting. I have always shied away from S2 because of the overhead (except for security devices), but I have seen a couple of references in addition to yours to better error-checking so obviously, there's something to it. I've been trying to find a technical article or more detail. If you happen to have a link or anything please post. I'm not going to redo all my zwave inclusions, but I would like to understand better for my own edification.
I’m certainly no expert, but I’m inclined to agree with @brad5’s take on the matter.
The details of what the hub logs isn’t the same thing as Zigbee/Z-wave mesh events. So I don’t see why there would be any impact on the mesh itself.
Changing the settings on the devices to decrease the frequency of the actual events would be the way to avoid mesh congestion.
Doesn't stop me!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
