Single dashboard for multiple PI through MQTT

[HZB]

Hi Everyone,

I am newbie & just learning Node Red. So i need help!
I need to get status of 23 different machines by using 4 different buttons and need to show all this information in a single dashboard. My idea is to use 23 different PI on a same network and send data using MQTT and run Node Red on my PC to make a Master Dashboard. Is it a right way? any other suggestion.

And i need help in establishing MQTT broker in my PC.

Thanks!

[Paul-Reed]

You need to speak with Andrew @Trying_to_learn, he has built such a system.

[HZB]

@Trying_to_learn Hi Andrew please take a look. Thanks.

[Colin]

The concept of using MQTT on the PC with a master dashboard to display the information from all the machines is a good plan I think. Though you might like to consider the idea of a separate server to run node red and the broker on, and connect to that with your PC (or any other PC or device on the network). Otherwise if your PC is not available the dashboard will not be. Also if you are logging data then that can be done in the server.
I suggest using Mosquitto as the broker on the server/PC. If it is running Ubuntu then to set the broker up is just
sudo apt install mosquitto
and the default config may well be exactly what you want. If you are using Windows then I imagine it is similarly easy but I can't help with that.

When it comes to how to organise the MQTT topics then think carefully about that in advance. You may well want, for example, the top level topic to be something like a machine id so you can switch between machines in the dashboard just by subscribing to id1/some/topic or id2/some/topic. Doing that you could have one dashboard page for the details of a machine and use a dropdown or something similar to select the machine you want and use that to route the data from the appropriate MQTT In node to the dashboard. Then the dashboard itself will work for any machine.

[HZB]

thanks,
what are the pros and cons of using IBM Cloud for Master Dashboard, rather than a designated PC running 24/7?

[Paul-Reed]

@HZB

what are the pros and cons of using IBM Cloud for Master Dashboard

Because a cloud server will have redundancy, with almost guaranteed uptime, whilst a local PC may have increased downtime - power cuts, updates, faults, etc.

It depends how important that the resilience of your master dashboard is to you, and how risk averse that you are.

[Colin]

A con is that if the internet connection goes down then you have no dashboard.

[Trying_to_learn]

Yeah, I've got a similar thing going.

(Not to show off, but this is a screen shot of my equivalent to what you want to do.)

But you really need to take it in steps.

First off determine EXACTLY what you want the machines to do.
What information they send, etc.

Then: how it is displayed.

How are errors handled.

How are machines locking up handled.

Reboots, etc.

And even maybe updates, and backups.

I say all this because it is a mine field of things. I have had a lot of learning to do with things that at first weren't considered but as time went on, they became needed and that was painful.

Also, learn a lot about sub-flows.
They will save you a lot of grief in so many ways.

Rather than messing around with 23 sets of code for the 23 machines (on the one) and having to sit there for hours rolling out an update to all the other 22...... Use subflows.

[Colin]

@HZB Another idea you might like to consider is to have local mosquitto brokers on each of the Pis (which is very easy to setup) and use MQTT Bridging to automatically synchronise selected topics with your central broker. Then you could have both a Cloud broker and one on the PC (both bridged from the Pis) and can run exactly the same dashboard connected to the PC broker or the cloud one.

Also you could run a subset of the dashboard in each of the Pis so you could have a local display at each machine which is only reliant on the Pi and not the remote brokers at all.

[HZB]

@Colin
Can you recommend me any example to learn how to use MQTT. I am really noob in this matter. Just started Node Red and it's fun and good. Thanks

[Colin]

@HZB

Can you recommend me any example to learn how to use MQTT

The best introduction I have found is MQTT Essentials - All Core Concepts Explained. You can work through it online, or I see there is now a e-book available.

[HZB]

@Trying_to_learn
Thanks

Can you tell me which node did you used for this part?

[zenofmud]

@HZB - please don’t open a thread AND post the same question in another thread, it just wasted people’s time.

[Trying_to_learn]

That is a lot of button nodes.

The button is set so it shows the icon and colour of the message it receives.

