While I certainly appreciate the robustness and overengineering of professional industry solutions, I don't really see why you consider RPi to not be reliable. Of course, we are not talking 99.9999999% uptime here. I personally would trust RPis for a project at 150 km driving distance. There could always be problems of a multitude sources. If you want really high availability, then redundant installations are a bare minimum and also, the rest of your system would need to be as reliable as the Node-RED hosting device itself. Weakest link in the chain applies.
I don't say that the Pi is not reliable, it is not designed for industrial environment. EMC wise, certification, operating tempratures, SD-card usage a.s.o. make it not suitable. Personally I follow the progress of https://revolution.kunbus.com/ very closely. And I think we will see these solutions in near future more often. And hopefully opens the very vendor locked market in the industry.
But I hope that the common Raspberry Pi will never be made fit for industrial environments or any other specialistic. Simply, because of the price. Let the openness of the Pi project take care that companies will make their own solutions around it.
And for OP's solution I still recommend to use OPC UA. (Which also has a very great node in Node RED )
No, I'm afraid you don't. That was the point of my previous comments and here: [Reference] Optimising Node-RED - #5 by TotallyInformation.
It is certainly true that what you say will lighten the load on the card and make it easier to last longer.
However, this is certainly not required. A decent card is certainly capable of lasting years with at least moderate use. My own cards have lasted a long time (years) with no special care at all. Albeit that they are getting what I would call moderate use - they consistently see 1-2 writes per second 24hrs a day. Last time I had to replace a card was in 2015. That was when I moved to larger cards of better quality - not had a failure since then.
Have you got a reference to support that? I understood that it is the total amount of data on the card that matters, not whether it is inside or outside the formatted region.
Just curious: what micro SD card r you using?
We have Pi in industrial environments running for years.
We only use Sandisk Micro SD cards.
Wear levelling happens at the controller level not at the filing system level. It doesn't matter whether you have assigned the whole of the card to a partition or not.
Not that many vendors publish anything about wear levelling for their SD-Cards. However Sandisk do.
The cheap cards may not do wear levelling even today but good quality cards have done it for years now. This is one of the main reasons that we don't see many failures any more.
Hi.
Please post how-to on your formatting procedure you mention, what tool you would recommend etc?
Hi. Decent Power Supply - do you mean something like a Din-Rail type from a good household name Meanwell, Omron or Phoenix etc?
I think that would depend on how you want the device mounted. Just be sure it can really supply the required power - it should be able to sustain at least 2-3A for a Pi3 or 4-5A probably for a Pi4 Best to avoid using USB power for reliability. As with all these things, get a decent brand, preferably one made specifically for your market/region - don't stint on power if you want reliability. If you do have to use USB for power, also double check all of your USB cables - some of them have serious power loss. Maybe get some to test. Then test them under a standard load to make sure that the voltage and current is stable.
Ok, I read some more on this topic. While SSDs and SD cards are both based on flash storage, namely NAND technology, the implementation differs a lot. SSDs have different standards than SD cards, and there are numerous differences technically under the hood. SSDs have standards like TRIM and wear leveling technologies that are part of the spec. SD cards don't. It means it's up to the manufacturer to implement wear-leveling on SD cards. The lack of a standardized solution means some manufacturers don't include these to save money. Not to mention the abundance of fake microSD card.
Just as you said, more expensive, high quality cards (also High Endurance series) are typically OK for years.
Are you saying that wear-leveling has nothing to do with partitioning? Samsung Magician and other SSD manufacturer tools have over-provisioning as a feature. What this does, it shrinks the partition creating unallocated space. The rule of thumb is at least 10% of capacity allocated to overprovisioning. Why would this be different for SD cards? Also, over-provisioning is a big deal in datacenters where there are high IOPS workloads to boost endurance. I have heard of 90% overprovisioning (just using 10% of the capacity of a drive). As I understand it, the firmware is treating differently partitioned free space than unallocated space. Am I getting this wrong somehow?
I tried Kingston and Sandisk cards, could not see any difference. Both brands were fried in a matter of days. For me, the Pi experience was a big disappointment.
I stopped torturing myself and am using Linux pc's now.
In that case either you were doing something extremely unusual or there was a hardware problem damaging them, or you had bought fake cards.
I used the power supply and SD cards that were recommended (and supplied) by my supplier, and I used it for monitoring temperatures in my solar system; writing the data once per minute.
In my opinion that's not extremely unusual, and I still don't understand why it gave out so quickly.
I would love to take a new look if Raspberry developed a Pi that can boot from a SSD.
Is that a typo; should be 2-3A (10-15W).
Power Supply - Raspberry Pi Documentation
Thanks for the correction Paul.
Also worth noting that newer versions of Rasbian at least report when the device is receiving less power than idea. I know because my Pi3 tells me regularly! It is powerered from a USB multi-plug power supply and I'm guessing (I've not actually measured it) that it is only getting around 2A or possibly that the cable I'm using has dropped the voltage slightly. I really must get a USB power tester.
Even so however, I've not had any problems and haven't had to replace the card since I first set the device up. In addition to Node-RED, it runs: Telegraf, Grafana, InfluxDB, Mosquitto, Ubiquity Wi-Fi Controller (Java) and probably a few other things. So it is being pretty well utilised.
pi@pi3:~ $ sudo dumpe2fs $(mount | grep 'on \/ ' | awk '{print $1}') | grep 'Filesystem created:'
dumpe2fs 1.43.4 (31-Jan-2017)
Filesystem created: Wed Apr 18 02:07:02 2018
pi@pi3:~ $
I believe that is correct though I've not studied the standards. It is up to the manufacturer to implement such things.
Really, the Samsung EVO cards aren't expensive. Though you do need to check that you didn't get a knock-off copy. For industrial use, I would buy in batches and test.
Yes, that is correct.
I'm not an expert but I would guess that this is to prevent the disk from being completely filled because at that point wear levelling is less effective. In addition, the controllers on SSD's are going to be more capable than those on SD-Cards and the algorithms are likely to be more sophisticated. I don't believe anything that complex would be implemented on an SD-Card which are, after all, largely consumer and photography based where space "missing" from an advertised size is likely to be noticed and reported negatively.
In addition, any partition should not be filled beyond about 80% capacity as it increases file fragmentation if you have large files and this can, in some circumstances, slow down disk read/write performance.
No, that is not unusual, in fact it is a very low utilisation. Just because you used psu and cards that were supplied by the supplier does not mean there was not a hardware fault. Similarly all cards are supplied by a supplier, that does not guarantee that they are not fakes
Hmmm, I thought about that. Raspberry, psu and SD card were in the same box, all components have the Raspberry logo. How can I know whether it's any good?
There are tons of tools and guides...
I'm suspect to talk, since I work for ST-One, but we work very very hard for almost two years to keep the SD incorruptible and make a hardware that is robust enough for the industrial environment, trust me it is not an easy task. The magic is not only in the hardware but mostly in the custom OS.
Most of our applications are remote (specially power plants) and it is running perfect for almost 3 years 24/7, but we had to develop many tools and softwares to have a plan B, C and D in case of any kind of problem.