So I did the update to ESP 1.14.
After doing that, almost all esphome devices are shown as offline.
They still react in Home Assistant, but is shown as offline in ESPHome.
They are all configured as dynamic IP.
I’ve started converting them to static IP, and with a static IP they are all online (I can still do OTA via esphome in HA)
Same for me, opened topic here, but only esp32 nodes have resolving issues, esp8266 are fine. May be mdns related, but not a 100% sure.
I wonder if it’s because it is now using asynctcp, I seem to recall a problem with certain kernel levels?
I’ve gone through most of the entities now, and changed it to static IP’s, but the entities still shows as offline., but they can still show logs in the interface, so they are indeed online.
Ok, I updated to 1.14.2
It’s better than before, but not really as rocksolid as 1.13.6 
I’ve just been told that the coffemachine is now off (it has been off for a long while), but weird things happen.
I think some of it is because they actually need to be powercycled after being updated 
It does look like it’s better, but the ESPHome interface is taking forever to show them as online (if they ever show as green), but they can show the logfiles, so I guess they are online.
@DasBootU96 how do I use the mdns chrome plugin to check that?
For a Windows (10) machine, make sure it is on the same subnet as your ESP nodes. Install Chrome, then install the mdns-browser extension and run it. Sort by IP.
In the Wifi AP I can lookup the ESP leases for ESPHome modules and check if they announce themselves using mdns in the mdns browser.
For me, ESP32 with ESPHome 1.14.2 do not announce mdns and as a result I can not update and showing logfiles takes ages, but ESP8266 with ESPHome 1.14.2 work perfectly fine. And ESP32 with previous ESPHome 1.13.6 builds also announce mdns and work just fine without issues.
For me, mdns browser looks like this:
Ah, I had missed that it was an application in itself, I tried all sorts of tricks in Chrome 
Ok, so out of 14 esphome devices, I see 7 in mDNS ???
And then 10, and then a minute later 5, it’s really weird, and in the esphome page in HA, it shows unavailable and offline very random.
I wonder, can I roll back to 1.13.6 by restoring the esphome snapshot from before the upgrade, and then reflash the devices?
You should be able to. I wish I could as 0.14.0 killed my connection to HA.
I’m working through them, it looks like it works perfertly, it offers an update from 14.2 to 13.6
Google backup addon is a godsend 
I wonder if it’s because AsyncTCP has been updated. This one shows 1.2.0 when it compiles.
Ok, the recompiling of my sonoff rf bridge is crapping out
But the rest are fine, and are all showing as online.
The RF Bridge shows this, I’ve done a ‘clean’ and a ‘compile’ but no change:
Linking /data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/firmware.elf
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib90f/[email protected](ESPAsyncTCP.cpp.o): In function `AsyncClient::_s_recv(void*, tcp_pcb*, pbuf*, long)':
ESPAsyncTCP.cpp:(.text._ZN11AsyncClient7_s_recvEPvP7tcp_pcbP4pbufl+0x4): multiple definition of `AsyncClient::_s_recv(void*, tcp_pcb*, pbuf*, long)'
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib67a/libESPAsyncTCP_ID305.a(ESPAsyncTCP.cpp.o):ESPAsyncTCP.cpp:(.text._ZN11AsyncClient7_s_recvEPvP7tcp_pcbP4pbufl+0x10): first defined here
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib90f/[email protected](ESPAsyncTCP.cpp.o): In function `AsyncClient::_s_sent(void*, tcp_pcb*, unsigned short)':
ESPAsyncTCP.cpp:(.text._ZN11AsyncClient7_s_sentEPvP7tcp_pcbt+0x4): multiple definition of `AsyncClient::_s_sent(void*, tcp_pcb*, unsigned short)'
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib67a/libESPAsyncTCP_ID305.a(ESPAsyncTCP.cpp.o):ESPAsyncTCP.cpp:(.text._ZN11AsyncClient7_s_sentEPvP7tcp_pcbt+0x10): first defined here
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib90f/[email protected](ESPAsyncTCP.cpp.o): In function `AsyncClient::_s_error(void*, long)':
ESPAsyncTCP.cpp:(.text._ZN11AsyncClient8_s_errorEPvl+0x4): multiple definition of `AsyncClient::_s_error(void*, long)'
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib67a/libESPAsyncTCP_ID305.a(ESPAsyncTCP.cpp.o):ESPAsyncTCP.cpp:(.text._ZN11AsyncClient8_s_errorEPvl+0xc): first defined here
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib90f/[email protected](ESPAsyncTCP.cpp.o): In function `AsyncClient::_s_poll(void*, tcp_pcb*)':
ESPAsyncTCP.cpp:(.text._ZN11AsyncClient7_s_pollEPvP7tcp_pcb+0x4): multiple definition of `AsyncClient::_s_poll(void*, tcp_pcb*)'
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib67a/libESPAsyncTCP_ID305.a(ESPAsyncTCP.cpp.o):ESPAsyncTCP.cpp:(.text._ZN11AsyncClient7_s_pollEPvP7tcp_pcb+0x10): first defined here
/data/sonoff_rfbridge_1/.pioenvs/sonoff_rfbridge_1/lib90f/[email protected](ESPAsyncTCP.cpp.o): In function `AsyncClient::AsyncClient(tcp_pcb*)':
ESPAsyncTCP.cpp:(.text._ZN11AsyncClientC2EP7tcp_pcb+0x30): multiple definition of `AsyncClient::AsyncClient(tcp_pcb*)'
...
Ok, that is this issue
Just removing the webserver fixed that, and it can be added after the first compile (where it knows it has the 1.2.0 of AsyncTCP already).
And now everything is green again on 1.13.6, so I guess 1.14 is not for me yet. Please let me know if you are on 1.14.x when it works perfectly.
Issue #816 was closed after reporting that mdns issue was gone when I moved away from a Mikrotik AP and using VLANs to a DD-WRT AP without VLAN.
To me that is hardly a real solution especially since all was fine before upgrading to ESPHome 1.14.x. 
Nothing is changed if we can not show evidence to the ESPHome team that the problem is in their framework.
Can you or anyone else who have similar issues say something about their network setup? Like router used and whether or not it is on a VLAN?
Either on this platform or re-open #816 or create a new issue linking it to #816?
Hi @DasBootU96 That is a problematic, I’ve posted a comment (it looks like I can’t reopen the case), I hope they see it.
Solved, for me at least by setting Multicast Helper: full in Mikrotiks wireless interface setting.
Manual says that option multicast-helper: full means: all multicast packet mac address are changed to unicast mac addresses prior sending them out.
Hope this helps.
I can’t set that in Fritz!Box, and it’s not a solution, it’s circumvention. It will increase traffic greatly on the net.
Having never used a Fritz!Boz before, I do see there is an option to telnet in and enable full multicast support on the whole network. Maybe it is worth to test it with v1.14.x even though you do not need it for v1.13.6 ?