Okay, then an other issue.
RPI is now my only option since I’m traveling and not able/willing to buy other hardware.
Without this grazy memory usages (like 600MB in a couple of hours) it is fine.
I only have a couple of sensors and will add a few relais…
This mem usage is completely normal for HA and a more or less virgin system. This is the reason why systems with more add-ons easily start to lag on RPi 3s with 1GB of mem. It is also normal that the mem usage slowly ramps up after reboot and takes some hours to reach a stable level.
My extensively configured HA allocates approx 2GB when grooved in.
Okay, makes sense when indeed a lot of devices are connected. For me I just see a connection between 1 service homeassistent.set_location and this amount of memory.
At the first line I start the node-RED with the service. Within a couple of hours there is almost a GB used for only this service. (have to mention it gets updated every minute).
Second line is node-RED flow deactivated and HA (in docker) restarted.
Then it gets stable.
Yes, but memory account ramps up also with add-ons. You have Node RED installed, which is definitely not lightweight. Have you checked you HA Logbook for many entity changes coming in? Anyway, I don’t think this is the place to discuss HA’s memory consumption. It has nothing to do with setting up RPi 4B and SSD boot.
On you configuration. What firmware version on the StarTech controller? I believe ending in 02 is the latest. Also are you using the top or bottom usb3 port?
Still trying to see what is different.
Thanks
@Jpsy,
Used the latest firmware on the StarTech 3.1 controller and tried the OS 5.12 again. Locked in 4 hours. No errors in any of the logs. Still have yet to see a failure on 5.4.
This IS a veritable conundrum. I read through your issue report where Agners tried to provide a debugging version. A pity that he did not succeed. I hope that this strange behavior will finally reveal it’s hidden logic and it all will lead to a better OS.
His debug version would not boot off of the SSD. I wish I was the only one, but it looks like more and more people are opening GitHub issues. Most of the people there have use Home Assistant for a while and understand what they are doing. It does not look like the inexperienced “operator error”. It looks like there is an issue somewhere with the OS. As you are aware there were major changes to the OS for the Pi after 5.4. I hope the answer isn’t they will stop supporting Home Assistant on the RPI4.
I also tried the method that is “support” and installed on an SD and move all but the boot to the SSD. This failed also after 3 to 4 hours. No difference than just using the SSD.
Thanks for trying! If I see something useful, I will post it here so you can attach it to your directions.
Bill
Does it even make a difference if you run the full system from SD only? If this fails too it would rule SSD out of the equation completely.
I was running successfully with the Sd up to version 5.8 (32 bit). I went to 64 bit when I went to SSD. I was told by @agners that the new versions of the OS supported 32 bit booting of the ssd. I have tried several and could never get this to work. I tried the recommended supported split version (sd boot/ ssd for everything else) and this failed after several hours with the 64 bit OS. My next test will be trying the split again with the 32 bit version of the os. I was hoping to try the 32 bit ssd first as once you go to ssd it is hard to go back to sd.
So in theory this could be a problem with 64 bit and possibly it is not related to SSD. Maybe you could take the time and try 64 SD only to see if it stalls too. This would considerably narrow down the possible sources of the problem.
That was one of the first questions I asked in Nov (which never got answered). I thought that as your 8G version worked where my 4G didn’t and my 32bit SD worked that the 64 bit could be the issue. Remembering how when windows first went from 32 bit to 64 and how some programs had issues, this could be a similar issue with how memory addressing was done. I believe that using the split version SD /SSD tests the pi with 64 bit (which failed), but I am not certain?
Each test with the SD is slow to setup. The split version takes about an hour (boot, restore, move). The SD setup is a little faster as there is no partition move. The test takes around 3 hours to a few days (when it freezes) so I would like to have some feedback from the developers on what to try and what to capture that will help resolve the issue.
I believe that there are enough people with this issue to do a controlled experiment to figure out a solution. We just need what to test that would help the developers determine the root cause so it can be corrected.
I am already for several days running HA in VM, it’s super fast, super reliable and hasn’t freezed yet. I put fresh HA on the RPi to control my projector only, which I control using HACS remote control (control slave HAss with master HA) and it works like a charm. My freezing is definitely related to expanding HA regardless of booting from SD or SSD, or running 32/64bit version. It’s the capability of RPi to handle continuous tasks.
I have not got that far.
First I bought an usb3-ssd that didn’t work at all.
Then I got an InaTech that was recomended… But it was the wrong on. This one needed a push on a button to work. So I ended up with This one and the pi’s boots like a charm.
I don’t know but I flashed the ssd directly and at least it boots. It seems that it starts everything.
I have not had the time to do more. This shall replace my old PI3.
Whenever I get the time… And see what files I have to copy to the new one.
That would deny the fact that me and many others are running really complex HA installations on Pis without any hangs or freezes for weeks. Mine never ever froze or stalled and I have it running everything from KNX, Zigbee and enOcean to MQTT and Node RED with dozens of flows to ESPhome, Glances, InfluxDB and Grafana. It transcodes video streams of 5 network cameras too and stores them on motion events. And it never complained the tiniest bit.
Please understand that your simple size of 1 is much to small for raising a big statement like that.
Maybe the main problem is my three automations that use a trigger based on one second pattern. However, this is my experience and I spent dozens of hours to solve it. VM on my personal computer solves it, it reboots superfast, the webserver is significantly more responsive, so I even do not see a reason to tinker on slow RPi when I can get intel NUC dedicated for HA. If I can spend so much money on all the gadgets, why not have a serious metal to run them.
Sorry for a big statement, but look:
Btw finally when I was running both instances, I realized, that the freezed RPi (disconnected, no ssh, no ping over lan) still sends commands to netatmo, so it is apparently not freezed completely.
The only and extremely quick solution was to put it to VM on my desktop computer. Everything is superfast, more responsive, stable, reliable and all the bugs, delays, freezes I experienced are gone. HW test by RPidoctor does not return any troubles.
Fresh install of HA on RPi that only sends shell commands to my projector (and is controlled by hacs hass remote control) makes the RPi stable. So I am fine with buying NUC for HA. It will work.
I guess you simply saturated the Pi with whatever your automations do.
Sure you can throw hardware on that kind of problem. You will succeed and doing that will always be the cheapest solution if your time is worth money.
All I want to say is that what you experience is not a general Pi problem. A Pi 4 is absolutely capable of handling the load of even a quite extensive HA installation.
As I said before the downside of more powerful hardware is its carbon footprint. A HA system will typically run 24/7. Your NUC will easily consume 5 to 10 W more than a Pi doing the same thing. Over a year this sums up to 40 to 90 kWh or an equivalent of 20 to 100 kg of CO2 (depending on the carbon based fraction of power generation in your country). So the difference between RPi and NUC is not only more ooomps but also up to 50 m3 of additional CO2 per year.
IMHO this is far too much for an unspecific “RPi is to weak for HA”.
The freezing problem.
I see many other people around in other threads with the same problem maybe caused by different errors. What we share is the fact that there is no debug method to cut down possible causes and find the one causing the freeze. There was a memory allocation problem in version 4.9 or 4.8 during which I firstly experienced the freeze. The developers of the HA Core fixed this and said there is no other bug to be fixed. Again, problem is that I do not have means to submit an extensive log. I can, of course, continue with looking for the cause but…
The wife problem
I cannot run my home toys on an unstable system because then my wife cannot switch on a simple light. That’s a problem beside all the HA complexity - the simply happy wife makes your life good.
Carbon problem
I plan to control my solar power plant with HA, manage flow of energy between PV, earth heat pump, heat reservoir for storing excessive heat in hundreds of C (oil) for usage in winter and heating/cooling the house. I plan to cool down my PV during summer to assist the heat pump (and store the excessive heat), so to control the temperature of the whole system on various levels, to control all valves for heating and cooling and other ideas. My first intention a year ago why I decided to understand HA was to make my life as sustainable as possible and mainly to control the energy. In this regard, I need stability, reliability and the difference of carbon footprint between RPi and NUC is negligible in relation to what I plan to achieve with my living.
