SMTP Mail notification fails frequently

I have an an email notification using Google that works only sometimes. It fails every 2-3 executions with the error:

  'utf-8' codec can't decode byte 0xa8 in position 19: invalid start byte

The decoded byte is usually 0xa8 but sometimes 0x80, 0xC0, and others as well. There is no change in the running automation between executions.

The log shows this as the last line of code executed:

File "/usr/local/lib/python3.11/socket.py", line 794, in getfqdn
    hostname, aliases, ipaddrs = gethostbyaddr(name)
                                 ^^^^^^^^^^^^^^^^^^^`

Does anyone know where I could find the value of the “name” variable being used for lookup?

Disabling the Matter integration worked for a few days, but the problem is back again.

Did you ever figure this out? I’m seeing the same thing. Seems like I can hop to a terminal and do a random host lookup and it’ll work a couple times but then randomly fails.

In my case it was the Matter add-on causing Python to return a hostname with invalid UTF-8 characters. If you don’t have that, take a look at disabling one of your other add-ons until it works. It seems random what hostname Python returns, but it seems it’s always related to one of the add-ons that uses websockets. For example, right now mine is returning the esphome one. I solved it by removing the Matter add-on, which I wasn’t using anyway. The comment from me above about disabling Matter didn’t permanently solve it refers to the integration, but removing the add-on did solve it permanently.

From a terminal I get:

➜  ~ python
Python 3.11.6 (main, Oct  4 2023, 06:22:18) [GCC 12.2.1 20220924] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.gethostbyaddr('homeassistant.local.hass.io')
('core-silabs-multiproto', ['core-silabs-multiproto'], ['172.30.32.1'])

But I don’t really see disabling zigbee support as a viable workaround.

Did you try SMTP now? In my experience notify works as long as the socket.gethostbyaddr doesn’t return the exact same UTF-8 error. That is, I could reproduce the error in Python when it wasn’t working.

I’ve never seen gethostbyaddr fail when I call it manually, but I did stop and re-start the zigbee multiprotocol add-on and now I get:

>>> socket.gethostbyaddr('homeassistant.local.hass.io')
('a0d7b954-spotify.local.hass.io', ['a0d7b954-spotify.local.hass.io'], ['172.30.32.1'])

Previously running the notification service part of my automation would randomly fail within a few calls and now I’ve been able to manually trigger it over 15 times without an error. Great, but a temporary solution. I hope your bug report sees some traction soon.

I was checking on it for a while but gave up. I was surprised more people weren’t noticing the same thing.

I can’t remember now what I did but at one point I was able to see the actual offending hostname, non-UTF-8 characters and all, which is how I knew to disable the Matter add-on. But if you aren’t running Matter there goes my hypothesis that Matter add-on is the problem.

AFAIK the Silicon Labs Multiprotocol add-on does both zigbee and matter/thread.

I’m using Zigbee2MQTT. I bought an Eve Matter motion sensor and tried to pair it with Smartthings but gave up and returned it because I couldn’t get it to work. So I’m only using Zigbee for now and haven’t seen any good Matter devices, at least that I could use.

At one point I played around to see what add-on was providing the hostname, I figured either the first or last add-on loaded at restart, but I gave up. It seems to vary with every restart.