Hi,
I have a question regarding the mqtt module:
I have two connections to the EMQX broker: Test1 (SM/#) and Test3 (spBv1.0/#). I publish data from Ignition Transmission to Test3, while we use LoRa to publish data to Test1.
On the other ignition side, we have MQTT Engine set up to receive data from both Test1 and Test3. However, I’m having trouble getting both to work together.
If I enable Sparkplug B, I have to remove the custom namespace to receive data from Test3, but this causes an error with Test1. On the other hand, if I disable Sparkplug B and add the namespace (SM/#), I can receive data from Test1, but Test3 stops working.
Here are some screenshots of what I did:
MQTT Engine:
Ignition designer:
MQTT Broker:
Ignition Namespace:
I'm not sure how to solve this problem, but Cirrus Link has their own forum. It's possible that you will be able to find a solution already posted there:
1 Like
On your first screenshot, Test3 is showing as "Not Connected". Does it become connected if you just enable the Sparkplug B namespace?
Maintaining a connection to the MQTT broker is at a lower level to the Sparkplug B protocol. You should be able to connect to all your brokers regardless of which topics are subscribed to.
Check the gateway logs, it might give you more meaningful error messages.
1 Like
Are you on the latest version of the module? They've recently been making some big changes/improvements that are only in the latest version, so wouldn't hurt to make sure you're on the latest just in case.
I don't have time right now, but this evening I'll play with it in a VM I have set up for testing MQTT. I was only testing sparkPlugB, but will test it with a custom namespace at the same time also.
1 Like
Yes, it frequently switches between connecting and not connected states when I enable it.
ME-e67ecb13-ace4-4e69: server Test3 - Failed subscribe on [SM/test, spBv1.0/#] granted QoS [0, 0] != [128, 0]
ME-ab6f5668-904e-4d16: server Test1 - Failed subscribe on [SM/test, spBv1.0/#] granted QoS [0, 0] != [0, 128]
I have 4.0.24 for MQTT Engine and 8.1.43 for ignition
thank you
I suspect the Lora client and the Ignition client have the same client ID (client name) which caused emqx to disconnect the existing client when a new connection is made. Make sure clients have unique names.
1 Like
That should be a rare conflict if defaults are used because Transmission uses random client IDs (unless they're manually configured to use a static client ID).
1 Like
You need to adjust the "Filtered Namespaces" option in the advanced settings of each server connection:
Or, that should do the trick at least. I haven't tried it with sparkplug on one and a custom namespace on the other.
But, I think you would need to put "Sparkplug B" on one server and "New Custom Namespace" on the other.
The hint is the "Failed to subscribe" messages you showed above. It's trying to subscribe to both topics on both servers, and I'm assuming your MQTT ACLs are rejecting that. If MQTT Engine gets a subscription failure, the default behavior is to drop the whole connection and retry.
1 Like
They aren't same and have unique name as well
I also tried using QoS1 for custom name space and QoS0 for sparkplug, but the connection is still erratic.
Did you note that the "Filtered Namespaces" is supposed to be the list of namespaces to disable for that server? So, on the "Test1" connection that is supposed to be receiving LoRa you would put "Sparkplug B" in that box, and on the "Test2" connection that is supposed to be receiving SpB you would put "New Custom Namespace" in that box?
EDIT: Are you still seeing the "Failed subscribe on" errors in the log after changing the namespace? That was definitely previously the cause of your intermittent connections. If you're still getting that and they haven't changed, then you didn't setup the namespace filtering properly.
PS: I drove Saabs for many, many years and liked them a lot. No idea if you have any particular attachment to them, but it made me happy to see Scania in your profile.
1 Like
Thank you so much for your help, Justin Brzozoski. We were finally able to connect both successfully!
P.S. I'm glad to hear that! Scania and Saab work closely together and, in many ways, operate as if they were the same company.
1 Like
