Log files are stuffed with pointers towards HA python files and libraries. That’s ok for ultra techies. WTH can’t I just see the typo I made in what sensor, input Boolean etc.?
Could you provide some concrete examples? As in: I get it! And fully agree.
However, to adjust any message, we do need to know what needs to be addressed… right?
So if you come across one, just dump the here 
Here’s one I just saw in my own system (and not related to an automation as OP implied).
Nothing is broken, so I’m not worrying about it or anything; but the error does not help narrow down what exactly caused it.
However, I don’t really agree with the OP. I think having the full technical details in the logs is super helpful, and should not be removed!
In some cases errors can be supplemented with more “human understandable” details possibly, but I think this is a case where nothing should be removed, only added when possible.
2 Likes
That example is beautiful, however, it doesn’t originate from Home Assistant 
They should no be removed but hidden from a common user. Even admin unless they are expanded
to show the rest of the details
The problem with hiding them is that there might be something wrong, but it isn’t visible anymore…
A bit of a pick between evil sides…
3 Likes
Sorry. I don’t mean hide the error. I mean more of show the common error with a more details toggle that will expand to show the error in Python/Javascript
2 Likes
That’s strictly true, but it looks like this was a problem previously, that some changes were made in HA to correct (HA-Core Issue#37791).
Anything that ends up in the HA error log are things that people may end up reporting as issues in the HA codebase (even if it does not originate from Home Assistant), so effective descriptions in all errors is still useful whenever possible.
But this is now offtopic from the OP, my apologies.
1 Like
Here’s one:
2020-08-19 01:31:21 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.139691397965184] Error handling message: Unknown error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 230, in async_render
return compiled.render(kwargs).strip()
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 1090, in render
self.environment.handle_exception()
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 832, in handle_exception
reraise(*rewrite_traceback_stack(source=source))
File "/usr/local/lib/python3.8/site-packages/jinja2/_compat.py", line 28, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
File "/usr/local/lib/python3.8/site-packages/jinja2/sandbox.py", line 460, in call
if not __self.is_safe_callable(__obj):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 1041, in is_safe_callable
return isinstance(obj, AllStates) or super().is_safe_callable(obj)
File "/usr/local/lib/python3.8/site-packages/jinja2/sandbox.py", line 360, in is_safe_callable
getattr(obj, "unsafe_callable", False) or getattr(obj, "alters_data", False)
jinja2.exceptions.UndefinedError: 'None' has no attribute 'split'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/connection.py", line 95, in async_handle
handler(self.hass, self, schema(msg))
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 265, in handle_render_template
state_listener()
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 253, in state_listener
msg["id"], {"result": template.async_render(variables)}
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 232, in async_render
raise TemplateError(err)
homeassistant.exceptions.TemplateError: UndefinedError: 'None' has no attribute 'split'
there’s pretty much no way to figure out where that error originates from.
Honestly I think that is a pretty standard python problem.
2 Likes
Hej @frenck, here you, a simple example.
Invalid option: (possible options: on, off, auto, hand)
So this a typical “WTH, which input_select”.
Context: I created a number of input_selects to monitor the state of devices, these are all controlled by automations. Auto, hand (manual in short in Dutch), on and off. The last two are for the legacy automations still controlling it differently. One of the automations in not working well and is obviously sending a not supported payload to the input_select now and then. However I can’t see which input_select is involved an as a result I can’t see where things go wrong.
This is not the worst I’ve seen, but it gives a good impression. When I find more, I will share.
Regards,
Ralph
2 Likes
Perhaps, in this example the title can be something like: “Error in dependency: yadayada” then the details show the real error. Im sure this was already something that existed, but I can’t be sure. Maybe a generic try except would work higher up the chain to catch these sorts of errors?
That’s a good example of friendlier messaging we could implement. Adding pointers to what and where would be useful here
Most of the problem cases I run into with log spew is about too little context. A few random examples looking at my current log :
WARNING (MainThread) [homeassistant.components.mqtt] JSON result was not a dictionary
I have hundreds of MQTT related devices and a ton of autodiscovery via MQTT. There is no practical way to hunt down the originator of this problem, short of a binary search where I just remove huge parts of my system. Can it spew the problem entry so I have some clue where it is originating?
[homeassistant.helpers.service] Unable to find referenced entities switch.couch_lamp
I’m sure I could grep all my configuration entries and figure out where this problem is, but the error itself is not particularly helpful. What is the service? What’s the context? Is it trying to set up a group? Trying to fire off an automation? A script? Like the previous, just giving additional data would help a ton.
ERROR (MainThread) [frontend.js.latest.202007160] http://assistant.home.lan/lovelace/default_view:0:0 Uncaught
Probably benign(?), but it’s an error that isn’t particularly helpful and probably can’t be resolved by the user. If it is something due to configuration that the user could resolve, there’s not enough data there for me to see what it is. If it’s not user actionable, should it error with default log settings?
WTH only 16 votes? Can’t imagin nobody else is bothered by this 
.
That’s a good example. As it is, that message is extremely unhelpful for solving the problem, only telling you there is one. All that it would need to add is the entity that originated this error to make it 90% better.
It would be a nice improvement if the error logging was written in a way that being able to identify and solve the problem was the foremost intent. If the error message does not help you solve the problem then it’s missed the mark.
3 Likes
If the log details could list the actual condition template that caused this it would be very helpful. I’d settle for the yaml file name.
You are right.
In the meantime perhaps the logbook might tell you what was happening at 8.00 pm on 1 Sept?
Indeed, Python is awful in that regard. While it is fun to write, The fact hat there are no compile time errors and everything then is traceback during runtime is putting the java guy in me off.