I experienced the very same thuesday last week at 9.04 o´clock. All of a sudden, my Rpi3 was just frozen, and no logging either, (as far as I could find). I pulled the plug and turn it on again. It have been running since 24/7.
Before this freeze, my Rpi had been running for quite some months, though with several reboots done by me without freezing a single time.
Perhaps it has to do with the SD card. I´m working on this part to get everything to run from an SSD insted. Just need to figure out how
I have seen it on this forum quite some time that SD cards die very often. It’s because openHab generates so much logfile and other files that it reduces the lifespan of flash devices? Because I haven’t experienced such an issue with just Kodi or other programs running on Raspberry.
If this is the issue, yes I think HDD is the best way to use…
Yes and no, In the great scope of things the logs and persistence are not much data (in volume) but the writes are made in the same locations on the card, especially with a persistence service like mapdb, that write a new value for every change (depending on configuration)
The main culprit is the unplugging or turning off of the pi.
It would be best to do this:
So that the pi detects the request to turn off and then do it safely rather than just pull the plug. This little hack can add a lot of life to your sd card.
But I would still recommend going the HDD way, with the switch hack too…
I know. just have to figure out how. Setting Rpi3 to boot from SSD seems like raher easy task. Getting my Openhab (SD card data) to the SSD is the part I need to figure out.
However if the SD card is already corrupted, making a whole image from the SD card will copy the corrupted blocks also, not?
I will look into later what is the best idea to solve this.
Anyway it seems that I need to seperate openHab from everything else. What do you use as a server for openHab? Raspberry, Barebone PC or anything else? Which is the most convinient way to use?
The way an SD card works is when you write something, it finds a block with some free space. Then it copies everything already in that block plus your new data to a whole new physical block. This is why pulling the plug can corrupt your SD card because if it happens to be writing something when power is lost, you lose not only the file that was being written, but also all the parts of files that were in that block already.
And given this data, it isn’t the total number of bytes written that causes the SD card to wear out, it is the total number of write operations. Each block can only be written to a certain number of times and then that block cannot be written to any longer. But when the blocks start to wear out, there is nothing to tell the computer that the write failed and that block is worn out and everything continues along as if the write were successful.
So the writes are not taking place in the same part of the card over an over. The controllers are smart enough to wear level the writes.
And it has nothing to do with size of the writes. 1 million writes of 1 byte is just as bad as 1 million writes at 1024 bytes (the block size).
So the problem with OH, particularly OH with events.log enabled and rrd4j saving state is you will have lots and lots of little writes per minute which can reduce the lifespan of the SD card significantly.
Thanks for pointing this out, I thought the same, but I was not sure that this is how it works exactly, because it is almost the same how and SSD works, but I was not sure about that this is true for the SD as well.
Works the same but SSDs have some capacitors or batteries in place to give the drive a chance to finish writing what it is in the process of writing when power is lost so they are more resistant to file corruptions on loss of power.
I know Rich, I was simplifying things a bit.
You kind of got told off on that lighting thread… I am interested in the suggestions you deleted. Any change you could PM me with them, please?
However I have updated today to 2.3.0 and it seems much-much better than 2.2.0. Lots of my issues seems to be gone… Just need a little time to prove this!
However I had to remove the wifiled binding. It is not a big problem for me, because my whole smarthome is in “beta” yet, and I just trying out different leds, etc with this binding. But do we know when a fix will be available for this binding? And if I’m on the stable channel how can I install this updated version? Replace the addon file?
You will have to look at the open issues on that binding. There are over 330 bindings. It’s impossible for any one person to keep track of them all.
It depends. The “safest” way (not super sage, hence the quotes) is to upgrade the whole OH. There can be changes made to the core of OH that make newer versions of bindings no longer compatible with the older OH core. If that hasn’t happened, you should be able to uninstall the old binding, download the jar file for the new one, and drop it in the addons folder.
Now I can say for sure that the cause of this whole freezing thing was that I had OSMC installed on Raspberry. I know that this was not a good thing, but I just started using openHab then, and it was easier to install openHab on a configured device. Now I have a dedicated server for openHab.
However I have tried it for a few weeks and if someone wants to try openHab and has a Raspberry for media playback with Kodi, you can do this:
Install openHabian on the Raspberry and later install Kodi from package.
This will have the best performance, but don’t use it for bigger and complex setup, mainly just for trying out openHab!
