Hello Frank
What is the “Updated fix killall brain damage patch” ???
Thanks Franck! The reason I asked is, I didn’t see an acknowledgement of the issue in the release notes, either. Nor here, nor on GitHub.
I was reluctant to open a new issue on GitHub, because it seemed possible that the change was intentional (if undocumented). I know there have been a lot of security changes recently, and DNS is pretty central to any network’s security. The sensors could have been a temporary victim of tightening the screws. So I was just pinging here first.
If it’s less work for you if we just open issues on GitHub when we encounter problems, I will by all means go directly there. (But, from my day job, creating bugs for things that are not bugs is more work for everyone involved. Hence my reluctance to start there when something isn’t obviously wrong.)
And now, after updating to HA .106.5, the add-on is completely dead.
- The web UI does not load, instead returning a “502: Bad Gateway” error.
- The add-on Logs repeats the following error every few seconds: “nginx: [emerg] invalid number of arguments in “resolver” directive in /etc/nginx/includes/resolver.conf:1”
Seems like we’re moving backwards here…
Hmmm. Restarting Home Assistant didn’t resolve the problem, but I just tried stopping the add-on, and then starting it again, and the web UI is at least back. So, that’s something.
@Frenk I know you advocate using the AdGuard Home add-on instead of the Pi-Hole add-on, but I’ve been uncomfortable with using it, because it’s from a commercial entity, and the “If you’re not paying for the product, you are the product” adage comes to mind. I might find myself changing my mind…
Same issue with sensors here
2020/03/06 03:18:22 [error] 768#768: *437 access forbidden by rule, client: 192.168.2.12, server: a0d7b954-pi-hole, request: "GET /admin/api.php HTTP/1.1", host: "192.168.2.12:4865"
[06/Mar/2020:03:18:22 +0000] 403 -(192.168.2.12) GET /admin/api.php HTTP/1.1 (HomeAssistant/0.106.4 aiohttp/3.6.1 Python/3.7)
Pi-hole is a commercial entity as well… just saying.
Hi!
Having a problem here accessing the API. I have an app with hardcoded URL http://[IP]/admin/api.php. But in my installation the API is available at http://[IP]/api.php.
There is no admin-login at all? When opening the webUI from outside homeassistant the URL shown has no path /admin as well although I’m logged in with user homeassistant.
Config:
update_lists_on_start: false
ssl: false
certfile: fullchain.pem
keyfile: privkey.pem
interface: ''
ipv6: true
ipv4_address: ''
ipv6_address: ''
hosts: []
Network
Container Host Description
4865/tcp 4865 API endpoint (For HA integration)
53/udp 53 DNS server port
80/tcp 80 Web interface (Not required for Ingress)
Regards,
petjek
Hi,
I keep getting this error in my system log:
20-03-09 00:59:22 WARNING (MainThread) [hassio.updater] Can’t fetch versions from https://version.home-assistant.io/stable.json: Cannot connect to host version.home-assistant.io:443 ssl:None [Try again]
Reading through some forums posts I found that this setting would solve my issue:
But when I try to save this I get following error:
Failed CORS: xxxxx.hopto.me vs 192.168.0.101, , a0d7b954-pi-hole, pi.hole, localhost, hassio, hassio.local
This is my Pi-hole settings:
update_lists_on_start: false
ssl: false
certfile: fullchain.pem
keyfile: privkey.pem
interface: ''
ipv6: true
ipv4_address: ''
ipv6_address: ''
hosts: []
virtual_host: xxxxx.hopto.me
Any suggestions on what this can be?
I did uninstall the pi-hole addon and now I get the updates for Home Assistant as usally.
Hi, in order to make a pihole switch I need the API KEY, but if I go
webui— settings—api — show api token .— yes show api token
I receive a web page with NO PASSWORD SET, and no api token is visible ??
@Klagio If you configure your Pi-Hole integration and switch using “localhost:4865”, then access from your Home Assistant instance should just work.
At least, once I read the docs (including the parts I missed the first time), made the changes, and rebooted Home Assistant (full restart), it’s working for me.
My integration is bog standard, but here’s what I’m using for my switch:
# "Simple" method for disabling Pi-Hole on both instances
# This method requires hard-coded strings for the commands, no secrets
switch:
- platform: command_line
scan_interval: 10
switches:
pihole_switch_hassio:
friendly_name: "Ad Blocking (HA)"
command_on: "curl -X GET 'http://localhost:4865/admin/api.php?enable&auth='"
command_off: "curl -X GET 'http://localhost:4865/admin/api.php?disable=60&auth='"
command_state: "curl -X GET 'http://localhost:4865/admin/api.php?status'"
value_template: "{{ value_json.status == 'enabled' }}"
As you can see, just using the empty API key auth= (along with localhost) is the trick.
mmhhh I have two instances of HASSIO, on my main I use Adguard, on my second I use pi-hole. And then I use as DNS address 1 the address of HASSIO main, and DNS address 2, the address of HASSIO second
SO from HASSIO main, I guess I can’t access the HASSIo/PI-HOLE on the second? Because I wish to have the 2 switches (to turn on/off Adguard and turn on/off pihole), only in HASSIO main
Of course I will not use localhost, but just the IP address 192.168.1.x
Hello,
is there a way to start pihole addon not from Supervisor ?
I use portainer and everytime i try to start pihole addon from portainer, pihole starts and then stop it.
This is useful in case of docker upgrade, since pihole will not restart by itself and will not turn it on automatically.
Or maybe i’m blind, if there is a way let me know, thanks.
p.s. nodered addon has the same issue.
I have a script for all HA add-ons I use under exactly that circumstance. None of them stay started with Portainer.
Can you please post it?
The issue is not only portainer, if i docker start addon_a0d7b954_pi-hole it won’t stay on anyway 
adguard addon has not that issue.
startalladdons:
alias: Start all Hass.io addons
sequence:
- data: {"addon": "7be23ff5_dropbox_sync"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_appdaemon"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_glances"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_jupyterlablite"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_logviewer"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_sonweb"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_ssh"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_vscode"}
service: hassio.addon_start
- data: {"addon": "a0d7b954_zerotier"}
service: hassio.addon_start
- data: {"addon": "core_configurator"}
service: hassio.addon_start
- data: {"addon": "core_mosquitto"}
service: hassio.addon_start
- data: {"addon": "core_samba"}
service: hassio.addon_start
- data: {"addon": "fe41fc28_caddy"}
service: hassio.addon_start
And I use a button-card to execute it. Docker start would have the same problem as Portainer.
ah, an HA script, i thought it was a bash script 
Thanks for that, will do some tests.
It’s really strange why some docker containers can’t start by itself via cli or gui while other containers can 
I’m not really a fan of “let low level tasks be done via HA” and hope it could be fixed a day.
None of the HA containers will stay running if started via Portainer. Non ha ones will.
mmm, not really true, i can stop and start for example: portainer, esphome, mosquitto.
Am i missing something?
No idea but for HA containers I have to use that script.