Hello! The Gateway on Raspberry Pi has killed 2 of my SD cards so far. I suspect it’s because of the logs. Is there any way not to give up logs and not to kill another SD card?
I Michal,
Sorry to hear you’re having problems. It’s true microSD cards are not great at handling a lot of write operations and can be unreliable, but not all SD cards are made equal. I’ve had a gateway running continuously from the same SanDisk microSD card for several years without any problems. What brand are you using?
I assume you’re talking about the developer logs available via developer settings rather than user logs created in the logging section of the UI? Feel free to file an issue to add a setting to developer settings to enable/disable logging in case that might help.
Ben
I bought and installed an external SSD, it’s much faster than an SD Card and has been absolutely stable for me. Buy a small cheap SSD, the RPI does not use huge amounts of space.
If you buy an external HDD, then ensure you get a separate power supply, the RPI cannot provide sufficient power at all times. If the HDD tries to take too much power, the RPI may disconnect the HDD to protect itself and then crash.
Hello Ben,
The last one that got out was 32 GB GOOD RAM.
I’m talking about user logs from the UI. I knew there could be problems with that. The cards lasted about half a year each.
Is there any software advice for this?
Hello,
I am not sure whether it is a possible solution on a WebThings gateway, but it can really halp in case of a “normal” debian. Use virtual drive mounted in the RAM space.
Yes, the space is very limited, and yes, you loose the content when you switch off the RPi, but you won’t kill SD card with temporary files. And the content can be written to SD automatically when the power off procedure is running. And as a part of startup it is restored to RAM disc.
So in total there is only one disadvantage. Good thing is that it is natively supported by Raspbian. The question is if it can be used by WebThing gateway.
Regards,
PR
- Only add the values that you really need/want to the UI Logs (graphs). Remove items that you seldom look at.
- When adding items to the Logs, ensure that you make the retention a maximum of 7 days.
- If possible, do not add frequently updating values to the log. I.e. something that changes every second will blow up the Log database, noticeable in long loading times.
- Consider running a purpose built graphing solution on another computer. I installed Influx and Grafana on a virtual server on my main PC. There’s an extension that allows the Gateway to send data to Influx
On my RPI I mounted a USB stick and have Gateway logs stored on the USB, not the SSD, partly to avoid write issues. Creating a sym-link from the GW log folder to a USB folder would help. My current USB is a year old and running fine. I’m sure it will fail too at some point. Cheap to replace as long as you have a working backup.
You could link other GW folders onto the USB too in case an “addon” stores local logs (not sure how that works).
I’m actually running the GW using a Docker container and store all it’s files on the USB. I previously posted the /etc/fstab command to mount the USB on boot that you can search for.
There are other solutions on the web to reduce log writes on computers with SSDs that you may want to check out. In my work doing large-scale data analysis we create RAM disk file systems as scratchpads and/or intermediate transformation storage. This is also a solution.