#esphome not talking to haos

1 messages · Page 1 of 1 (latest)

quiet ether
#

i`m green... sorry. the esphome folks seem to think my dns isnt allowing esphome through... thisis the error im recieving

#

Platform Manager: Installing platformio/espressif8266 @ 3.2.0
INFO Installing platformio/espressif8266 @ 3.2.0
WARNING Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7f5bea5fa410>: Failed to resolve 'api.registry.platformio.org' ([Errno -3] Temporary failure in name resolution)")': /v3/packages/platformio/platform/espressif8266

versed crypt
#

Can you try nslookup api.registry.platformio.org via SSH?

quiet ether
#

great question... havent tried ssh onto that machine yet

#

sooo. the HAOS cannot see the internet... but why can it install addons?

#

from my HAOS... 127.0.0.11 servfail

versed crypt
#

Run ha network info and ha resolution info and please use code blocks

quiet ether
#

`[core-ssh ~]$ ha network info and ha resolution info
Error: accepts at most 1 arg(s), received 4
Usage:
ha network info [interface] [flags]

Aliases:
info, in, inf

Examples:

ha network info
ha network info eth0

Flags:
-h, --help help for info

Global Flags:
--api-token string Home Assistant Supervisor API token
--config string Optional config file (default is $HOME/.homeassistant.yaml)
--endpoint string Endpoint for Home Assistant Supervisor (default is 'supervisor')
--log-level string Log level (defaults to Warn)
--no-progress Disable the progress spinner
--raw-json Output raw JSON from the API

FATA[0000] Error while executing rootCmd: accepts at most 1 arg(s), received 4 `

fast spade
#

Those are two seperate commands:
ha network info
and
ha resolution info

quiet ether
#

sorry... `[core-ssh ~]$ ha network info
docker:
address: 172.30###
dns: 172.30.####
gateway: 172.30###
interface: hassio
host_internet: true
interfaces:

  • connected: true
    enabled: true
    interface: enp1s0
    ipv4:
    address:
    • 192.168.0.80/24
      gateway: 192.168.0.1
      method: auto
      nameservers:
    • 192.168.0.1
      ready: true
      ipv6:
      address:
    • fe80::38f2:b23c:4####
      gateway: null
      method: auto
      nameservers: []
      ready: false
      mac: 6C:2B:59###
      primary: true
      type: ethernet
      vlan: null
      wifi: null
      supervisor_internet: true
      `
fast spade
#

No need to hide the 172, 192 and fe80 ip addresses. those are local

quiet ether
#

`[core-ssh ~]$ ha resolution info
checks:

  • enabled: true
    slug: docker_config
  • enabled: true
    slug: free_space
  • enabled: true
    slug: network_interface_ipv4
  • enabled: true
    slug: core_security
  • enabled: true
    slug: addon_pwned
  • enabled: true
    slug: multiple_data_disks
  • enabled: true
    slug: supervisor_trust
  • enabled: true
    slug: dns_server
  • enabled: true
    slug: dns_server_ipv6
  • enabled: true
    slug: backups
    issues:
  • context: system
    reference: null
    type: no_current_backup
    uuid: b674d24ed78146d08f1####
    suggestions:
  • auto: false
    context: system
    reference: null
    type: create_full_backup
    uuid: 1b85d06219ca459####
    unhealthy: []
    unsupported: []
    `
quiet ether
quiet ether
fast spade
#

The 172 network is Docker's internal network. The 192 network is your LAN, as well as the fe80 one

#

If you disable IPv6 in HAOS, does it start to work?

#

You can find it in Settings - System - Network - Your network adapter - IPv6

quiet ether
versed crypt
fast spade
#

If you try nslookup api.registry.platformio.org 8.8.8.8 does that work?

quiet ether
versed crypt
fast spade
#

And what happens if you try nslookup api.registry.platformio.org 192.168.0.1 ?

quiet ether
#

[core-ssh ~]$ ha dns logs [00:25:03] INFO: Service restart after closing [00:25:04] INFO: Service restart after closing [00:25:06] INFO: Service restart after closing [00:25:07] INFO: Service restart after closing fatal error: unexpected signal during runtime execution

fast spade
#

Setting the router as DNS without fallback and a DNS restart? @versed crypt

versed crypt
#

Yes but that's the third time this month I've seen the dns plugin die. At least it looks like it died.

quiet ether
#

`[core-ssh ~]$ ha dns options --servers dns://8.8.8.8
Command completed successfully.
[core-ssh ~]$ ha dns options --fallback=false
Command completed successfully.
[core-ssh ~]$ ha dns restart
Processing... Done.

