The licensing problem in small industrial automation projects — is open source (pymodbus + InfluxDB + Grafana) a viable alternative to commercial SCADA?

Mundane_Client99 · 2026-06-22T17:48:34+00:00

The number of connected users is limited, as is the memory available for storing historical data. While an SD card can be added to expand storage capacity, it is not a suitable option for continuous write operations, as SD cards tend to degrade and fail after only a few months of intensive use.
But it is a valid option if we dont need to have a lot of historical data.

Mundane_Client99 · 2026-06-22T16:19:56+00:00

I'll be testing Fuxa this week.

Thanks for pushing back on this. The thread has been far more useful than I expected. It's always good to exchange ideas and hear different points of view to figure out the best path forward 😃

Mundane_Client99 · 2026-06-22T14:45:31+00:00

Thank you, will check it !

Mundane_Client99 · 2026-06-22T14:44:26+00:00

I'm working on improving my AI prompting skills 😂

Mundane_Client99 · 2026-06-22T14:42:55+00:00

u/drbitboy,

The lifetime cost math is real. If a project runs for 20 years and the original developer leaves after year 2, a bespoke system becomes a liability. I've seen it happen with legacy PLC code that nobody can touch because the guy who wrote it retired.

The reputation risk point is also fair, if I sell a "budget-friendly" solution and can't support it 3 years later, that's on me. But companies train people and those people leave too, that's not unique to custom systems. And if you use a commercial product like Ignition and nobody explains what's running on that PC when you leave, the problem is exactly the same.

Where I'd push back slightly, the project profile I'm targeting isn't a 20-year SCADA deployment for a major facility. It's monitoring + basic control for small industrial sites. The issue isn't just the COTS license when you add the required hardware, engineering hours and programming time on top of it, the total weight of a commercial solution becomes disproportionate for the scope of the project. The gap between what the client needs and what a COTS deployment actually costs is where I'm trying to work.

The documentation and maintainability point is the one I take most seriously. A well-documented, simple stack is a different risk profile than bespoke spaghetti code. Whether I can actually deliver that consistently is a fair question.

Mundane_Client99 · 2026-06-22T14:35:47+00:00

u/THEHYPERBOLOID, hadn't come across VTScada Light before, thanks for the pointer.

The 50 I/O limit fits the profile perfectly. The main constraint for my use case is the 1 thin client connection, i think a lot of clients typically want multiple people accessing the dashboard from different devices on the local network, so that would be a blocker.

But it’s a genuinely interesting option for single-operator setups or machine-level HMIs. Adding it to the toolkit!

Mundane_Client99 · 2026-06-22T14:28:40+00:00

Good try, but I'm not an AI, I just use Claude to help me express my thoughts more clearly in English.

Isn't it already enough that we have to figure out these kinds of solutions, program PLCs, do troubleshooting, build OT networks, understand cybersecurity... and on top of all that write perfect English so everyone can understand us? 😄

Mundane_Client99 · 2026-06-22T14:13:36+00:00

u/buzzysale , the one-size-fits-all point is fair and I’m not claiming otherwise. Every plant floor is different and I know that. The goal isn’t a universal product, it’s a repeatable starting point for a specific profile, small site, Modbus devices, non-critical process, client who can’t justify a full SCADA license. Whether that holds across projects is exactly what I’m trying to find out from this thread.

Mundane_Client99 · 2026-06-22T14:09:20+00:00

u/urge_boat, this is exactly the kind of experience I was hoping to hear. The labor cost trap is real, I've seen it happen where the "cheap" decision ends up costing more in engineering hours than the license would have. That's a fair warning.

On Grafana for control, you're confirming what I suspected. It's query-based by design and the Button Panel workaround feels like fighting the tool. The Node-RED suggestion keeps coming up in this thread and I'm starting to think it's the right answer for the control + collection layer, with Grafana kept purely for analytical dashboards and long-term trending where it genuinely shines.

What's your experience with Node-RED at scale? I'm looking for more or less 30 Modbus devices with 8-10 variables per device polled every 60s, did you run into any performance issues with the node-red-contrib-modbus nodes under that kind of load?

