Devices becoming randomly unavailable in Home Assistant

Hello everyone, I’m having some issue with my wifi decices becoming randomly unavailable as then available.

My setup:

  • I have Local Tuya setup. I removed cloud Tuya a while ago.
    -I have home assistant running on RPI4 and SDD. I keep all my system updated. On core_2022.2.5 now.
    -I have 3 dashboard around the house, one on old iPad and two on amazon kindle 5.
  • I also 4 z-wave (Smarthings hub)
  • 30 zigbee devices (Conbee II and dDeconz) and
  • 72 on wifi decices (tPlink Archer AX 20).
  • I have reserved IP for all the IoT decices, lighta, switches and cameras.

I can’t be exactly sure but I think the issue started just before core_2021.12.7.

I can see on my HA panel, the devices going offline, and then after minutes coming back online, randomly. Not all at the same time though. It seems like it happens with Tuya and Kasa based devices and Kasa.

I read that perhaps it has to do with the number of wifi devices on the router. I am wondering if anyone you have experienced similar issues and how you resolved it.

Thank you in advance.

I have the same, drives you nuts right :slight_smile:

I don’t trust some automations at this point which is very irritating. You can handle it better with node red to check if they are available or not and make it more reliable.

Local tuya works better than the cloud one, I setup both again to double check.

Have been messing arround with the wifi 2.4Ghz channel, check your router for the signal strenght, it seems that its quite related to the poor performance of it. (says more about the plugs then your router probably as other devices seem to have no issues)

@galletn , exactly. I cannot rely on the automation because of it. I use node red as well and I love it. I’ll try out what you suggested. Thank you for reading my long winded explanation and advising.

It maybe a bad news but I added Tuya cloud integration and it seems to be stable. This means something wrong with the Local Tuya or my setup with Local Tuya was faulty. :frowning:

A bit disheartened with Local Tuya. I had some devices going offline before, but I’d be able to fix it by removing and adding device, but this time I was all devices randomly becoming unavailable.

Oh well, at least my automations are back stable again. :slight_smile:

1 Like

Hi!! I have the same problem with Local Tuya and something caught my eye: Do you have a router that delivers 2.4G and 5G separately? Or is one of this new routers that gives you both 2.4/5G in one single wifi address?

Hi All,
Just had the same issue.
My router died and when I installed the new one, all IPs were assigned by DHCP.
In the previous router I had an IP reservation table so all entries had a persistent IP.
After installation, almost everything restarted except the one that measures the current to my fridge.
It remained stubbornly unavailable through core restarts, reboots etc.

