Is there a way, or can there be a rule action added that will turn on/off these debugging means?
I would like to be able to set up some virtual switches that turn on various rules' debug logging from one place. For instance, if I need to dive into what is triggering the thermostat to start misbehaving, I can just flip a switch that triggers a rule to turn on logging of the events, triggers, and actions of all rules involved, and later turn the rule off once I have fixed the issue.
I can always put in conditional logging into the rules themselves, but sometimes, I need more, like the rule logging. And it is somewhat of a pain to keep track of what I turned on and go back and turn it off and repeat if needed. Does this make sense? Or is there a way to do this already that I haven't thought of?
Just leave logging on for all rules. That's now the default for new rules, all logging on. Logs don't burden the hub in a meaningful way.
We won't be adding a feature to allow logging to be controlled by a rule.
Adding to the above: are you aware that the "Events" tab on the device detail page shows not only events but also commands, including which app sent the command? That will tell you definitively without needing to go through logs and guess.
See:
Note specifically that you are looking for commands (look for "command" in the "Type" column, and the "Produced by" column will tell you what app called it), not events (or what apps were triggered by the events, though that can be helpful if you aren't sure what app might be doing something in response to a particular event). This page shows you both, but there is an important difference.
Thanks. Yes I am aware of the event tab on the devices page. For myself, this isn't much help as commands stopped being listed since yesterday but my thermostat was getting turned on and off. So I was trying to figure out what app was actually doing manipulating it.
I am not a real big fan of throwing everything into the log file all the time. Thus, I prefer to turn on and off stuff with a simple switch where I don't have to remember everything I need to turn on or off. I know that I can filter the log file by all this, but then I have to figure out what all calls it again.
It's just a matter of making debugging a little easier for myself and I didn't think that it would take too much to put it in. But I understand if you don't want to implement it.
Like there's nothing since yesterday? If the problem happened today, I don't see how it could be Hubitat, then. If an app sent a command (including if you did it manually from the device detail page, mobile app, a dashboard, etc.), it would be listed here. If not, whatever change happened couldn't have come from the hub. This is why this page can be useful for troubleshooting.
Is this Wi-Fi or somehow connected other systems, too, like a Matter device or something with Zigbee binding or Z-Wave Association configured?
I agree with @bertabcd1234 that if there are no commands listed, then it is unlikely to be something on your HE setup controlling the thermostat. Perhaps as a more general piece of advice, you may also want to look at the "In Use By" section for the device in HE, to understand which apps have some kind of association with the device. (Apologies if I'm telling you something you already know).
As far as your request, while I can appreciate that it may seem like a reasonable option for what you are facing right now, my guess would be that it may also be something that you ultimately use rarely, i.e. hopefully you don't have too many issues you need to troubleshoot. It would likely need some kind of setup for each particular use case as you come across as well, e.g. a new virtual switch and the list of rules to enable / disable logging for, needing to be maintained as you add/remove rules over time. Plus devices are not always controlled via RM rules or at least RM rules alone, they can also be used in other built-in or custom apps, each with their own logging options.
I think for what you are facing, as much as I don't expect it to be HE related, the device events and also the link to a filtered list of device logs are two very good options for troubleshooting a specific device.
Further to what the posters just above have suggested, you might also open a Live Logs tab, and command the thermostat through its own control panel. That should send commands to Hubitat. This would be to confirm that it's actually talking to the hub. Do this in both directions -- just a sanity check.
It's a bit bucket.
I really didn't mean for this to open a rabbit's hole. I will try to keep this short(ish). I was having issues with my iBlinds after going to ZwaveJS. I have many of them (which are slated to be replaced soon(ish)) so I didn't want to put a whole lot of effort getting those right as they aren't really easy access physically to reinclude them. So, I just decided for the time being to go back to legacy zwave. That was late yesterday. Today, I noticed the z-wave thermostat was making the house quite cold. Nothing has changed on that stuff in ages (except the zwave method changing twice) . So, I was just trying to figure out why that was. The zwave logs were showing communication with the device (although I do not usually try to dig far enough to figure out what that communication is) .
Anyway, I have six hubs and lots of devices and apps. Trust me, I create plenty of issues that I need to troubleshoot. I know that this request was only for rule machine, but that is mostly what I use, and I use it a lot. And my logs get quite full with everything on and I like a more granular control over it. But its not a biggle, I will survive without it.
Could it be confused between degrees C and F? (I remember seeing this on mine recently and think it was after the switch for some reason, but I don't remember at this point...) If so, that should be a simple fix, though I again can't recall exactly what did it for me. Power cycling the thermostat, running a "Configure" command on the device from the device detail page on the hub, and maybe a "Refresh" just to see what it's currently reporting would be good steps, as would making sure it's set to heating, cooling, auto, or whatever mode you want (and that your hub units are correct, of course, or the driver if it allows overriding that via preferences/parameters, though that was not my problem).
