EmonPi crashes regularly

Old thread, but I have experienced this twice past month. I have been using emoncms on an RPI3b+ without any issues whatsoever from January to November 2019. I think it has been rebooted once, maybe. Then I swithced to a new Emonpi (bought in 2019). After about one or two weeks something suddenly crashed during the night, making it impossible to log into it (some overflow error appeared). I rebooted it by using the button on the emonpi to shut it down, then cycle power and everything looked good when it rebooted. Now, one week and a few hours after the first incident, it happened again yesterday morning. Same procedure with shutdown/reboot/power cycle and now ok.

During the problem period, data becomes garbled. The CT data are restored, since they are logged using Iotawatt, which will hold the data and fill up the emoncms db once up and running again. But - the calculated data becomes garbled for the period between the crash and reboot. For example. power calculations become very high and this obviously disturbs the statistics.

My primary concern is however that the entire setup is unstable. I am away in periods, and cannot rely on physically be there to recycle power every 7 days…

Is there any way to track down the root cause (I am a real newbie to linux/RPI)? Is this error known?

low-write 10.1.13
Administration | App v2.0.9 | Backup v2.1.7 | EmonHub Config v2.0.4 | Dashboard v2.0.5 | Device v2.0.3 | EventProcesses | Feed | Graph v2.0.6 | Input | Postprocess v2.1.2 | CoreProcess | Schedule | Network Setup v1.0.0 | sync | Time | User | Visualisation | WiFi v2.0.2
* stable
Linux 4.14.71-v7+
emonpi | emonpi | (xx.xx.xx.xx)
2019-12-02 09:30:40 CET
09:30:40 up 14:54, 1 user, load average: 0.35, 0.17, 0.12
#### HTTP
Apache/2.4.25 (Raspbian) HTTP/1.1 CGI/1.1 80
#### MYSQL
localhost:6379 (
2019-12-02 09:30:40 (UTC 01:00‌​)
Uptime: 53746 Threads: 2 Questions: 55840 Slow queries: 0 Opens: 27 Flush tables: 1 Open tables: 21 Queries per second avg: 1.038
#### REDIS
Redis Server
PHP Redis
427 keys (824.08K)Flush
0 days

#### PI


Raspberry Pi 3 Model B+ Rev 1.3 - 1GB (Sony UK)


Serial num.



51.54°C - 51.5°C





There have been odd reports of this - there was an issue with the logs filling up, but that should be fixed.

The best way to move forward, I suggest, is to upgrade the system to the latest EmonSD image (export and import your data) - that then removes any possibility of it being an problem with historic SW issues.

I’d also start with a new SD Card so that; a) you have a roll back position, and b) removes any possibility the card is failing (though I doubt that).

Thanks, will do that. I would like to increase the SD card size at the same time. Would a 32GB card be ok?

Yes should be. I would say though, that volume of data is pretty slow to backup, so you might want to consider a system using something with more reliable storage such as an SSD.

Ok, then I wonder - would an USB connected SSD be faster and/or more reliable as a permanent data storage device? Maybe even recommended?

It really depends on how much data you actually have, and how important it is.

EmonCMS is really efficient in terms of data storage, a 16GB card has about 10GB of data storage. If you think that is not enough, you may need to look at alternatives. If you check, I anticipate your data storage is less than you expect.

Yeah, I know. Right now I have spent about 1.6% of the 10GB, and with the current write rate, it will take years to fill it. But I already ordered a 32GB card (easily available, fast and quite cheap), and so I will be using that.

1 Like

If an SSD were connected via USB3, it would be faster than a µSD card.

More reliable? Without a doubt, yes. The larger capacity of a SSD means the wear leveling
“mechanism” can spread the “wear” over a much greater amount of flash memory.
In a nutshell, it’s one of the reasons SSDs have lifetimes measured in Terabytes written (TBW).
Yes., that’s Terabytes, as in 1012 bytes. Not likely to get that type of performance
from an SD card. Here’s a couple of scenario examples:

A typical TBW figure for a 250 GB SSD lies between 60 and 150 terabytes written. That means: To get over a guaranteed TBW of 70, a user would have to write 190(!) GB daily over a period of one year (In other words, to fill two thirds of the SSD with new data every day).

A normal office user writes approximately between 10 and 35 GB on a normal day. Even if one raises this amount up to 40 GB, it means that they could write (and only write) more than almost 5 years until they reach the 70 TBW limit.


Recommended? Yes, definitely!

1 Like

Good to know. I was slightly unsure if this was true or not. Writing would be no problem - it would be reading large amounts I wondered about (for graphing etc.).


I should have been a bit more specific. i.e. a drive connected via USB 3.1 will be faster.
But delving into it a little deeper shows that it’s not by much. i.e. some of today’s media can hit
fairly high speeds, and it looks like that may change. Here’s some more info:

From the article at the link below:
SD Express , a joint effort with PCI-SIG to create SD cards that are compatible with PCIe 3.0/NVMe v1.3 protocols and will offer peak theoretical speeds of 985MB/s.

As with most speed tests, coming up with a definitive answer isn’t easy.

1 Like