So here is the section in the config_entryxxx.json that I think was causing it:

  "data": {
    "config": {
      "entry_id": "84835d5789d6afa9d2af7b16665d4442",
      "version": 1,
      "domain": "esphome",
      "title": "fridgefuse",
      "data": {
        "host": "10.10.0.111",
        "port": 6053,
        "password": "**REDACTED**",
        "noise_psk": ""
      },

The IP was from the previous router and was not being updated. The IP was valid in the new router, but would have been returning an error.
So my guess is (IP+error) → no IP update → (IP+error)

Any thoughts?

BTW, the text file with the config information is accessed:

Settings>Devices&Services>(ESPHome devicename)>"1 device">"Device info"(three dots)>"Download diagnostics"

Can you explain where you were going with this logic? What’s the difference in usage between a router with one or two wifi addresses?

1 Like

Having the same SSID for 2.5 and 5 GHz can throw a 2.5 GHz device like a Tuya switch.
I believe it’s because the device incorrectly picks the 5ghz network to comms on, which it can’t.
Something like that, anyway.
I’ve divided my home into two separately named nets, in an attempt to stop dropout from some Mitsubishi aircon units. I think it’s made things better, but not totally - I have a new Tuya wifi switch which drops out regularly.

I’ve had nothing but issues with a Tuya C02W controller recently.

I have 2 of them, in the same room (bedroom), and they both connect to a 2.4 AP ‘_IOT’ SSID. They show up in the DHCP. They show up in HA. But one of them is unavailable.

It is working fine from the Smart Life app, just not in HA. I’ll have to turn on logging and dig deeper…but something has gone AWOL in that device’s WiFi connection…in order to get it to connect to the ‘_IOT’ SSID, I had to set up a hotspot on the computer with the same name and password, connect it to that, and then shut that HS down and reconnect it to the main AP. It refuses to connect to any of the other SSIDs I have via the Smart Life app…just times out.

(and it was all previously working fine until I had a power outage and the router rebooted)

1 Like

Despite what salespeople tell you, WI-FI IS NOT MAGIC. Just because we cannot see it, does not make it magic with unlimited range, speed and number of connected devices.

Router specs are deliberately misleading about the number of devices which can connect simultaneously, letting you assume that all the connections can be via wi-fi. That is called “marketing”.

In fact the router internally has several tables to keep track of what is going on. 20 years back residential routers might support only 15 active wi-fi connections, and commercial models double that number. Newer models have more memory, and so bigger tables - but there is still a limit - and when a new device asks to join the network usually the router drops off the connection which has been unused longest, and uses that slot for the new device.

The best fix is to connect as many devices as feasible using ethernet cabling. Ethernet is faster, much more secure, much more stable, and will even speed up your wi-fi #1. Leave wi-fi for portable devices and locations where it just isn’t feasible to run a cable. You may find little 4- or 8-port switches to be really useful where several devices are located nearby (eg TV, Media player and Xbox are all located in one spot).

The simple fix is to get an additional Wireless Access Point (WAP) - or another wi-fi router and not use the routing functions - and position them both so that about half of the devices will get better reception from the new WAP. Note:

  1. IoT devices all still use 2.4GHz, so a second-hand wi-fi router which only does 2.4GHz is a viable option for smart home devices.
  2. The WAPs should be connected back to your main router with ethernet cable, for reasons mentioned above. If not, your WAP is acting as a repeater - ie the WAP has to receive each data packet, the re-transmit it - thus halving your wifi speed through the repeater.
  3. Both WAPs should use the same SSID (network name) but different radio channels.
  4. You and all your neighbours are sharing the same 11 (or in some countries 13) radio channels. Encryption is automatically applied so you don’t see their data packets and they (hopefully) aren’t reading yours - but (like regular AM radio or CB radio) if two devices transmit at the same time on the same frequency the result is totally garbled and both devices have to re-transmit … resulting in your network seeming to run slow.
  5. When the salesperson tells you that buying their fancy new router will fix all your problems, look closely at their eyes to see the dollar signs.

#1 - indirectly, by reducing the number of devices which are trying to share the radio channel.

Hi Andrew

I’ve been having the same issues with my Tuya based WiFi underfloor heating thermostat/controllers since I integrated them in HA. What I’ve been able to troubleshoot so far is:

It’s not a Wi-Fi issue in my case. I have a NEMS/Nagios monitoring server and continuously monitor all IP based endpoints on my network and various open TCP/UDP ports on devices. The Tuya thermostats are reliably responding to ICMP/ping (I still need to check the open port status over time). I have other smart devices that go through bouts of long ping response times and this has been down to those devices doing other stuff (updates, sending out MQTT, sleeping etc). All my devices are set to DHCP reservations so they are not changing IP. As far as I can see, they are not being confused by 5G and dropping off the 2G band and they are not moving to other satellites in my mesh that could account for potential issues, although I’d expect to see this in long ping response times.

Likewise it’s not likely to be another router or Internet issue - I have various scripts on NEMS for checking both router and internet performance. I can see when things go slow relatively speaking and this does not coincide with when the Tuya thermostats show up as not responding in HA.

Although I’m using Local Tuya in HA, I’m not sure yet how often the devices interact with Tuya cloud API and if this plays a part in the issue.

What I have found is on the iPhone app, when I set a thermostat to manual and immediately back to auto, this has sometimes triggered the thermostat to show up in HA, only to revert back to not responding over time. This is not a consistent fix though.

What I have consistently seen is when the thermostats become unavailable, then powering them off at the isolator switch and back on (not using the button on the device as that doesn’t kill the power and just puts them to sleep), waiting for them to boot up, then refreshing HA dashboard brings them back as far as HA is concerned.

They were showing up fine over night, I then did a HA update this morning and once HA booted up, the Tuya were unavailable. Locally they were working fine but once I powered each off and back on and they came back in HA.

So this leads me to think the issue is the HA integration with Tuya, or Tuya cloud and some session timeout or refresh issue. I might try and raise with Tuya but I won’t hold my breath.

I have seen other HA integrations present unavailable status for their respective devices and these clear up over time when HA does a session refresh. These issues seem to be improving as updates are rolled out. So maybe it’s a case of waiting for Tuya or the HA integration developer to figure out where the reliability issue is and fix it.