Empty reply found when expecting JSON data

Configuration
1

Since 2023.9.x I have lots of warnings in my log.

2023-09-15 00:45:40.989 WARNING (MainThread) [homeassistant.components.rest.util] Empty reply found when expecting JSON data
2023-09-15 00:46:10.942 WARNING (MainThread) [homeassistant.components.rest.util] Empty reply found when expecting JSON data
2023-09-15 00:46:40.989 WARNING (MainThread) [homeassistant.components.rest.util] Empty reply found when expecting JSON data
2023-09-15 00:47:11.005 WARNING (MainThread) [homeassistant.components.rest.util] Empty reply found when expecting JSON data
2023-09-15 00:47:40.989 WARNING (MainThread) [homeassistant.components.rest.util] Empty reply found when expecting JSON data

But even with

homeassistant.components.rest.util: debug

I only get the lines above and no details about which call or context brings it.

I assume I know which is the relevant REST call, but is there no option to see more context/proof?

And if it the call I have in mind how to avoid the warnings in the rest sensor? Most probably they appear when the REST endpoint is not available. But I would like to skip this warnings in that case and I would think that another warning (endpoint not reachable) would be even more important than an “empty” JSON.

2

Just to be sure: you know that you can add a Log filter to exclude specific logs at specific levels?
For instance like this:

# Setting the logging level
# The logging level can temporarily be changed for components via the service: logger.set_level
logger:
  default: warn
  logs:
    homeassistant.components.rest.util: error
3

Yes, I know. But this would be a all or nothing. Because of the missing detail and context in this waring message.

So first I would like to know which sensor (or whatever else) is producing this warnings.

4

Did you ever figure this out ? I have an error and I am trying to track it down as well

5

No. Neither to get any more detailed error/waring log which is leading to the right underlying entity/config nor to define for specific REST interfaces, that an unreachable is o.k. and should not be responded with an error/warning.

6

so I was able to get to the bottom of this by turning httpx logger up to debug and then I could see the path and host of the failing request and track it back to the integration at fault… I did bump the rest logger a bit too, but it wasnt really all that helpful and settled on httpx: debug.