Each icon (button) represents a machine and there are different colours and icons depending on the machine's state.

That may be a bit ahead of what you want to do just now.

This is because you need to work out which conditions you want to detect and how they will be shown.

For instance:
msg1 = {payload: '<font color = "red" i class="fa fa-exclamation-circle fa-2x"></i></font>'};

Is shown if a serious condition happens.
This is also shown until the button is pressed and then it goes back to .... normal.
(That's a whole other story)

But I hope that helps you in some way.

[Trying_to_learn]

To keep things here and not in the other thread, this is how I have the button node set:

[{"id":"de1cd0.47fce33","type":"ui_button","z":"c636aa5a.cc34","name":"83","group":"1f5fe937.c354c7","order":2,"width":"2","height":"1","passthru":false,"label":"<font size =\"4\">83</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{{msg.payload}}","tooltip":"","color":"","bgcolor":"#333333","icon":"","payload":"HEALTH_ACK","payloadType":"str","topic":"","x":1390,"y":1190,"wires":[["176f7b4f.d7fb5d","be5e454f.a21318"]]},{"id":"1f5fe937.c354c7","type":"ui_group","name":"Cat-5","tab":"1c792414.600e94","order":3,"disp":true,"width":"10","collapse":false},{"id":"1c792414.600e94","type":"ui_tab","name":"Telemetry","icon":"track_changes","order":2,"disabled":false,"hidden":false}]

You will have to edit the name field to more suit your set up.

I did/was/am thinking that the name is actually set by the computer, but as I run fixed IP addresses, it wouldn't serve much purpose.

[Trying_to_learn]

This is what you are getting into for displaying multiple device status on a machine.

The bigger picture

Where sub-flows become handy.

What they were before sub-flows.

And even then: before the sub-flow it was painful, and the big function node in the middle was hard to maintain. As any update had to be rolled out n times for each device.

Now with the sub-flow, it only needs to be done once.

There are some problems with this, but not anywhere near as bad as the problems doing it this way fixes.

Update:

Just to show you some of the stuff which happens on the dashboard.

All normal:

Machine booting:

Booted:

(Yeah, ok, the colour scheme may need tweaking.)

Ack the boot (Click on the button):

And at last, All good:

This is a lot of stuff going on and I am not saying you have to do this.

I just got involved in showing status of machine etc and really got hooked on it.

There is/are also health messages and if the machine locks up on boot - or more precisely: NR doesn't start up in a given time.

But just to show you things that if you don't consider now, can really bite you hard in the future when you try to apply them into the scheme.

[russ57]

You mentioned a pi for each machine. If all you have connected on each is 4 buttons, the pi may be overkill. I'd look into an esp8266 of some type, or an esp32. Much cheaper, smaller, lower power., and wifi. Or if you need higher reliability from comms, an arduino of some type with ethernet.

[Trying_to_learn]

Yes @russ57 but you also need to understand that I can only work with what I have.

And know only what I know.

At the time I didn't have an esp32 (or similar). And they don't have dashboards/web GUIs.

It works with all 10 Raspies on, but that isn't that often.
The load is low - though it does spike every now and then.

[russ57]

No issues whatsoever with using what you have. From a long term reliability view, and cost for 23 pi and power supplies and cases, it could be worth investigating. You haven't said what the machines are, or the requirements for reliability, and perhaps the hardware cost is insignificant compared to other factors. But development on the esp platform is pretty simple.

[kuema]

@russ57

But development on the esp platform is pretty simple.

Plus, there are some ready-to-go firmwares like ESPeasy, so you don't even have to write a single line of C code. If you're just doing "simple" stuff, like reading sensors (one wire, I2C, ...), inputs from switches or control some relays, these are more than sufficient. Wifi and MQTT included. Those devices boot nearly instantly after power up, and consume only a fraction of the power. And you don't have to worry about power outages that could damage your filesystems.

I abandoned the RPi for these kinds of tasks a long time ago, much less maintenance work. Think of all the OS updates/upgrades you'd have to do for 23 RPis...