0.99: Withings, Device Automations, launch Home Assistant Cast from Python

Is the cert fully trusted? I know that verify_ssl: false on 0.99.3 doesn’t work and the fix has been pushed up into the code base.

Also does

    homeassistant.components.pi_hole: debug

in configuration.xml provide any extra clues?

There were no clues in debug mode also added hole: debug, still nothing to detailed.

I don’t if that the issue but the hole class receives in the constructor arg of verify_tls which is not being passed, instead 1 line above it in the initialization of the session there is a usage of verify_ssl.

Anyway, i assume that’s not the issue since my certificate is a fully trusted (by COMODO)

running out of ideas here :slightly_smiling_face: but if it is fully trusted certificate why not take the verify_ssl:false option out as it should successfully verify. And the wget is over https port 443 as if it is not over that you need to specify the other port e.g. host: pi.DOMAIN.NAME:4865 - others earlier in this topic have modified the pihole configuration itself to get around the problem too.

so what is the output of

nslookup pi.DOMAIN.NAME
bash-5.0# nslookup pi.DOMAIN.NAME

Name:   pi.DOMAIN.NAME
Address: 192.168.***.***

That looks OK doesn’t it. By the way you don’t need to hide your private address space IP addresses.

Same issue in Hassbian, HA 0.99.3

  - platform: pi_hole
    verify_ssl: false
2019-10-02 02:40:41 ERROR (MainThread) [homeassistant.setup] Error during setup of component pi_hole
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/setup.py", line 168, in _async_setup_component
    hass, processed_config
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/pi_hole/__init__.py", line 47, in async_setup
    conf = config[DOMAIN]
KeyError: 'pi_hole'
2019-10-02 02:40:41 ERROR (MainThread) [homeassistant.setup] Unable to prepare setup for platform pi_hole.sensor: Unable to set up component.

Your configuration is not correct, check the breaking changes and/or the updated documentation for that integration.

1 Like

All good.

Moved Pi-Hole to configuration.yaml as below.

  verify_ssl: false

I think I better understand the issue, when i previously ran the hole example I ran it in the machine not inside the docker and it ran, running it from the docker itself:

import asyncio
import json

import aiohttp

from hole import Hole

async def main():
    """Get the data from a *hole instance."""
    async with aiohttp.ClientSession() as session:
        data = Hole('pi.DOMAIN.NAME', loop, session, tls=True, verify_tls=False)
        await data.get_versions()
        print(json.dumps(data.data, indent=4, sort_keys=True))
        await data.get_data()
        # Get the raw data
        print(json.dumps(data.data, indent=4, sort_keys=True))
        print("Status:", data.status)
        print("Domains being blocked:", data.domains_being_blocked)

loop = asyncio.get_event_loop()

got me the following response:

Can not load data from *hole: pi.DOMAIN.NAME
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/aiohttp/connector.py", line 924, in _wrap_create_connection
    await self._loop.create_connection(*args, **kwargs))
  File "/usr/local/lib/python3.7/asyncio/base_events.py", line 981, in create_connection
  File "/usr/local/lib/python3.7/asyncio/base_events.py", line 1009, in _create_connection_transport
    await waiter
  File "/usr/local/lib/python3.7/asyncio/sslproto.py", line 530, in data_received
    ssldata, appdata = self._sslpipe.feed_ssldata(data)
  File "/usr/local/lib/python3.7/asyncio/sslproto.py", line 189, in feed_ssldata
  File "/usr/local/lib/python3.7/ssl.py", line 774, in do_handshake
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/hole/__init__.py", line 55, in get_versions
  File "/usr/local/lib/python3.7/site-packages/aiohttp/client.py", line 476, in _request
  File "/usr/local/lib/python3.7/site-packages/aiohttp/connector.py", line 522, in connect
    proto = await self._create_connection(req, traces, timeout)
  File "/usr/local/lib/python3.7/site-packages/aiohttp/connector.py", line 854, in _create_connection
    req, traces, timeout)
  File "/usr/local/lib/python3.7/site-packages/aiohttp/connector.py", line 992, in _create_direct_connection
    raise last_exc
  File "/usr/local/lib/python3.7/site-packages/aiohttp/connector.py", line 974, in _create_direct_connection
    req=req, client_error=client_error)
  File "/usr/local/lib/python3.7/site-packages/aiohttp/connector.py", line 927, in _wrap_create_connection
    req.connection_key, exc) from exc
aiohttp.client_exceptions.ClientConnectorCertificateError: Cannot connect to host pi.DOMAIN.NAME:443 ssl:True [SSLCertVerificationError: (1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)')]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/asyncio/base_events.py", line 579, in run_until_complete
    return future.result()
  File "<stdin>", line 5, in main
  File "/usr/local/lib/python3.7/site-packages/hole/__init__.py", line 65, in get_versions
    raise exceptions.HoleConnectionError(msg)
hole.exceptions.HoleConnectionError: Can not load data from *hole: pi.DOMAIN.NAME

after looking at that issue within Alpine, i got to the following fix:

    async with aiohttp.ClientSession(connector=aiohttp.TCPConnector(verify_ssl=False)) as session:

the only problem is, I don’t know what is missing in HA code to fix it

You should elevate this to gihub IMHO.

Check this regarding verify_ssl:False does not work in 0.99.3 with the fix (or wait until next release I guess)

Since updating to 0.99.3 I’ve started having an issue restarting Home Assistant from the UI (Configuration > Server Control). It never seems to start up successfully. I see lots of errors like this in the log:

[homeassistant.components.recorder.util] Error executing query: (sqlite3.OperationalError) database is locked

I end up need to use systemctl to restart it, and it then starts up properly. It looks like when it is being restarted via the UI, it isn’t releasing the lock on the database. I’d never noticed this happening with previous versions.

Is your database corrupt? i.e. are you seeing history update for entities?

The history appears to be updating correctly, the only gaps in the history have been the periods when it is restarting (and if I restart it from the UI the database locks mean there’s nothing in the history until I restart using systemctl).
I haven’t noticed any gaps in the history or any database lock during normal operation.

Edit: I actually noticed today that I was seeing some “database is locked” errors during the normal operation. I decided to try repairing the database (using the commands here).
Once Home Assistant was back up I tried restarting from the UI and it worked fine, so probably just a coincidence that this happened at about the same time as updating to 0.99.3

Anyone else having problems with the .99 builds. Both 99.2 and .3 crash for me every few hours. What’s weird is the main process stays running, logs keep generating but the we service dies and so do automations and integrations. Very frustrating. I’ve tried disabling various integrations to see what the culprit to no avail… the log doesn’t even note anything that indicates errors.

Probably not. I’ve lost count of reports of database corruption during updates reported in these forums.

Agreed. My #1 go to when there is a sniff of a database issue is to delete it and restart HA.

Can anyone provide some insight?

Upgraded to 99.3 from a perfect working 93.x install… now HA crashes every few hours… I’ve turned off countless integrations, upgraded Ubuntu, upgraded Python, did a clean install in a new Venv… still crashes.

The strange part is the process doesn’t exit, just automations, web access and any Alexa integrations don’t work but it still keeps logging ISY communication, nest and other things.

The logs don’t indicate any errors or warnings when the crash happens either.

I also have these log messages. Are you able to solve it?