Working dashboard- next steps?

Hi folks!
We've been prototyping with a ClickPlus PLC talking to mosquitto, ending up at Node-RED, with the goal of ending up with a web-enabled product. We almost have the PLC running through a VPN for remote access, now it's time to get MQTT and Node-RED doing the same thing to continue development.
What are some good steps to take so we can monitor and manage its development remotely? For now, I'm able to visit my dashboard, monitor data, do some minor controls to the PLC using any device on our HQ network, but I'd like to be able to see the data coming from the PLC from anywhere. What's it take to get to that point? I've read a lot but haven't really found what I'm looking for. We have the capability to add some things to a spare appserver which I understand might be an avenue we can take.
If you have some experience with this type of thing, let me know what you've done for this goal! Thanks!

Through the VPN you should be able to see the data in the same way that you can when connected locally.

Mosquitto and Node-RED are running on my PC though, so when I leave our building I can no longer access them. I'm hoping to get it set up so that when I'm away I can go to a webpage and still view and manage things

I don't understand. I think you have not described the network topology clearly. What is running on what and where, and where is the VPN running?

My bad. Here's some more info-
Our modem runs into a firewall, then into a layer 1 network. Layer 1 is feeding our cameras, phones, computers, smart devices, etc. in addition to a layer 2 network for IIoT development and some additional cameras (boring). The PLC is on that layer 2 network, and once our IT company finishes up implementing the VPN I should be able to access it again from my desktop on layer 1 network, or anywhere else. The PLC can still send out and receive MQTT messages to the broker but I can't connect to it to do any programming on it for now.
Mosquitto and Node-RED are both currently running locally on my desktop which is on the layer 1 network. I think I need to get them off of my desktop and onto an appserver we can set up on a spare web domain to accomplish my goal (viewing and modifying all my Node-RED programming from anywhere, to develop a web app) but I'm not certain.
If I understand the networking side of it correctly, the VPN is running on our modem.

Yes, that is absolutely what you need to do. Either a physical or virtual server.

I you want to improve security, consider having 2 VPN's. One for customer access to the Dashboard and one to your node-red Editor, file system, etc.

Or better still, use a proxy server as the edge control for the Dashboard, with user login to control access. Then restrict the VPN to people who need access to the Editor and other aspects of the server.

That isn't relevant. What IS relevant is what access people have when they use the VPN. A corporate VPN of this type potentially opens your internal network to external users and that can be problematic.

1 Like

That's the route I'd like to take with it, to keep customer access and administrative control separate. One issue is how we go about pushing updates to PLC's in the field and/or connect remotely for troubleshooting but we'll get there when we get there.

That's the scary part to me as well. Frankly I'm a little out of my realm but our IT company and the owner are much more knowledgeable than I am with this dynamic. My concern is giving end users essentially zero ability to enter our own backend network.

Well you have not told us much about the scale or potential number of users etc - but as an initial proof of concept i would do the following

  1. Implement a Raspberry PI or similar on the same network as the PLC devices feeding it the data - on this device would be your "internal" node red instance that you would use to generate and manage your flows, host the Mosquitto broker and the like

  2. Impement a 2nd device (could be another Rpi depending on number of customers involved etc) and put it out on a seperate network segment where it is isolated and access it controlled through a strong firewall and a proxy server

  3. Have the internal Rpi with NR push data that is required out to the Pi on the secure segment and display it for customer consumption in either NR dashboard or some other acceptable medium


I would say conservatively a couple dozen users within its first year on the market, but needs to be able to ramp to a couple hundred over the next 2/3 years. This is based off of historical sales of similar product offerings, which this product will exceed in capabilities- we just need to keep BOM and R&D costs as low as possible so final sale price can remain competitive.

I like that idea. Two Pi's would help keep overall costs lower and insulate internal vs external data handling. Is Pi strong enough to handle the demand of this, and user data if they opt into it? The PLC will remain responsible for the base functions of the product so Pi doesn't necessarily need to handle that, but there are other products in mind that could benefit from edge computing.

A Pi is a pretty solid platform as long as you take care of its power supply and possibly use an SSD drive instead of an SD-Card.

But if your IT department has a virtual server capability, that would almost certainly be far better. A small Linux or BSD virtual server in an enterprise configuration is always going to do better than a Pi. With the advantages that IT probably already have the monitoring and backup capabilities sorted and an enterprise VM can be moved to new hardware at the drop of a hat.

Total cost of ownership would probably be lower as well since the Pi's would need people with knowledge of the hardware and OS, different backup/recovery processes and so on.

Insultation of the data would come from putting the live server into a DMZ.

1 Like

Yep as Julian has said - if VMs are an option then that is your ultimate solution if your IT department provides this and the infrastrcuture around it.

Infinitely scalable and easy to pick up and host off-site if required at a later stage for more capacity/accesibility/performance


1 Like

Thanks guys! We've successfully moved the network config & test environment including broker and Node-RED to a monitored data center. After some serious head scratching, everything is functioning as it was before the transition. Now to get back to development!

1 Like