My RPi3B+ with Hassio lose wifi connection every day

Hi everyone, on my RPi3B+ with the latest production version of Hass.io, I noticed that about 1-2 times a day does not respond to any connection attempt, of type https, Samba, SSH or other, the card it is no longer connected to the router and, if I connect an HDMI monitor, I can only see these lines that run endlessly, until I cut the power to my RPi (praying for the safety of my SD card):

brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110

What can I do?
I mean, when RPi restarts everything works normally, but it happens randomly and if I think it’s working maybe it’s not. This is a big problem because it reduces confidence in this system. :thinking:

Thanks in advances for the replies.

Why are you not using a RJ45 cable ?

Yup, agree, trusting my entire home automation (& life it feels like at this point, lol) to a WiFi connection would not be something I would entertain…

2 Likes

Because it’s working location is mobile. If I want to move my RPi, the only need is a near power plug on a wall. Having another cable to manage is fastidious for me. :slight_smile:

Yes… it is the exact point. I searched a bit on google and seems is a hardware bug of RPi or a combination of hardware and kernel issue… not real solutions yet, and for me, semi-new on Linux, this problem is pratically hard to solve for myself.

No solutions?

As you correctly state, it appears to be a bug with the actual RPi hardware, or the WiFi driver (or a combination of). I have a RPi3B+ that is also showing the same issue - started about a couple of months ago - this RPi is monitoring a weather station and does not have Hass.io installed on it - it has nothing to do with my Home Assistant set up, which is running on other hardware.

I initially thought that it was my SD card starting to fail (3yrs old now), as the system just appears to hang and sometimes the only way to recover is to power cycle (and keep fingers crossed). The majority of times when it fails, it recovers after 5-10 mins (I’m using HA to monitor it now, and alert me when it goes offline, so I know when it happens). Having looked at the syslog I now realise that it is the WiFi card that has the issue.

I can think of a couple of options…

  1. Use an RJ45 cable - not always convenient I know, and I would have to connect it into a PowerLine socket, as that would be the only way to get a physical network cable connected, as I don’t have any switch ports nearby.

  2. Use a 3rd party USB WiFi dongle instead of the on-board WiFi. I haven’t investigated how practical this will be, and if there are the appropriate drivers available. Also you would need to check that this USB dongle will be supported by Hass.io.

  3. I am going to upgrade my RPi to the latest OS release and see if there is a new driver in that build that fixes the issue.

Ian

1 Like

Thank you for the reply… I have found someone that check, in Hassio with an automation that use a command line (I don’t remember well, maybe a .sh script), if wifi is working every x seconds… then when not working it reboot automatically the RPi. But I lost the link and not finded again, and I haven’t many kowhow to make this procedure…

I have found in this forum this procedure:

  • Create a Shell Script:
    In the Terminal add-on or in a SSH terminal from another PC, go in /config dir:
    cd config
    in the /config directory I made a file call checkping.sh with
    nano checkping.sh
    The file looks like this:
#! /bin/bash

ping -w 5 8.8.8.8 > /dev/null 2>&1
if [ $? -eq 0 ]; then
    echo "Success"
else
    echo "Fail"
fi

For save this, use CTRL+X then confirm with Y and press Return.
The script pings google five times and reports after its done. After you have that done you have to make it executable with:

chmod +x checkping.sh

Finally, modify your path to add the directory where your script is located (/config under /root in Hass.io):

export PATH=$PATH:/root/config/

To test it, you can run from any directory:

sh checkping.sh

it should return “Success” or “Fail”.

  • Create a Sensor in configuration.yaml:
binary_sensor:
  platform: command_line
  scan_interval: 30
  name: WAN
  command: "/root/config/checkping.sh"
  payload_on: "Success"
  payload_off: "Fail"

I used the scan_interval in my setup but I am not sure if it is doing anything.

  • Create an Automation in configuration.yaml
