The Hubitat logging needs an overhaul. Debugging issues is way harder than it should be or needs to be:
Default settings: Devices need to default to log every time something is triggered. Some of my devices default to not log anything. There should be basic logging (something is triggered) and advanced logging (temperature readings, battery level, etc.) that can be filtered for in the log view.
Hierarchical view: Because of the complexity of a smart home, there needs to be a better view of the log, for troubleshooting purposes. I propose a hierarchical view (like a tree view) where the trigger or cause is at the top, and then everything that happened because of it (effect or action) is below, indented. It should support nested cause/effect. So, you could have trees within trees if a cause or trigger resulted in an effect or action, which resulted in another cause or trigger, etc.
What devices are these? Stock drivers generally offer two levels of logs: "Deubg logging," which by default/convention is enabled after adding the device or after manually enabling it, with a 30-minute auto-off timer; and "descriptonText logging," which logs "info" logs with a description of any events the device generates (e.g., motion active, switch on, etc.). If you aren't seeing those, it's likely because you turned them off. They are generally the most helpful to figure out why an app did something or if a device actually did anything, and it will never (necesssarily) show you when a command was executed to try to make the device do something. Debug logs are generally most helpful for driver development, though some newer ones also log when commands are sent.
Community drivers may vary, which is part of the reason I'm asking what devices/drivers these are.
Also, I'm not clear on what the real request is since devices don't get "triggered" (that is a Rule Machine term, sometimes more broadly applied to other apps, and it refers to when the app will wake to run actions, generally in response to events that could be a device event subscription — maybe that's the connection?). But apps do bring up another point: given the above, if you're trying to figure out why something did or didn't happen, app logging will generally be more helpful than device loggng. For example, rules can be set to enable action logging. Actions are often actions that send commands to devices, so that should show you when that is happening, even if the device itself doesn't have logs that do.
Not a bad idea, but logs are generated by apps or devices, and I don't see a way for the platform to really know any connection between them. It would be great to see, for example, that Rule Machine sent an "on" command to a device and that this is why you got a "switch on" event for that device, but there's a disconnect: the hub sends the command, the device does its thing, and the device sends back a report--but the device doesn't know an app did it, so there's no information to that extent in the report, and the hub can't really know either because the only connection is that it was, presumably, reasonably close in time. It's possible another app did something in the meantime or a human phyiscally turned something on or off. This is just one example.
The log view could certainly use some improvements, so I'm not denying that. But it's possible some of this is already do-able with a little different use of the options we do have, so I just wanted to make sure you weren't missing something. In the meantime: filtering, appropriate settings in my apps and drivers, and browser search (often under-used, though not perfect) are my go-to!
I just remember having to go through all my devices to turn on logging, several months ago. I don't recall which devices actually had to have it turned on.
After posting this, I was told that Hubitat is working on something to help us know what triggered something to happen. It's not a hierarchical view like I had said, but I think it will go a long ways in making it easier to troubleshoot why something happened.
I don't think the "what triggered it" thing is going to be exactly what people think it is (the platform should be able to tell what app called a command, but you can't tell why a device event may have resulted from something a specific app necessarily did--all for the reasons above--and events are really what you see in device history at the moment), but it may be worth waiting to see what happens with this regardless.
Keep in mind that most drivers offer two types of logging, and debug logging will only stay enabled for 30 minutes (by convention, though it could be considered a bug if a stock driver doesn't do this, and it's a practice community drivers follow and most users ask them to if not). So, enabling that several months ago would be long gone by now. The descriptionText logging (info/event logging) should remain indefinitely, though, again, that will more or less just show you what events happened (not what commands were called or what did it; app logging can help with figuring out the "what did it" part).
Respectfully, I disagree with this. I would rather not clog up the logs with reporting from every device and for that matter every app by default. If you do that, it is hard to sort things out, and the relevant information falls off the logs fairly quickly.
If I have issues with a particular app or device, I turn on logging. Of course that doesn't help in a one-off situation, but if it was random, and like you propose with hundreds of devices reporting every change, you aren't going to have a record of the issue anyway as the error message will be purged from the logs fairly quickly.
I do think logging could use some improvements, and hopefully on Hubitat's radar. Also not sure if you are aware, you can use the built-in Preference Manager app to turn on logging in one place for all your devices if you really need to log everything.
But it's possible some of this is already do-able with a little different use of the options we do have, so I just wanted to make sure you weren't missing something. In the meantime: filtering, appropriate settings in my apps and drivers, and browser search (often under-used, though not perfect) are my go-to!
