BEWARE! If you're using a MicroSD, switch to a HDD NOW!

@Valentino_Stillhardt what database engine were you using on the SSD?

And was the database on a separate partition?

What does dmesg tell you about the drive?

What does smarttools tell you?

:joy:

Please read this report. SSDs can survive Petabytes of writes. Your HA instance isn’t likely to achieve that any time soon, even with your “5 pages” of entities (I have about 1K, writing to an SSD for the last 18 months, and that SSD has many other chatty things writing to it - no issues).

1 Like

I’d have a closer look at your power supply. More likely that the lack of sufficient amperage is causing this strange behaviour.

Also I don’t subscribe to the notion of locking posts or shutting down discussion purely on the basis of a post’s title. The mods will pick up on spam quite quickly.

Everyone is entitled to express their experience with HA be it good or bad

1 Like

I’m not sure these statements are consistent?

1 Like

MicroSD cards known issue, SSD nope something else at play here

1 Like

My experience with MicroSD&HA: was only using the official accessories for Rpi 3 running HA, which was then plugged into an UPS. Between 2016 and 2018 I was able to run Home Assistant without any issues whatsoever. Then, suddenly in 2018 the initial MicroSD card died and two others in a single month (I make regular backups so it wasn’t an issue of lost data but of inconvenience).

Went for entry level NUC with Celeron J4005, 8 GB or RAM and the cheapest 120 GB SSD I found at that time and (except for some stupid network configuration stuff that I do from time to time) it is perfect. By the way, I’m nearing 2,500 entities in HA, with 12 GB in SQL database so it is not idling by any means. Having general purpose addons such as MariaDB, InfluxDB or Grafana on the same machine with Home Assistant is useful.

I then use multiple Raspberry Pi 2 (probably even v 1 would have worked fine for most of these tasks) for more than 4, even 5 years, with daily usage and reboots only to install latest SO upgrades, without any MicroSD corruption issues but these are not huge on the I/O side:

  • LibreELEC;
  • MotionEye camera;
  • Phlips Hue Sync clone on Raspbian with Hyperion;
  • NUT server on Raspbian (for NUT I initially went with HA addon but found that the UPS was not recognized).

Kodi runs on hundreds of thousands, maybe even millions, of pi’s. SD card corruption doesn’t seem to be a significant problem. And they use sqlite by default.

2 Likes

I’ve setup mine with MySQL :slight_smile:

me too. Have forever :slight_smile: But there are many many kodi users with a default sqlite database on SD card running kodi, and kodi does write to the database constantly (when playing anyway). I’m not saying it is as heavy as a home assistant with a few hundred entities.

I have gone through 3 new SD cards in a little under a year :frowning: A couple of weeks ago after the last SD card died I changed to a SSD, when I started my install I experienced strange behaviour (wouldn’t connect to the LAN network etc) it turns out it was down to a poor power supply.

Regards

3 Likes

While the recommended manufacturers power supply is used by many this recommendation is based upon using an SD card for operations.

My advice to users operating their RPI with an SSD on the same power rail is to obtain a power supply with a higher rated amperage to cover the additional overhead drawn down by an SSD or consider an SSD with its own external power supply

This article might give a better insight into the powering of an SSD and possible problems that might be encountered. https://burstforum.net/topic/9533/ssd-disks-beware-of-the-amps

1 Like

The default one which ships with HA (sqlite?)

It ran on the same docker container as HA.

Didn’t try dmesg

I did a short check, SMART tells the drive is totally OK
I did a long test, disk unmounts itself after some time and that’s it. All commands fail and I need to recycle power.

That sounds like a power problem more than anything else

1 Like

It’s the original NUC power supply. Don’t think it’s a power problem. That thing can handle full blown Windows.

The entities that I use most I included, and they write a lot, but I excluded most of the other things, such as on/off states of automations, switches, etc.

But anyway, a new SSD is on the way. Maybe the new SSD will endure Petabytes of writes, but the old one that we had in there didn’t ‘seem’ to be in the mood to do this, unfortunately. Only thing that I remember right now that SandForce was written on the chip. I’m not home right now.

It’s just a little warning for users that might have older hardware or are using MicroSD’s. I wasn’t the luckiest.

that means nothing a laptop with a 35w powerr supply can run windows
I would still look at your powers supply

I could test this at a last resort, but the NUC didn’t get hot to the touch, at most warm. I will test the temps today and report back.

Well, the power supply was designed for that load. I don’t think it’s an issue there.

1 Like

I hope you did your research before choosing a suitable SSD drive. I assume you are aware that not all SSD drives function well with the RPI https://www.raspberrypi.org/forums/viewtopic.php?t=266353

Also assuming you are using a power supply delivering a steady 5w and knowing that an SSD can draw up to 1 amp you’ll need at least that above the recommended amperage to guarantee stable power to your RPI.

I really would be wary of using generic power supply units unless these units have been tested and proved to work by others.

All I can recommend here is research and research again before purchase.

I am currently talking about the NUC. I left the RPi with the MicroSD behind, since MicroSD cards were gone faster than my clothes.

I believe you just had a bad SSD… thing will broke, but unless it happen multiple time you can just judge or saying that it will happen to everyone.

Ok.

Maybe others using the RPI will benefit from that advice I gave you. Either way choose your SSD wisely. Cheapest is not always the best solution in the long term.