I’m using now openHab for months. However the biggest issue which I have a while ago (and I haven’t found the solution yet) is that openHab sometimes freezes. It is very random, sometimes it happens after days, sometimes after a half a day.
Anyone experienced something else?
What I think it might cause the freeze:
I’m running Kodi also on that RPi, maybe the resources is not enough (sometimes the whole thing freezes, I can’t even SSH to the device, I have to unplug it)
Maybe there is some bug in one of the bindings which can cause this? (Usually just openHab freezes, and everything is working fine, however I can’t restart the docker of openHab.)
I have tried looking at the log, but nothing outstanding happens there. I have some errors sometimes, but as I looked after them, they are not really errors (HomeKit disconnects, Chromecast device disconnects, and other errors like this).
I’m a bit clueless how can I debug this error. Buy another board install openHab on it and try it if it’s works if only openHab is installed on that board?
Overall, is a Raspberry enough for running an openHab server with a complex setup? (Unique Habpanel, more and more things and bindings included in my setup…)
Yes definitely, with KODI running at full blast on top, maybe not.
How old is your SD card?
Do you have persistence set-up? Is it on the SD card or remote data store?
What you describe looks like SD card failure. Some block of memory become corrupted after time and are not recoverable. Especially if
That’s is definitely not good for the system.
Get yourself a fresh SD card, good quality if possible.
Copy (Don’t back up) all your conf files
A back up will also save the corruption of the card
Install raspian, OH, KODI…
Copy your conf files, install your bindings, actions…
You should be back to normal
I would keep monitoring the RPI when both OH and KODI are running (Maybe with the systeminfo binding) just to check that the CPU is coping with the load.
Thanks! Yes, I forgot to include, but I thought also of this.
I have checked several times the load, usually if Kodi is on idle (no movie running, etc…) the CPU usage is around 30-40% which seems a lot for a device which is on idle, but I think it might not cause a freeze.
Yes I have rrdj4 persistance (no Grafana and other things so far), and it stores the data on the SD card.
Thanks, firstly I will try it with another SD card!
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?
