You are right! But it not reboot at all!
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.
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.
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 +.
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).
If you build an environmental sensor you want to build a mobile system, then move it and measure the conditions in a room or under the porch (until I build others to use them fixed in a network of sensors). If you have to show it to your students in class, you want something compact and mobile and different from the usual laptop. If you want to take it with you then you don’t carry 5kg of stuff, not to mention the size. There are many reasons why you want to use something small as hardware … otherwise I wouldn’t buy an RPi
Ok, I think I understand. So, you are adding sensors to your rPI running HA for educational purposes? That makes sense. I wasn’t sure why anyone would want a portable home controller. LOL
Thanks for the explanation.
Two in one… educational and personal solution… the latter is the principal.
Just wanted to add that as of today, I am seeing the same errors on my RPi4 with 4GB RAM model B.
With an Rpi4? Strange… have you find any other with same behavior?
I have only really been running HA OS on the RPi 4. Though when I installed there was no specific RPi 4 image, so as was recommended on the download page at the time, I installed a RPi 3 image.
I readed that this issue is not OS related, but it happen when the wifi is on for a long time… I have found in my case that it didn’t works at the change of day… 00:00 around…(+/- 30 minutes)… and is correlated with Rpi3B+ hardware… very strange…
oh, sure… i realized now that this problem is even related to the Linux kernel (readed somewhere), so if you have used the RPi3 OS image you have took the kernel with this issue in your system too. Of course all is a bit strange. I repeat myself.
This might also be a solution:
Thank you very much for this valuable contribution @solarjoe. At the moment I have reinstalled everything (for data corruption after update) and I have no longer configured the wifi for my Rpi3B+, I’m going on wired network. But sooner or later I’ll re-insert it (I’m a little busy in this period) and I’ll use these parameters you linked … fundamental will be “connection.autoconnect-retries: 0”. If, in the meantime, anyone wants to experiment and would like to share their experience, I will be the first to be grateful.
Thank you again!