Command completed successfully.
[core-ssh ~]$ nslookup api.registry.platformio.org 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53

Non-authoritative answer:
api.registry.platformio.org canonical name = lb1.platformio.org.
Name: lb1.platformio.org
Address: 88.198.170.159

`

versed crypt
fast spade
#

@quiet ether and now nslookup api.registry.platformio.org

versed crypt
quiet ether
#

Thank you for your assistance!!!!! thank you! i must step away for a while.

versed crypt
#

I'd check the docker logs for the dns container but you need the advanced SSH addon or keyboard and monitor for that.
ha dns stats might tell you if it's running though. Can't test anything right now

haughty iron
#

snowy from ESPHome here - we tried a lot of things also to get this running - its a really odd problem

fast spade
#

The problem itself is simple - the solution is the part causing headaches 😆

haughty iron
#

yeah DNS is screwed

#

but how?

versed crypt
#

127.0.0.11 is docker's internal DNS thingy which should query the server set on the host.
Here's were it gets interesting/confusing.

Core SSH nameserver

[core-ssh ~]$ grep nameserver /etc/resolv.conf
nameserver 127.0.0.11

As mentioned above. Docker internal.

Advanced SSH Addon nameserver

~ # grep nameserver /etc/resolv.conf
nameserver 172.30.32.3

172.30.32.3 is hassio_dns' ip.

Host nameserver

# grep nameserver /etc/resolv.conf
nameserver 192.168.1.50

My primary DNS server's ip.

#

So what happens if hassio_dns is stopped? Or, if my guess is right, it died in spectacular fashion?

Core SSH nslookup

[core-ssh ~]$ nslookup google.com
Server:         127.0.0.11
Address:        127.0.0.11#53

** server can't find google.com: SERVFAIL

Advanced SSH nslookup

~ # nslookup google.com
;; communications error to 172.30.32.3#53: timed out

Host nslookup

# nslookup google.com nslookup
Server:         192.168.1.50
Address:        192.168.1.50:53

Non-authoritative answer:
Name:   google.com
Address: 2a00:1450:4016:809::200e

Non-authoritative answer:
Name:   google.com
Address: 142.250.186.174

[core-ssh ~]$ ha dns stats
Error: Container hassio_dns is not running
fast spade
#

Does a supervisor repair revive your dns container?

versed crypt
#

Nope, it does not start it. I watched in another window with watch -n1 'docker ps | grep dns'.
It doesn't show up in docker ps -a either and it seems like I broke something. I stopped it via docker stop hassio_dns before testing.

[core-ssh ~]$ ha dns stats
Error: 404 Client Error for http+docker://localhost/v1.43/containers/hassio_dns/json: Not Found ("No such container: hassio_dns")
[core-ssh ~]$ ha dns restart
Processing... Done.

Error: Can't start CoreDNS plugin
[core-ssh ~]$ ha dns logs # < No output

Oops. It comes back after a reboot though.

fast spade
#

🤔

versed crypt
#

I'm a bit confused as well but hopefully the info above helps a bit with figuring it out

versed crypt
#

A little bit more information I want to share. 127.0.0.11 is only used for custom networking.

root@debian:~# docker run --network test --rm debian grep nameserver /etc/resolv.conf
nameserver 127.0.0.11

root@debian:~# docker run --network host --rm debian grep nameserver /etc/resolv.conf
nameserver 192.168.1.1

root@debian:~# docker run --rm debian grep nameserver /etc/resolv.conf
nameserver 192.168.1.1

Here's the interesting part. 192.168.1.1 is blocked for most devices including this one (reject rule).

root@debian:~# docker run --network test --rm -it debian bash
root@abf12646bd89:/# grep nameserver /etc/resolv.conf
nameserver 127.0.0.11

root@abf12646bd89:/# apt update && apt install dnsutils -y
...
W: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease  Temporary failure resolving 'deb.debian.org'

So what happens if I change the name server on the host back to something that works?

root@debian:~# grep nameserver /etc/resolv.conf
nameserver 192.168.1.50

root@abf12646bd89:/# grep nameserver /etc/resolv.conf
nameserver 127.0.0.11

No change as expected but.

root@abf12646bd89:/# apt update && apt install dnsutils -y
...
W: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease  Temporary failure resolving 'deb.debian.org'

It still fails until the container is recreated.
So what do the SSH addons use?

# docker inspect addon_a0d7b954_ssh | jq .[].NetworkSettings.Networks
{
  "host": {
  ....
}

# docker inspect addon_core_ssh | jq .[].NetworkSettings.Networks
{
  "hassio": {
  ...
}

That explains the different addresses here: <#1176295714108747807 message>
Sorry for the editing mess I had to trick the bot (I hope that's okay in a thread?) and prematurely send.
I want to reference and search for this in the future hence I felt it necessary to keep it all in one place.
TLDR: Try a reboot (not a HA restart).

quiet ether
#

this is all over my head... but for the record, i did reboot the computer. is the general consensus that i should reinstall HAOS? i really do appreciate all the help today! i appears to be quite the puzzle. does this happen often (wierd puzzles that can cause things to not work)? if so, i'm thinking this home assistant world isn't going to be for me. probably throwing in the proverbial hat🤷

versed crypt
#

A big part of why it write this down is so I can reference it later. I'll probably forget about it as well. It would also be a waste not to share my findings.
Sometimes it can make sense to re-flash but I'd like to take a look at the logs for hassio_dns first. You can get them via docker logs hassio_dns.
You can run this either via a attached keyboard and monitor (enter login first) or you can install the advanced SSH addon, disable its protection mode and then run it with it.
As I shared here I saw a few big failures with the DNS plugin and if yours is similar we (you) should let the devs know about it:

haughty iron
quiet ether
# haughty iron well that's the thing, you have had some of the best guys from HA and ESPHome lo...

i do appreciate your comment. TBH, please no offence, i had no idea who i was dealing with and am happy to hear your opinion of credit to those helping my situation. I've spent the last hour collecting as much info as possible to post to the github issues, i'm happy to help if this is a "HA" problem and not a "me" problem. As impact suggested i'm going to post to devs at github... unless there's a better place you'd suggest it be address officially.

versed crypt
#

But please share the docker log first.

quiet ether
fast spade
#

The DNS container might be corrupted. A try to fix it would be a downgrade to an older version, followed by an upgrade to the present one.
ha dns update --version 2022.04.1
When this command is completed, you can do the upgrade with
ha dns update --version 2023.06.2

#

In hope, it can perform the task in the present state

quiet ether
#

does this mean what i think it means?

fast spade
#

Looks promising

#

I would do a full reboot and try to do the ESPHome stuff after that

quiet ether
#

i work in healthcare and there are probalby many things i do that are "magic" to those on the outside looking in... i just had a moment right there with esphome... so that's how it's supposed to run! Linking .pioenvs/esphome-web-657be5/firmware.elf RAM: [==== ] 42.4% (used 34716 bytes from 81920 bytes) Flash: [===== ] 48.8% (used 499709 bytes from 1023984 bytes) Building .pioenvs/esphome-web-657be5/firmware.bin esp8266_copy_factory_bin([".pioenvs/esphome-web-657be5/firmware.bin"], [".pioenvs/esphome-web-657be5/firmware.elf"]) ======================== [SUCCESS] Took 120.36 seconds ======================== INFO Successfully compiled program.

#

i didn't reboot... oops

fast spade
#

The reboot was just to check if everything survives it. No worries 😆

quiet ether
#

umm, i was literally downloading the generic x86 to flash and nuke the haos for one last ditch effort.

#

THANK YOU

#

is there somewhere i should post that will alert others to this fix (if that's what it's called)?

fast spade
#

Credits go to a HAOS (and more) developer, who helped us 🎉

#

You could add that information to your GitHub issue before closing. I suppose that's the best archive we have

quiet ether
#

will do. new to discord... do these threads get nuked after they are unused for x days ect?

fast spade
#

They aren't. But Discord isn't great for finding stuff easily

quiet ether
#

Thank you everyone@versed crypt @haughty iron @fast spade dns issue resolved. crossposted to github as well.