Request: Add a section under "Settings" to provide a centralized place to view and control device and application logging and the count of events recorded per-device.
Rationale: Logging is frequently cited a cause for hub slowdowns, and logging is often enabled unnecessarily or left enabled after it is required. It is tedious, inefficient, and error-prone to manually check and change logging and the count of saved events in each device and application. This is particularly true in RM, where accidentally clicking on "back" or "App list" can corrupt a rule.
Implementation: Within the Logging page, display a chart, with rows named for the device or application and columns for the type of logging and count of saved events. A check-box would indicate if logging is enabled.
There would also be controls to enabled/disable logging per-row, per-column, or globally and to globally set the count of saved events.
It would take an a ridiculous amount of logging to cause a slow down.. I can confirm this because my development hub frequently has a massive amount of logging on to trace problems, and I have seen no slow downs from this.
The act of pruning the logs has also been cited as a temporary slowdown....but I wouldn't know for sure, as I'm staying with v 2.2.2.129 for a while.
In any case, I hope we can both agree that logging unnecessary data will unnecessarily consume network bandwidth, CPU cycles, and storage -- it would be helpful to have an easy way for end users to see and control what devices are logging, and at what levels.
Um, sounds like some of the HE staff believe in bigfoot:
Maybe "events" in this context means something different from "events that the user chooses to log", and maybe there are "event history" entries that are not controlled by user level logging settings.
Perhaps the terminology could be clarified to distinguish those classes and put an end to the Nessie sightings.
Yes, events are completely different than logging. In and of themselves, events are not an issue (except for odd circumstances like a run-away driver). The issue that was addressed was that we were saving 1000 events per device. This made the database an order of magnitude larger than it should have been, and that in turn caused some slowdown of database access. This was not the cause of hub slowdowns that people complained about, but rather, an unnecessary tax on the hub. We have made the number of events stored user selectable, and defaulting to 100. My database went from 26MB to 4MB. I did not notice any difference in performance.
The UI to change max stored events for a selected device and corresponding changes to cleanup job is still in beta. It is not available in 2.2.3.119. It will be visible by default in a future general release.
There is no UI to change overall max stored events number in 2.2.3.119. The
/hub/advanced/event/limit/X
URL is the only available method of modifying it. It affects all devices' events and hub events. Note that the number is per device/event name, such as pushed for a button.
