I’m using the latest version of Ignition and the Cirrus Link MQTT Engine to try to ingest data from an MQTT broker (normal MQTT topics with simple JSON payloads, not Sparkplug B) into Ignition tags.
I created a custom namespace in the MQTT Engine config, with a wildcard subscription. I expected that the MQTT Engine would parse any topics received and convert them to folders/tags, but it only converts one of them.
I can’t imagine that I’d need to create a separate custom namespace for each tag I want to ingest from MQTT - that’d be insane.
There are no entries in the log indicating and problems with parsing topic names. Also, I’ve verified with other MQTT client(s) and the same broker/wildcard subscription that messages are indeed being transmitted successfully. It seems to be a parsing issue with MQTT Engine, but again, no diagnostic information is available that I can see.
Yup. Went through that in depth. Something seems to be failing in MQTT engine but no log messages or other indication why. Any way to turn on tracing or other diagnostics to see how it is processing topic messages?
I put together a little test bench to explore this. I was running into similar problems until I disabled the other namespaces for that MQTT connection. As a habit, I usually disable the built-in namespaces I never use. Then, you can filter out Sparkplug B on a per-server basis if needed.
That said, there might be a deeper issue here, but I figured I’d share this to hopefully get you up and running.
1 Like
Here is the little Docker Compose test bench I used, in the event further study is deemed of interest:
https://www.icloud.com/iclouddrive/09fmJQqHwuttZMsVT0rAJOoqg#forum-59583
It was too big to share directly in the forum due to the included gwbk.
1 Like
Disabled all four of the other namespaces, and same behavior. It connects fine to my MQTT broker, but only creates a single tag based on incoming messages (even though it’s a wildcard subscription).
I tried re-enabling those namespaces, and sure enough I got back into the same state as you–only first JSON payload represented as tags. c.c.m.e.g.j.JsonPayloadHandler logger set to trace also not showing parsing for any other of the published topics (for new messages, not just the retained ones presented on initial connection). So it almost seems like the subscription isn’t setup right.
Also noticing a very long delay (almost a minute) in saving the changes to the namespace configuration through the GW web UI…
However, after disabling those namespaces again, everything seems to be coming through… Oddly enough, I was getting this error upon connection, prior (though not repeatedly when switching on/off Sparkplug B namespace):
forum-59583-gateway1-1 | jvm 1 | 2022/05/15 18:59:07 | E [c.c.c.m.c.CirrusClient ] [18:59:07]: ME-57e34609-15ad-42c6: on connection to Mosquitto - Failed to subscribe on topic spBv1.0/# with QoS=0
When you reset the connection (going into the Server settings and just clicking Save Changes should be enough to have it reconnect), do you see any errors in the logger related to failed subscriptions? I’ve connected to brokers in the past that seem to reject certain subscriptions and cause problems in initialization of MQTT Engine (thus my habits of being very explicit on enabled namespaces).
2 Likes
One other note that I can offer is that enabling DEBUG on c.c.c.m.c.CirrusClient logger will show you the subscriptions Engine is attempting to setup for each connection. Might help in troubleshooting.
Thanks Kevin. Where can I make that logger configuration change?
So I disabled the other namespaces, shutdown Ignition completely, restarted, and voila! It’s working as expected. Clearly there’s a bug in MQTT Engine related to having the other namespaces enabled. Honestly I think they should ALL be disabled by default.
It’s still a bug I’d think - having those other namespaces enabled or disabled shouldn’t really affect the behavior of the custom namespace.
I spoke too soon - for a test I deleted the automatically created tags, and restarted Ignition, and the same error behavior returned (just creating a single tag).
You can adjust the logger levels from Status -> Diagnostics -> Logs section:
For this situation it is probably sufficient to just adjust them after gateway startup. If you want to persist those log level changes, edit the ${IGNITION_INSTALL_LOCATION}/data/logback.xml and add a <logger> element (details here):
For the benefit of further potential debugging, can you share the Ignition version you're using as well as the version of the MQTT Engine module you've installed?
Using 8.1.17 and downloaded the version of MQTT Engine compatible with 8.1.16 since it didn’t show up as compatible with 8.1.17.
With all of the other namespaces disabled (by explicitly disabling them) it started up fine this morning.
Is it possible for you to supply the exact topics and payloads your testing with?
Hi, Wes.
I could do one better and put this on an open public MQTT broker if you’d like. Nothing secret in there.
Rick
Sure - if you do that I can take a look.
OK - they’re up there now at broker.hivemq.com. Subscribe to TwinThread/# - all topics are retained so you’ll get a message for each.
