In RM, logging per rule offers 'Events, Actions and Triggers' - multiple options.
In Basic Rules it is a switch 'Enable Logging'.
In Motion/Mode Rules it is also a switch 'Enable Logging'.
Obviously, RM has more functionality than other apps, but it feels wonky - like it was afterthought.
DescriptionText seems to be the go to Driver logging for devices and groups. It is useful in watching for wheen a device is triggered. I submit that Description text should be an independent switch for Rules, and then extended logging for more detailed analysis.
Inconsistent treatment of logging by community apps and drivers can also be a challenge but obviously one that HE would find it difficult to address. I have a couple where I've had to go into the source code and get rid of logging because either there are no switches to turn it on or off or the app or driver does not honor the switches.
What would "descriptionText" mean for rules? This is an attribute provided for events, which devices generate. Most apps don't generate events (they technically can, but this is a rarely-used feature and I think even most built-in apps that used to are moving away from it). For devices, this would generally be things like "Switch 1 is on" if your device is named "Switch 1" and some attribute (likely switch here) just became "on," though technically it could be whatever the driver developer provides--the same thing you'd see on the "Events" tab/page for that device. As you note, this logging is enabled by default for devices and remains so unless manually disabled.
I would say rules have these various options because sometimes you just want to look at one specific thing and don't need the "noise" that enabling all logging options would create (e.g., if you only want to know when the rule triggered, turning on action logging would be excessive). I would not want that granularity removed in favor of a single option, even if it would be consistent with the single option provided in simpler apps.
IMHO, the biggest issue mentioned above is that community apps and drivers don't always follow these conventions, though many written specifically for Hubitat do (ST ports are probably the worst offenders, given that there was pretty much no convention, and very little need for one given the unavailability of past logs). A wishlist item for me is that some built-in drivers (mostly newer ones) log when commands are sent when debug logging is enabled, while others don't, and this can be helpful for troubleshooting sometimes if you want to see exactly what an app (or you) is doing; it might be nice if every driver were updated to log this in these cases. The other thing is that the 30-minute timeout might not be enough to catch these cases (though is probably more than sufficient for the other purpose of debug logs). Perhaps this should just be a third option...but it's probably wishful thinking in any case, and a slight tangent from the specific issue above. Just not sure exactly what you're looking for with RM.
Just not sure exactly what you're looking for with RM.
