It dawned on me tonight, I really never understood how to read and interpret logs. It seems they just point me Back to the device screen, but never really telling me what the problem is. So how does one go about learning how to read and interpret logs to make them useful?
I'm sure you know how to read a lot of it so perhaps it might be a good idea to give a sample of what's not making sense.
Logs are specific to the driver or app and therefore, the actual spelling of the words used is 100% independent. Hubitat may use one set of words to describe an event, while my drivers or apps would use the words as-I-remembered-them.
Thus the best way to understand them is by comparison... if you have the chance, screen cap a working device's logs, then compare that to the non-working. The logs that are the same in both aren't usually the problem. However, one gets a log entry that the other did not, in a big percentage of my debugging at any rate.
Here's my logs on one of my hubs in the past few minutes...
Counterintuitively, I can say that everything is working perfectly 
Those errors are for a device I have powered off at this moment and the hub is just informing me that it noticed 
Thus interpreting the logs is context dependent in a very large way.
5 Likes
To add to the above, since I mostly already had it written...
By default, most of what you have enabled is probably "description text" logging, which conventionally shows events generated by the driver/devicen as an "info" entry in the logs. So, if you're trying to troubleshoot a motion lighting automation, for example, it can be helpful to see when the motion sensor went active or inactive and perhaps whether the lights actually turned on or off. (A common misconception: this normally tells you if an event was generated, which normally only happens if the hub heard from the device--not whether a command to [try to] do was sent.) The "Events" tab on the device page is the authoritative source for a device's event history, but seeing them in their place in time in logs can be a better visual for some troubleshooting.
By default after device installation, debug logging is also enabled temporarily. You can also enable it yourself at any time. By convention, this automatically disables itself after 30 minutes. With some drivers, this logs what commands were sent, so could be useful for seeing what an app is doing. With most drivers, it normally just shows what the hub receives from the device and how (or if) it got parsed into an event. It can be useful for troubleshooting driver issues, though it's not always useful if you aren't that driver's developer or familiar with the protocol being used.
The above really relates to devices. Many apps also have their own logging options, and behavior here is a little less consistent than with devices and depends on the app. Lots of built-in apps have logs that show when the app is supposed to do certain things, like when a Rule Machine action is executing (often something that sends a command to a device--so this is what can be useful if your goal is something like the above) or when Basic Rule or SAR is trying to do something along these lines.
Community apps and drivers do not always follow these conventions, though often they'll do something similar.
How useful these will be ultimately depends on what kind of logging you have enabled, what the app or driver actually logs, and what the nature of your problem is (e.g, they won't be much help in figuring out that your sensor's battery died and that's why you aren't getting motion events--but the lack of such entries in "Logs" if you have description text/info logging enabled, or if you see the same on the "Events" page for the device, could be helpful indicators).
6 Likes
Thank you both for the quick replies, definitely a lot of good information there!
To be honest I never really have understood it. I guess I've just been lucky that I haven't had many issues that necessitated understanding what I was looking at. However, as of late I'm finding myself starting to go deeper down that rabbit hole, and I'm pretty sure my luck will run out sooner or later in that regard!
Here is a log for a Zigbee motion sensor that I just realized tonight maybe not be working. it seems to be reporting Battery level and temperature just fine but doesn't seem to pick up motion.
this sensor worked fine for a few months and has just sorta stopped lately. I had all logging turned off. It was just tonight that I went into it and turned on "Enable debug logging " and "Enable description text logging". After doing this, I went back to try and trigger it, and this is what I got. Not to turn this into a dissection of the device, I do genuinely want to understand what I'm looking at in logs and how to use them.
In this log, If I click Debug or info it takes me back to the device page. If I click what I assume is a device number (that looks like a link) dev:343, it doesn't do anything.
Here is a different one:
The same thing happens. Clicking on Info, Error, Warn, or Debug all just take me back to the device page. the dev:298 doesn't do anything again.
I know I have to be missing the big picture. otherwise, the logs seem sorta pointless to me right now.
Now I'm really feeling kinda dumb. I never noticed that before..
1 Like
Clicking on the left most column is simply a sort. The logs not for that device are suppressed and you can look at the logs for one specific device only. Clicking it again, appears to do nothing because it's already in that final state.
You can also see at the top of the page that one specific device becomes selected. "All" becomes unselected and the device you are focusing on becomes all the log displays. Functionally the two clicks are the same, but they are based on a) the name, or b) the id. Both get to the same display of the logs.
1 Like
You mention battery and therefore I'm going to suggest exactly that... change the battery and verify motion resumes. I'm thinking the battery is barely good enough to power the radio and the power needed to drive the PIR is larger than sensing a memory location (last battery state) or a temp sensor.
2 Likes
Funny you mention that. I just did that a couple weeks ago when I last suspected it was having problems. At that time, it was showing 95% percent, but I thought maybe it was just not reporting correctly. I put s new set of batteries in and it worked fine for a couple Weeks. I just noticed again last night that it seems like its not working again.
To follow up, I do now the batteries are good. They were brand-new a few weeks ago when I put them in. It is currently reporting 100% battery, and the temperature it reports is correct. It matches the temperature reported by another zwave motion sensor in the same zone, and is in the ballpark with a Soniff temperature sensor in the attic above it..
