Unifi device tracker component SSL errors

Configuration
1

As of the new pyunifi update I’v e been getting these warnings:

2017-05-08 16:03:43 WARNING (Thread-5) [py.warnings] /srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py:852: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)

Would it be possible to disable these warnings when verify_ssl: False is set?

My unifi controller is ONLY available on my LAN.

1 Like
2

It was originally disabled. However, per the request of the HASS team, it was enabled. I would recommend adjusting the unifi component logging level: https://home-assistant.io/components/logger/. I changed my device_tracker unifi component specifically to “critical”.

1 Like
3

Well before I got the chance to read this, the problem destroyed my HA installation.

System ran out of space due to the log file growing thanks to this message and needed to be rebooted… All config files have been zero’d… No backup.

4

FYI, it seems impossible to block this warning using the logging level. It doesn’t appear to be the unifi component which blurts out the error, but it IS the unifi component which CAUSES the error to be blurted out.

Also I’m not the only one having problems with this. 0.44.2 problems

5

If the logger doesn’t block the messages, that’s a pretty serious issue then. Looks like I will have to disable the use of the unifi tracker until this is resolved. :frowning:

6

Guess it is a good thing I have not updated to 44.X yet. The unifi component is kind of important to my config and I run off of a PI and an SD card.

7

I’ve done some further checking, and I’ve been able to figure out the following.

There was a change in the pyunifi package, where the InsecureRequestWarning is no longer disabled, but warnings in general are being captured.

According to the python documentation, the way it is handled is as follows:

If capture is True, warnings issued by the warnings module will be redirected to the logging system. Specifically, a warning will be formatted using warnings.formatwarning() and the resulting string logged to a logger named ‘py.warnings’ with a severity of WARNING.

This means that in order to suppress these error messages you need to configure something like the following in your configuration.yaml:

logger:
  default: info
  logs:
    py.warnings: error
2 Likes
8

I am running Home Assistant in a docker on my Unraid server. These errors are flooding my logs at an incredible rate, and they always seem to wait until I am asleep. A few mornings in a row I woke up to notifications on my phone about my docker.img file being out of space. I narrowed it down to the homeassistant container, and then to these errors. In this situation, it is not only flooding home-assistant.log with the errors, but also my docker container log. Both of these files went up to 15GB each. Crazy.

So I wiped out my home-assistant.log file, and nuked my docker.img and started over (keeping my config files obviously). I added this to my config:

logger:
  default: info
  logs:
    py.warnings: error

with default: info you will get a ton more in your log files (I didn’t catch this either before trying it). So I tried again, like this:

logger:
default: warning
  logs:
    py.warnings: error

I figured this way, I will get anything “warning” or above, while cutting out the “py.warning” junk from the Unifi component. This worked! Or at least it seemed to…

This morning, once again, I woke up to notifications that my docker.img file was almost full again. I stopped the container and looked at the container logs, now I am seeing the exact same message but with “ERROR” instead of “WARNING”. It’s like playing whack-a-mole with logging levels.

9

I’m currently using the following and it seemed to work until a new error appeared:

logger:
  default: error
  logs:
    requests.packages.urllib3.connectionpool: critical
    py.warnings: critical

The new error was REALLY spamming the log file:

grep pyunifi home-assistant.log |wc -l
 10215434

It was as follows:

2017-05-22 21:17:38 ERROR (Thread-9) [pyunifi.controller] Expecting value: line 1 column 1 (char 0)

Anyone ever see that?

10

Yup, same here. I had to disable the unifi device tracker. Too bad, when it worked it was excellent. These APs are so good, I was connecting as soon as I pulled into my driveway. Looks like I am going back to Owntracks/Tasker/MQTT.

11

It happened twice again since I last posted. I’ve also had to disable the unify tracker as it is not just functionally, but dangerous.

Hopefully the problem will get resolved soon.

12

Has anyone re-enabled the unifi tracker component after updating to 0.47.0? I have not yet, but plan to next weekend when I can more closely monitor the logs.

13

Seems to be solved in 0.47

14

So far so good.

15

I’m now seeing this behavior running against a unifi instance on hass version 0.57.2. Disabling the Unifi component removes the error. Has anyone had this behavior return recently? It is just crushing my logs, and disabling logging for the unifi component doesn’t resolve the issue.

16

I’m seeing it in my logs also. It wasn’t appearing for me previous to upgrading to 0.57.2.

17

This issue is still present in 0.62. No fixes suggested appear to work, setting logger to critical still presents these messages.