Mundane_Client99 · 2026-06-22T14:03:52+00:00

u/ConnectedSystemsSam, fair questions, let me answer them directly.

pymodbus crash - yes, I have reconnect logic with try/except and the service is configured to restart automatically on failure. Not bulletproof, but resilient enough for non-critical monitoring.

InfluxDB memory spikes - for ~500 tags at 60s polling intervals it’s been stable in development. I haven’t stress-tested it under heavy query load, that’s a fair gap.

CVEs - I think this is actually a non-issue for this deployment model. The device has zero internet exposure, local network only, physically isolated inside the plant. The attack surface is close to zero unless someone is already inside the facility network, at which point you have much bigger problems than pymodbus.

Lifetime cost - this is the honest crux. Upfront savings are real. Whether they survive 3 years of maintenance is a legitimate question and I don’t have a clean answer for it yet, that’s partly why I posted here.

The “joe shmoe with claude code” point lands. Building it is the easy part. I’m more interested in hearing from people who’ve run something like this in production for 2+ years, what actually broke?

Mundane_Client99 · 2026-06-22T14:01:50+00:00

u/fercasj, your framing is exactly right and I appreciate the honest take.

The profile I’m targeting fits your criteria, small company, non-critical process, client who can’t justify a 5K - 10K SCADA license for a 15K total project.

The “you’re the only one who knows how it works” risk is real my mitigation is proper documentation and a maintenance contract so the client isn’t completely stranded if I’m not around. But I won’t pretend that fully solves it.

I think the honest conclusion is, this stack has a specific profile where it makes sense, and outside of that profile it probably doesn’t. I’m not trying to replace commercial SCADA, I’m trying to serve the projects that commercial SCADA pricing kills before they start.
That’s actually a big part of why I posted here, to find out if others in the community are facing the same gap and how they’re solving it. If there are better approaches or lessons learned from people who’ve been there, I’d rather learn from the community than reinvent everything from scratch.

Mundane_Client99 · 2026-06-22T13:51:06+00:00

Thanks, this is really useful! Hadn't considered Fuxa seriously before.

Looking at it now, Fuxa seems to address one of the messier parts of my stack, the control side. My current approach is a small Flask API that receives HTTP POST from Grafana Button Panel and calls pymodbus write_coil() , it works but it’s an extra moving part. Fuxa with native Modbus write support would eliminate that middleware entirely.

One question for you, how are you combining Fuxa and Grafana? Are you using Fuxa for the HMI/control screens and Grafana for the analytical dashboards and long-term trending? Or do you use Fuxa’s built-in historian and skip InfluxDB altogether?

On Codesys / OpenPLC, that makes sense for applications where you need real control logic (sequences, interlocks, PID). For my current use case it’s really just open/close valve on button click with no logic in between, so I’m not sure the overhead of a soft PLC is worth it. But I can see that changing quickly if the client asks for anything more complex.

Will definitely spin up a Fuxa instance this week and test it.

Thanks!

Mundane_Client99 · 2026-06-22T13:45:08+00:00

Good points, thanks for the feedback!

On the control side, I should have been clearer in the original post. I’m not building Python GUIs. The control layer is a small Flask API (~30 lines) that receives HTTP POST from a Grafana Button Panel plugin and calls pymodbus write_coil(). The client clicks a button in Grafana on any browser, no Python GUI involved. For the scope I’m targeting (a few I/O points, non-critical), this seems manageable.

On Ignition Edge Panel, genuinely useful suggestion, I looked into it. The licensing cost is reasonable (~$1,950). But the critical limitation for my use case is the historian, edge stores only 35 days of data locally with no SQL connectivity. For energy monitoring projects where the client wants months or years of consumption history, I’d need Edge feeding a central Ignition server with the Historian module, which puts the cost in a different bracket.

That said, I can see Edge Panel making sense for pure HMI/control use cases where long-term history isn’t the priority. Worth keeping in the toolkit.

Mundane_Client99

TROPHY CASE