automation:
  - alias: Reboot when internet goes down
  trigger:
    platform: state
    entity_id: sensor.wan
    to: 'off’
  action:
    - service: hassio.host_reboot
    # A notice on telegram:
    - service: notify.telegram
      data:
        title: '*Server Offline*'
        message: Home Assistant is offline, rebooting...

Well… I did all this things, yesterday night, I left my RPi on, and today I tried to connect to Home Assistant: not working! I connected an HDMI monitor to it and, again, it showed an infinity scroolling loop text with:

brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110

So, not solved with automation… I think that there would be a check from system, running in background, not in Home Assistant, that reboot if obtain this specific error… I read like cron service… but I don’t know how, because cron is not installed on Hass.io.

Any possible idea?

2 Likes

Dunno about your script, but the telegram notification will never be sent since

  1. You telegram message is after the service to invoke the reboot, the next service will not have a chance to be fired
  2. If the internet connection is down, how will be the telegram message event be sent

You are right! But it not reboot at all! :slight_smile:

I am guessing that the since the initial state is off, it is going into unending reboot loop. Can you change your automation to below. This would likely ensure that the reboot is triggered only when the state goes from on to off

  trigger:
    platform: state
    entity_id: sensor.wan
    from: 'on'
    to: 'off’

This is a good observation. Tonight I will also try the two actions exchanged as I wrote them before (but it wasn’t my code) … but I’m sure the RPI will crash before this automation can happen. However I can say that my RPi does not work continuously for 24 hours … and this affects all my projects of using Home Assistant with Rpi for home automation.

What do you think if in Hassio there was a kind of register in which the triggered automations are written and so, if the system go in crash, can be resumed even after a reboot?
And then, above all, some program that checks that the system does not go into infinite loops …or if it going in loop, then auto-reboot itself. I am not a programmer, but I think they are all things that can be thought and coded. Let me know.

Hi!
I have the same problem.
Did the automation work after you added ”from: on”?

I apologize for the delay with which I respond. I made the indicated changes and tested the system … it didn’t work. The reason is simple: if RPi crashes it does not execute any Home Assistant command, but its Linux core is still working. So the automations have no meaning and you should have some program that checks outside the Home Assistant that the wi-fi connection is still active and possibly intervenes for a restart. I tried the other solution, that is to connect the Ethernet cable rather than using the wifi, and obviously the connection no longer dropped. This is my experience, common to many, but very few talk about it and no solution yet. I wouldn’t want to switch to RPi4 and have the same hardware problem. Let me know of any similar experiences or partial or total solutions. :slight_smile:

Me to switched to ethernet and since then I had no problem.

Couple of thoughts.

  • check to see if the channel for wifi you are using is a busy one in your neighborhood. Change it if so.
  • might be a power management issue with the wifi chip. I’d assume that it would be disabled by default but worth checking. Not sure how to do that but a quick google will likely reveal the commands.

How is it a problem with HA though? The rPi3B+ is notorious for having flakey Wifi/BT radios.

The rPi4 is MUCH better when it comes to the wireless radios, but for something that literally runs my home, there is no way I would ever trust it to run on WiFi.

If you want something that is going to run HA flawlessly on WiFi, look at purchasing an old laptop. With that you get WiFi built-in and a battery backup should the power go out. I’ve seen people running HA on laptops that were 10+ years old with zero issues.

No problem with Home Assistant, I just commented on some answers and my previous post that spoke of some attempts to solve this situation within Home Assistant with some automation activities. :slight_smile:
You bring me good news (real, not reviews) about RPi4’s behavior with wifi.
The laptop solution is a good idea, but so I have lost the key feature of having a mobile microsystem that can be moved from one room to another if I wish. Not forgetting the total dimensions if it is a static sensory solution with an RPi3B +.

1 Like

Laptops are mobile, BUT… just out of curiosity, if you are running HA on a Pi (or laptop or something like that), why would you need to move it? I don’t see any use case that would require that (aside from maybe pairing stubborn z-wave/zigbee devices).