I’m toying with the idea of using MQTT as a communication method for data between a web app and the EPIC. I’ve got the EPIC publishing data with the MQTT capability out to a broker - all good thus far.
I’ve been digging to see if there is a simple way to subscribe/write to update the control strategy using MQTT. Could I publish something to a topic like myBase/myDevice/Strategy/Numeric Variables/onSwitch with a payload of “Turn On” or “1” and have it update the strategy variable when received?
you could use Node Red to subscribe to the broker and then use the pac node to post the variable straight into the strat depending on the status of said payload.
You have a few options here but I would use Node Red for simplicity
I have a setup here using a PAC R1 and MQTT, as @sengsberg suggests, Node-RED is an easy way to implement it.
Using the Mosquitto Broker and Node-RED on an RPi4 along with the PAC Read and PAC Write nodes supplied by Opto22 for Node-RED, I am able to pass messages using MQTT. Operational reliability is excellent.
I will add to the recommendation to try it out with Node-RED. I haven’t been using the built-in MQTT functionality of the PR1 and RIO because we want to rate limit the publishing on time and delta change of value to minimize data consumption and we also are reading and writing data to the memory map. Node-RED has been great for this.
I can certainly try out the Node Red path for getting data to the strategy. I liked the easy option for RBE filters to minimize data as well. I was a just a little leary on the reliability and scalability of using it if there was a way already built into the EPIC. If I wanted to update add writes to 100+ points in the strategy, it seemed like a lot of hardcoding on the Node Red side.
So as it seems, it sounds like the MQTT function on the EPIC is to ‘publish only’ via the Public variables. Is this true? There’s the ‘Allow write access’ box in PAC as well, which is sort of what prompted the question.
If that doesn’t apply to the MQTT at all, then I’ll move ahead with testing some Node Red.
If you use the built-in SparkplugB, you can write as well.
In your web app you could provide the variable name, variable data type and value in your MQTT payload and parse this in Node-RED and then feed to the PAC Write nodes (one for each data type you need).
Your flow will have a MQTT subscribe node listening on a “write” topic that your app will publish to. Then parse the payload (JSON makes it easy), run a switch node on the variable data type (since you can’t feed the variables data type dynamically to the PAC Write node (Why @Beno?). Then the switch node will feed to each of the PAC write nodes for each data type you need to support with a payload like this:
msg.payload = {
tagName : "onSwitch",
value : parsed.value
};
The PAC Write node will need the value set to msg.payload.value to pick up the value that is passed in.
Sort of.
I love Node-RED, don’t get me wrong, but in this application (which I may not be following your brief description of) I am not sure its the best hammer in the tool-box.
Exactly, so lets take a look at that…
Whats going on here, what does writable mean exactly here?
When you check the first ‘Make Public’ box, it adds this variable to a kind of ‘hidden table’ inside the controller.
That table is used in two places, REST and MQTT.
So we now can make RESTful calls to this variable name and get its value back from that RESTful call.
In the case of MQTT it means that if the variable changes (alas @philip , analog no dead band in PAC Control yet) it will be published out its topic.
Hang on… what topic?
Jump into groov Manage with me…
Going from top to bottom, we setup the topic name space and broker, then we get to the device.
Click on the device…
When we click on the device, we see we have two options, MMP or Controller.
Each means just what they say…
So if we select Controller, then all those ‘Make Public’ tags in that hidden table will be published on change on the topic namespace we have setup in groov Manage, using the tag name in PAC Control as the final name.
Ok, so thats publish, but whats the ‘Allow Write’?
Well in the case of REST, we can give the API permission (with the right authentication) to write to the tag name and change its value in PAC Control.
What about MQTT…?? Well, it means that this tag will also listen to the broker for any changes to its topic name space… and remember, the PAC Control tag is part of that name space…
So, what that means is that yes, in regard to the native (groov Manage) MQTT client in EPIC, you can in fact subscribe to tags on the broker… The bit you just need to get clear, is that you can only subscribe to the same tag names… So no MQTT wildcard tags for example.
Thus, if you set things up right in your web app, you can publish to the broker the topic name space that matches the strategy tag names and thus you can have subscribe only MQTT tags that will subscribe to themselves all day long and your strategy can use those values how ever you see fit.
@sengsberg Do let us know if that changes things up a bit for you.
Thanks @Beno and @philip. I appreciate the help. My initial goal was to have a UI done in React, Flutter or some other JS framework that could effectively send commands down to the EPIC. The REST API was certainly a way to handle it, but I wanted to proof MQTT in my spare time since I could also easily integrate a time-series database like Influx or other systems. That said, Node Red plays really nice with Influx so it isn’t too much of a benefit compared to that.
Regarding string payloads, I’ve got them publishing to the broker. Using MQTT FX as a client tool, I can publish to the same topic (i.e. topic is “myBase/DemoGroup/DemoNode/epicLCSIM/Strategy/Numeric Variables/randomScale” , payload of “10”), but the PAC Control tag doesn’t get updated unfortunately.
So I tried it with SparkplugB. There were some issues connecting to a broker using Sparkplug payloads on EPIC firmware 3.3.0 (only sent out death messages to the broker, MQTT logs showed it switching between connection/disconnection)
I upgraded to the latest firmware and it fixed the EPIC’s publishing issue, but trying to post using a matching tag name presents other issues. The first underlying issue is publishing from a client using of the three clients I downloaded, none did SparkplugB publishing formats.
The second issue is identifying the specific topic I should post to. All the data goes to the same topic of (spBv1.0/DemoGroup/DDATA/DemoNode/epicLCSIM) which an aggregate of tag changes. After looking at the birth payload, I tried to imply some tags that might be correct to write to. (ex: spBv1.0/DemoGroup/DDATA/DemoNode/epicLCSIM/Strategy/Numeric Variables/randomScale). At this point, it’s unclear whether the publish fails from not being sparkplug syntax or from not being on the right topic that the EPIC is subscribed to.
The MQTT Logs haven’t been been particularly helpful, but I’ve looked at them a bit too.
At any rate, I think using the REST API might be a bit more intuitive to get rolling with at this point.
To use Sparkplug B you will want to use a library that supports it. There is too much going on to effectively roll your own. Also as you found, the string payloads are only published, the EPIC does not subscribe to any topics to get any writes. Without Sparkplug B on the web app side, Node-RED is the way to go where you can create your own payload- it is actually pretty simple to do and that is why many of us have recommended it.
On your web app, what are you using for the back end? Are you planning on doing the REST and/or MQTT direct from the browser? For MQTT, you will need to use a broker that supports web sockets. If you use REST calls from the browser to the EPIC, I would be concerned about the number of connections to the EPIC if you have a lot of users (especially since you will be doing polling with REST). MQTT brokers are more tolerant of a lot of connections and will be more bandwidth friendly since they don’t require polling. If you have a back end server handling the EPIC connection side, then those concerns are mitigated.
Doh! So sorry @sengsberg That is my bad… You don’t write to the same topic namespace because if you did, the tag would change and publish the new value on the same topic which you subscribe to and publish the change … and so you would have an echo race through the broker.
You need to put write in after the base topic.
I just did this example in Node-RED because its easy to see/show. Of course its your web app that has the publish topic in it.
Cool, didn’t know we could write with the string payload.
That’s perfect. Just what I needed to know and got it to work after putting the write after the Base Topic like you mentioned. I thought about the possibility of echo/feedback and this takes that off the table.
@philip Likely a small amount of concurrent users, so it’s kind of a toss-up. Back-end is still a toss up - kind of defining the needs still… If I need a server, I’d would probably use a node.js or python service. I haven’t looked to see if the libraries are useful yet. Flutter has a rough Mqtt library that has to use websockets - which Mosquitto did fine with on my test. It also forces you to either pick between app or browser platform I found, kind of getting rid of one of the better features of the language. Thanks for the advice on connections.
