HassIO Keeps Going Offline

I seem to be having a similar issue.

  • Rpi3 was connected to wifi
  • Rpi3 shows power and activity LEDs still going
  • Rpi not found by router anymore, tried rebooting router (hey why not)
  • frontend, samba, ssh, mpd, etc… all unreachable now
  • Occurs approx every 24-48 hrs
  • requires hard reboot to recover
  • Z-Wave sensors still trigger automations
  • Highly unlikely that it’s a power issue (I got PO’d at the brown-outs during setup so it’s running off a PSU capable of 5V @ 21A).

On a whim I also blew a bunch of cold air across both sides of the pi, it did not come back up.

Anyone have a way to 1) see some type of persistent log, 2) see cpu/mem use ? Curious whether this is only on Rpi3 or other hardware as well.

As neat as Hass.io is I feel we’re lacking some of these debugging options that are typically useful (or they’re hard to find). I like that maintenance and configuration is simpler (so I’m told, just got on to this in the past month), but I’m starting to wonder if I wouldn’t rather trade that for reliability.

I had the same issue and spent a few weeks troubleshooting it.

Your RPi wi-fi chip is busted. Switch to ethernet connection and Hassio will behave normally.

I’m doing an informal poll related to this issue. Did you purchase your RPi as part of a Vilros kit?

Have never used Wifi on RPi and still had the issue. I got rid of a bunch of services and things I didn’t need and the problem disappeared. I think its related to certain services, but can’t prove that.

Neither of you two got further with logging/mem usage? Did nothing come of the memory issue comments above?

I have nmap_tracker and zwave set up, it was happening with just those.

Recently moved and haven’t had a chance to run ethernet, this will be the longer-term goal. For now I’m just getting started and feeling the waters but would very much like it to be working reasonably reliably.

At this point I’ve got half a mind to set up a Pi2 with nmap_tracker and point it at this one to see how long it’s up for each time. I might also stick a scope on the power pin to see if there are still local brownouts, I know my supply has plenty of current capacity, but the line regulation might not be great for fast switching loads, worth a shot?
Unfortunately it seems they left U19 (which is the chip that appears to be connected to the antenna) off the schematics, so we won’t be getting many clues from there. I did see some Rpi forums talk about catching catching an undervoltage condition and displaying it to the screen, might be worth seeing if it’s something that can be incorporated into the logs?

I got it via Digi-key.ca, and use a separate power supply.

Hello, I have the exact same issue
Basically, raspberry doesn’t respond anymore (front, ssh, ping), leds are on, z-wave sensor keeps running in background…
I also have an official power supply with enough A and use wifi

Did you solve the issue or have a better understanding of it ?

Thanks in advance

Seems to be a software or hardware issue with the wi-fi onboard the Pi. Since switching to an Ethernet connection, I have not had the issues.

I do not have a better understanding, I haven’t had that issue since switching to an ethernet connection.
I would still like a resolution to the problem, so please share if you find anything further.

Switched to ethernet and disabled wifi.
I will report in a few days if everything is now working fine.

I’ve noticed that myself recently. I thought it was because I had a version of Ser2Sock installed and tried disabling it. Still having the issue randomly. I notice the first symptom is I can’t easily access the addon tab on the front end. Its really only been a problem recently. Maybe an issue with an update?

Have the same issue as well (running 0.65.5, wifi, raspberry pi 3b). Disconnects seemingly random once or twice every week.

Used to occured quite frequently (every night) on a previous build of hass.io (perhaps around 0.60) a few months ago, but then the problem went away after an upgrade. Everything was rock solid for about two months, and then started appearing again one or two weeks ago (after upgrading to 0.65 - don’t know if it’s related though, might just be coincidental).

Is there anyway to get any logs to try to find the cause here? Seems to be an issue to quite a few people, would be very good to know if it’s hardware of software related.

8 days later and no crash since
Switching to ethernet solved it for me

1 Like

I have the same issues, this started when I installed the bluetooth driver and setup the device tracker, this was fine on the hassbian version. Im not technical but it seems the bluetooth is conflicting with the wifi.
However Ive uninstalled the bluetooth now and it has remained stable on the wifi connection for days now.

hi guys, sorry to be late into the party. my solution is

  1. ensure wifi power management is off
  2. a cronjob to ensure wifi availability

hence step 1 would be

  • go to /home/pi
  • vi wifiscript.sh
  • insert these, see below
    #!/bin/sh
    iwconfig wlan0 power off
  • save the script and change the permission by , chmod 777 wifiscript.sh
  • test run this script by ./iwifiscript.sh and check iwconfig if the wifi power is now off
    ** if it isn’t, vi into wifiscript.sh and change /bin/sh to /bin/bash
  • vi /lib/systemd/system/myscript.service
  • insert these, see below
    [Unit]
    Description=My Script Service
    After=multi-user.target
    [Service]
    Type=idle
    ExecStart=/home/pi/wifiscript.sh
    [Install]
    WantedBy=multi-user.target
  • save the file, and chmod to 777 for myscript.service
  • run command systemctl daemon-reload
  • run command systemctl enable myscript.service
  • run command reboot

now whenever your pi boot, management wifi power is off, this will keep your wifi always ON state.

step 2 is for people who’s pi still keep going down so you need a cron to do a check and load

  • go to /home/pi

  • vi restart_wifi.sh

  • add these.
    #!/bin/sh
    WifiPing=’/bin/ping -c 5 google.com |grep -i icmp | wc -l
    if [[ $WifiPing -le 4 ]]; then
    ifdown wlan0
    sleep 5
    ifup wlan0
    fi

  • save it and now use command, chmod 777 restart_wifi.sh

  • now add this script into crontab with command, crontab -e

  • insert below and save
    */5 * * * * /home/pi/restart_wifi.sh >/dev/null 2>&1

end of tutorial

so what above does is to set a timer for every 5mins to check if internet is reachable, if at anytime google.com is not reachable, it will assume wifi interface is down, therefore stop the wifi interface and start again.

these 2 script should enable you to have long wifi connection even if it was some stupid hardware problem. remember, hardware issue is never an issue for any software guys! we write bypass because we are smarter than computers!

Nice but won’t work with Hassio

could you explain why it won’t work with hassio? this work for any *nix system. i didn’t verify the shell script though as it was written on the fly for anyone. there maybe some syntax error but easily replaceable if found.

Hassio is not *nix it is ResinOS

hassio run on top of linux kernel, it run bash and run shell. my solution will work.

i have almost gotten a heartattack because i tested part 1 works for me a few weeks ago.

https://docs.resin.io/reference/resinOS/overview/2.x/

There is no such thing as /home/pi
It’s all docker containers and anything you put in is reset when you reboot.
It won’t work.
Try installing Hassio and trying it. It WON’T work!

it’s not via http, please login via ssh with cli. suggest you use putty.

Suggest you try it. I doesn’t work.