Skip to content

Conversation

@ekutner
Copy link
Contributor

@ekutner ekutner commented Nov 2, 2025

Currently when a call to Home Assistant fails the log entry in appdaemon is pretty useless. It just says "Error with websocket result" and gives the error information but without knowing the context of the call, the service that was called, it's impossible to know what user code caused it in the first place. Theoretically it may be possible to get this information by running appdaemon with loglevel=DEBUG but that is not practical for a production environment.

This PR saves the request based on the call_id, in the same way that silent_result is handled, and then writes it to the log in case the response indicated an error.

@jsl12
Copy link
Contributor

jsl12 commented Nov 7, 2025

Thanks for the contribution, and apologies for the delay. I've been pretty busy recently, and I assume @acockburn has been too.

I really like the idea of including contextual information with each request, but I think maybe we should make each context a dataclass and fold the other stuff (result_futures and _silent_results) into it too.

In the meantime, there are some other ways to debug wonky service calls. Also, the standard error messages have been improved relatively recently, so it should pass through whatever the error message is directly from HA

@ekutner
Copy link
Contributor Author

ekutner commented Nov 8, 2025

It would definitely be nicer but I was going for a minimal change and followed a pattern that was already in place for connecting requests with responses.
The "other ways" you mention are useful when you know where the problem is and just need more information about it, but they're not that useful when there are many service calls and you get some generic statement from HA that doesn't actually help with understanding which call is causing it. In such a case it is very useful to know exactly which service call ended up with the error response. In my case, adding this context information was the only way I could find the source of an error I was getting because the debug log was just too messy to follow (I have a rather complex implementation).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants