• Have you tried out dark mode?! Scroll to the bottom of any page to find a sun or moon icon to turn dark mode on or off!

diy solar

diy solar

Software system design and reliability.

Luk88

Solar Addict
Joined
Apr 5, 2024
Messages
783
Location
Poland
I'm starting this thread to hopefully collect your experiences with the reliability and general ease of use for different types of DIY software system designs. What are your regrets, as in what would you do differently if you were starting again? Any advice for others?

For a start let's assume anyone doing DIY software already knows some programming and has plenty of "general computers knowledge". This is not about linux vs windows, open source vs proprietary(if you make custom components for your proprietarty system of course) etc.

So what do I mean by software system design? Things like:
  1. - Controller centralisation/modularity?
    • Use one computer (Raspberry PI, PC, Intel NUC, whatever), connect lots of interfaces to it that talk to all hardware components and run all the software on it?
    • Use two computeres in some sort of resilient, fault tolerant setup?
    • Use a bunch of small devices like ESP32, each programmed for a very specific purpose?
  2. Software centralisation/modularity (only for centralised controller/s)?
    1. Do you run one piece of software that does everything? (maybe except recording and presenting stats)
    2. Do you run bunch of programs/scripts all under the native OS?
    3. Do you have a bunch of programs/scripts that each run in its own docker container (If so, do you use, or wish you did use any container orchestration)?
Then there are details, like:
  • Imagine you're pulling data from current sensors, tempearture probes, BMSes, you're doing analyzing it and you control a bunch of inverters via their rs485 BMS port. Would you:
    1. Write one multithreaded script/program that reads/writes through all serial ports.
    2. Use existing tools like mppsolar to fetch data from the BMSes (via serial), put it in MQQT and have your scripts only consume the data and do the actual control?
And anything else you can think of you have positive/negative opinion based on experience? I'm slowly putting together my system and I'm trying to learn from other people's experience here :-)
 
I got some great answers in this thread
 
Thanks for the answer @hotnoob , you've expanded the scope I had in mind considerably. All these are valid concerns, but I'm going to narrow down my response in hope someone will actually read it if it's not too long😁
reliability is a combination of redundancy and simplicity.
The theory side of things is pretty straightforward 😁 I started the thread asking for experiences to hopefully learn something about where the optimal balance between redundancy and simplicity is in our DIY systems.

considering energy constraints, because this is solar!
for optimal reliability...

1 central server, no failover switches, multiple sensors.
Is this how you're running your system? If so can you expand on this, please?

What specifically would stop working if the server dissappeared now? How long have you been running it like this? What (if any) did you have issues(even just annoyances) with?

On the hardware side, how do you power the thing? AC, DC to DC? How do you like what you have?


without energy constraints,
1 central ha cluster setup, pairs of failover network switches, multiple sensors.
now considering things like modbus are pretty dumb, i'd think failover modbus adapters should be possible if they don't already exist.
That's the essence of simplicity vs reliability vs ease of adding new features right there.

The easiest way to have multiple masters(only one active at a time) on a serial link IMO would be to convert everything to rs485 (so a "standby master" can be connected all the time to the same bus). On the hardware side this is relatively simple, but it can increase the software complexity considerably if we decide we want to monitor how the other master is talking to the devices and so on to detect failure.

I decided for now cold standby is more than sufficient for my needs (a spare raspberry pi sitting in a drawer, ready to be swapped in). But I'd love to hear from others that decided different.

for interfacing with sensors.
esp32's are simple and reliable, you can use them as simple modbus rtu to modbus tcp adapters... or just go straight to mqtt.
I meant more in terms of self contained control blocks. Let me give an excample. There is this open source project that runs on an esp32. It talks to a BMS on one side and the inverter on the other. (with some extra coding) It let's you change how the battery is being charged by adding things like absorption (while the BMS may not support it) or temperature dependant max current etc.

When you have one bms and one inverter that is an easy choice. Just use the thing. Maybe have it export to mqtt for monitoring at the same time.

But when you have 4 sensors (3 BMSes and a smart shunt) and 3 inverters to talk to that is too much connectivity for an esp32. So a kind of obvious solution is to have this functionality implemented on the central controller (raspberry pi etc). But then the most important part of the system is subject to issues with other system components.

Maybe your disks fill up with logs and you don't notice? Maybe it will bog down when you add yet another piece of software? A single purpose, real time device has none of these issues, but it is also arguably more difficult to program as many things you take for granted on an OS(multitasking, multithreading) are no longer there.

Also from the hardware side one would need something like an esp32 but with at least 8 uarts, 10 preferably (7 needed now, 3 for expandability). That's a lot! For a computer (a rpi etc) one can just plug in a hub and usb to serial adapters.

So this is one of my main choices to make.

I got some great answers in this thread
What was this film called, inception? 😱
 

diy solar

diy solar
Back
Top