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
logger:
logs:
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 
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.NAMEbash-5.0# nslookup pi.DOMAIN.NAME
Server: 172.30.32.3
Address: 172.30.32.3#53
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
sensor:
- platform: pi_hole
host: 192.168.200.209:80
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.
pi_hole
host: 192.168.200.209:80
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()
loop.run_until_complete(main())
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
ssl_handshake_timeout=ssl_handshake_timeout)
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
self._sslobj.do_handshake()
File "/usr/local/lib/python3.7/ssl.py", line 774, in do_handshake
self._sslobj.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
params=params)
File "/usr/local/lib/python3.7/site-packages/aiohttp/client.py", line 476, in _request
timeout=real_timeout
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?