Important point perhaps, the ESPHome devices do not connect to HA, HA connects to the ESPHome device.
Not sure about the rest, your Home Assistant perhaps has them configured with a different IP, but after deletion you should be able to add them.
Did you try to add them to HA using the GUI (add new ESPhome device, enter hostname or IP, enter api key when asked for) instead of using discovery?
Thanks for the input Armin.
I was not aware of the detail about Home Assistant connecting to the ESPHome device and not the other way around.
I found out that I can also ping my devices with fixed IPs, so they have indeed connected to the wifi.
And the smart plugs without fixed IP’s I can visit with a browser and see that they are alive and well.
So my ESPHome devices are either ignoring Home Assistant’s attempts to talk to them (maybe because of API password issues?) or Home Assistant is not trying to contact them at all for some strange reason.
I have now tried deleting them and adding them using the GUI (Add device) instead of using the auto-discovery function.
I get the same error message: Can’t connect to ESP. Please make sure your YAML file contains an ‘api:’ line.
So I never even get to the part where I have to enter an API key.
Could you post the IP addresses of your HA setup as well as a few of the ESPHome devices? If for some reason you set a bunch of your devices to use a static IPs and some of your other devices to get IPs via DHCP from your router, it’s possible that there is now a mismatch between either the subnet or the net mask. That could cause a communication issue between HA and the ESPHome devices. I know you said all the settings on your new router were the same, so I might be grasping at straws, but I also don’t want to miss something obvious on the network side.
I am very open to the possibility of some network clash as I am no network engineer and have only basic router experience.
My Home Assistant Raspberry Pi has the fixed IP: 192.168.1.30
Router subnet mask: 255.255.0.0
Router IP address range: 192.168.0.1 ~ 192.168.255.254
My ESPHome devices with static IPs have the following IP’s (although only a few of them are on at the moment):
192.168.2.x (x = 1-10)
192.168.3.x (x = 1-10)
etc.
My non-static IP ESPHome devices currently have the IPs:
192.168.22.197
192.168.25.7
192.168.25.139
Additional information:
I can get logs from my ESPHome devices when connecting one of them directly to my laptop using a serial USB cable.
The devices seems to work perfectly, but no Home Assistant API connection is ever made, which I guess is at the root cause of my problem.
Relevant log output from ESPHome device:
[C][api:025]: Setting up Home Assistant API server...
[D][main:310]: on_boot - Before intial delay
...
[C][api:139]: API Server:
[C][api:140]: Address: 192.168.2.8:6053
[C][api:142]: Using noise encryption: YES
...
[D][main:415]: Skipping sleep cycle - no API connection
The last log entry repeats forever as no API connection is ever made.
I can reflash the ESPHome devices using the serial cable, but this changes nothing.
The last log entry where it is skipping sleep cycle due to no API connection is my own code where I check the condition of api.connected and then refuse a sleep cycle if no API connection has been made.
This code is working fine and in this case it provides a handy log feedback regarding the API connection.
Of course the absence of a successful API connection in the log gives the same information
My limited knowledge says 192.168.x.x should be a class C network not class B
your subnet mask should be 255.255.255.0
and only the last segment for the ip addresses should be different.
But I actaully thought this was more of a genaral rule then stuff not working.
maybe one component has this hardcoded?
what happends if you move everything to a class C network?
The private IP space is classless for the 192 network. So 192.168.0.0 is part of class C but the subnet is /16 for the designated private space, so they should be fine.
@Thomas11 I know the ESPhome Dashboard add-on uses mDNS by default to try to connect to the devices. It uses the friendly name appended with .local to reach out (e.g. friendly name of esp-device would be mDNS of esp-device.local).
Can you reach the web pages using the mDNS name of any of the devices?
A /16-network in the 192.168.x.x range… ok … unusual, but should work.
Usually you would create the private /16-network in 172.y.x.x
Did you check the netmask in your Home-Assistant ? Is it 255.255.0.0 like on the router? Same for the ESPHome devices with static address?
ping 192.168.2.8
Reply from 192.168.2.8: bytes=32 time=3ms TTL=255
Reply from 192.168.2.8: bytes=32 time=5ms TTL=255
Reply from 192.168.2.8: bytes=32 time=12ms TTL=255
Reply from 192.168.2.8: bytes=32 time=5ms TTL=255
I am unsure as to how I can ping it using mDNS.
You suggested friendly name with .local appended, but won’t that make the command: ping ESP32 Mini 8.local
This obviously gives an error.
When I instead try to write: ping esp32mini8.local
I get the following error:
Ping request could not find host esp32mini8.local. Please check the name and try again.
Was that what you wanted me to try?
I can access the homepage of my smart plugs using their IP addresses (e.g. 192.168.22.197).
I cannot however reach the webpage of my “ordinary” esp32 modules by just typing their IP addresses in a browser (like 192.168.2.8 or 192.168.2.8:6053 or 192.168.2.8:50), but I do know that they are on the wifi network.
I had even added the following to the yaml configuration, but it did not help.
I have not (recently) changed the netmask in Home Assistant.
I only recently changed it in the router and the ESPHome devices’ yaml files.
I was not aware of this having to also be changed in Home Assistant.
That being said, everything works perfectly with my old router. I am just not sure why
If I go into Home Assistant and look at the network settings under Configure network interfaces it lists the IP address/Netmask as: 192.168.1.30/24
I am a network novice, but I am guessing that /24 may not correspond to 255.255.0.0 ?
Dinner is calling, but I will research this afterwards.
Yes. So that tells me mDNS isn’t working properly.
If your ordinary devices didn’t already have the web_server enabled, then that’s not going to help. Adding the config to the YAML doesn’t change anything on the device. For that particular setting, you’d have to add the config and then do an OTA update to have it added to the firmware that’s running on the device.
I would start by fixing this:
since you definitely want to make sure the IP config in HA matches what you are doing at the router level (in theory though, this should still work).
If that doesn’t fix things, then I would focus on a single device at first.
Edit the YAML again and add the use_address option under the WiFi section. This will tell the ESPhome Dashboard to attempt to connect to the device by IP instead of mDNS.
TLDR: I got it working again - thanks a lot for all your help
Long version:
It was my Home Assistant network setting Configure network interfaces where the IP address/Netmask was: 192.168.1.30/24
I changed it to 192.168.1.30/16 after which everything connected like a charm.
I had never touched the /24 part, which apparently is the same as a subnet mask of 255.255.255.0 meaning that only the last byte/octet can be used by individual devices - or at least that Home Assistant will not talk to anybody beyond that range.
Recently (a month ago) I decided to put my ESPHome devices on what I thought was some well planned IP ranges as shown here:
192.168.2.x all my esp32 minis
192.168.3.x all my esp32 devboards
192.168.4.x all my esp32-cams
192.168.5.x all my esp32 smartplugs
192.168.6.x all my esp8266 D1 minis
etc.
I knew I had to update the relevant yamls for the ESPHome devices as well as the router settings and this worked very well with my old router.
All ESPHome devices had originally been flashed and given a DHCP IP of 192.168.1.x, which I then changed to statics IPs.
They all connected nicely to Home Assistant with their new static IPs and I could make nice dashboards with all the sensor data.
Being a network novice, I had no idea I also had to change the /24 setting in Home Assistant as well and apparently it worked with the old router without changing that setting.
That shouldn’t have worked according to my new understanding, but it did.
Maybe the fact that they were accepted into Home Assistant when they still had the old IPs that were allowed according to the /24 setting was the reason that they were not thrown out of HA even though their IPs later changed beyond the /24 scope?
Anyway, my problem arrived when I took a new router into use even though it had the same settings as the old one.
And the problem went away as soon as the /24 setting was changed to /16.
I was a bit baffled about not getting a response from ping esp32mini8.local when I did get a response when pinging its IP directly.
But obviously this was because I was pinging from my Windows PC prompt and not from the Raspberry Pi Home Assistant terminal.
When I finally realized this, I tried ping esp32mini8.local from the HA terminal and got a response
I can still get to my smart plugs web pages just by typing their IPs in a browser.
I am not, however, able to do that though for my ordinary ESP32 devices in spite of adding the web_server: port: 80 lines to their yaml (and of course flashing the devices).
But this is not so important for me right now.
I guess it requires more knowledge about the ESPHome web server component, CSS or other stuff in order to setup a web page that shows the sensor data.
I just expected that a web page would be created automatically on ESPHome devices.
Anyway - Thanks a lot for all the help.
You saved the day
Yes, that was the bit I did not spot. I had got to the right page but did not figure out the combination of ‘expand’ and ‘select static’.
I successfully changed /24 to /16. Unfortunately, it did not solve my problem, so perhaps mine has a different cause. I will post it as a separate issue shortly.
Thanks. FIY, I now opened my own discussion in this thread. It seems to be more a problem of how the mesh network is set up in the first place, so that is my first remedy.