Error processing edit for tag path - MQTT Engine

gabosm · October 31, 2025, 6:11pm

Hello,

I am running into a strange issue or bug that has completely taking down my Ignition MQTT integration, and I’m unsure of what is causing this or how to resolve it:

The logs identify the following error: Error processing edit for tag path '[MQTT Engine]teletest/application/26cff63b-1b2c-429b-8210-fc3985035143/device/74fe48ffff8b3d45/event/up/vib_sensor_01_tag/object/payload/Accelerometer/Z-Axis/Deviation': Bad_Unsupported("The target path '[MQTT Engine]teletest/application/26cff63b-1b2c-429b-8210-fc3985035143/device/74fe48ffff8b3d45/event/up/vib_sensor_01_tag/object/payload/Accelerometer/Z-Axis' cannot accept children tags.")

Previous to this, all MQTT integrations where working great and there have been no changes made to any settings - This issue occurred after doing some field testing where I would walk with the end-device sensor as far as possible until it dropped out of LoRaWAN range. When the sensor was back in range and re-connected to the LoRaWAN gateway, the error described above started being produced on every MQTT tag ONLY within Ignition.

Some background:

-I have confirmed that the LoRaWAN end device (in this case, a WISE-2410 vibration sensor) is working and happily reconnected to the gateway (SenseCAP M2). All LoRa frames are being transmitted via MQTT, and these are seen coming into my other integrations (Node-Red, Grafana).

-Because this is not a Sparkplug compliant device or gateway, I have set up a Custom Namespace within Ignitions MQTT Engine for the vibration sensor. The custom namespace subscribes to the MQTT topic being published by my broker (Mosquitto). This is being placed in the Root Folder called “teletest” and the MQTT topic is “application/26cff63b-1b2c-429b-8210-fc3985035143/#”.

-Directly accessing MQTT tags within Designer is quite cumbersome when using a Custom Namespace, because the tags are automatically added to the “teletest” folder which is buried under the “MQTT Engine” tree, and the topic string is quite long. You also can’t add MQTT tags to the UDT section easily, in the same way you would with lets say a device driver and the OPC UA server. This resulted in me creating a few custom UDT definitions that indirectly referenced the MQTT tags I need to work with in my project - I’m wondering if this is the right approach to handling MQTT tags produced by the MQTT engine, and if this is what might be causing the issue. The error seems to identify a problem with a child tag (Z-Axis/Deviation) associated to the Z-Axis tag, but I haven't actually used or referenced that /Deviation child tag anywhere.

-I’m running Ignition Version 8.3.0 on Ubuntu Desktop 24.04.3 LTS, and the following MQTT Modules:

-MQTT Distributor - 5.0

-MQTT Engine - 5.0

-MQTT Transmission - 5.0

-MQTT Recorder - 5.0

Any help or thoughts on this subject is greatly appreciated. The Ignition environment was running extremely well up until this point, with all components of the system being powered on/off several times.

gabosm · November 2, 2025, 6:25pm

I ended up getting things working again by deleting the Custom Namespace entry. In order to do this, I had to first delete all UDT tags references, along with the namespace root folder that the MQTT Engine creates. This time while configuring the new namespace, I have narrowed the scope of the subscription to “application/26cff63b-1b2c-429b-8210-fc3985035143/device/+/event/up” which should only return the uplink payload data. With the previous scope “application/26cff63b-1b2c-429b-8210-fc3985035143/#” it would return every piece of MQTT data in the application, including downlink data, which likely resulted in different or overwritten tags when a device goes out of range and then reconnects.

This post helped provide some insight: MQTT Publish Error - #7 by wes0johnson

gabosm · November 3, 2025, 6:50pm

Unfortunately I’m back to the same errors today, even after narrowing the scope of the MQTT subscription. Does anyone have any further suggestions on this topic? This error seems to be a result of how the MQTT Engine handles and automatically creates tags within Ignition. When the system is rebooted, or an end device loses connection and reconnects, all tags stop working until the namespace root folder is deleted.

pturmel · November 3, 2025, 7:17pm

Perhaps you should open a support ticket with Cirrus Link.

gabosm · November 3, 2025, 7:23pm

Thanks for the suggestion. I have attempted this last week, but it seems their forums and support channels put your account on hold immediately.

pturmel · November 3, 2025, 7:30pm

Hmmm. @wes0johnson ?

wes0johnson · November 3, 2025, 7:54pm

The error you were getting in the original post was this:

Error processing edit for tag path '[MQTT Engine]teletest/application/26cff63b-1b2c-429b-8210-fc3985035143/device/74fe48ffff8b3d45/event/up/vib_sensor_01_tag/object/payload/Accelerometer/Z-Axis/Deviation': Bad_Unsupported("The target path '[MQTT Engine]teletest/application/26cff63b-1b2c-429b-8210-fc3985035143/device/74fe48ffff8b3d45/event/up/vib_sensor_01_tag/object/payload/Accelerometer/Z-Axis' cannot accept children tags.")

When using a custom namespace, this typically indicates the structure is changing in such a way that what was originally created as a leaf tag is now expected to be a folder. If this can not be adjusted via the publisher, a custom parser is typically required. You can uncheck this option in the custom namespace:

This means the json payload will now arrive in a single String tag. You can then create a tag change script to deal with the payload as you need and make sure to account for the changing structure.

Also, @gabosm - you should have proper access to the Cirrus Link forum now: https://forum.cirrus-link.com

gabosm · November 3, 2025, 9:50pm

Thanks very much for your response, Wes. This gives me a much better understanding of what is going on. Looking at the JSON Payload of the MQTT message in Node-Red, the structure has indeed changed, although no new tags have been added.

What I will do here rather than trying to create individual tag change scrips in Ignition, is parse the data again in Node-Red and then re-send it.

I will report back in a couple of days.

gabosm · November 5, 2025, 3:39pm

The solution that ended up working best for me was using Node-Red to format the data for a second time, and then sending it back to Ignition via MQTT. Node-Red is able to deal with the randomly changing JSON tag structure, which appears to be a result of the LoRaWAN payload decoder provided by the manufacturer. I’m not about to re-write the payload decoders, and this situation occurs with every LoRaWAN device I’ve used so far (for example when a device loses connection to a gateway and then reconnects - the payload and tag structure will change). Here is the Node-Red java function script I created to deal with the changing structures:

[
    {
        "id": "fb8c5f2e8a66aca5",
        "type": "function",
        "z": "b9364f642836f7c6",
        "name": "payload structure - MQTT",
        "func": "\nmsg.payload = {\n    name: \"Vibration Sensor 01\",\n    temp: Number(msg.payload.object.payload.TempHumi.SenVal.toFixed(2)),\n    battery: Number(msg.payload.object.payload.Device.BatteryVolt.toFixed(3)),\n    time: Number(msg.payload.object.payload.Device.Time.toFixed(1)),\n    event: Number(msg.payload.object.payload.Device.Events.toFixed(1)),\n    x_axis: {\n        crest_factor: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].CrestFactor.toFixed(2)),\n        deviation: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].Deviation.toFixed(1)),\n        kurtosis: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].Kurtosis.toFixed(2)),\n        oa_velocity: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].OAVelocity.toFixed(2)),\n        peakmg: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].Peakmg.toFixed(3)),\n        p2pd: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"][\"Peak-to-Peak Displacement\"].toFixed(1)),\n        rmsmg: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].RMSmg.toFixed(3)),\n        skewness: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].Skewness.toFixed(2)),\n        senevent: Number(msg.payload.object.payload.Accelerometer[\"X-Axis\"].SenEvent.toFixed(1)),\n             },\n    y_axis: {\n        crest_factor: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].CrestFactor.toFixed(2)),\n        deviation: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].Deviation.toFixed(1)),\n        kurtosis: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].Kurtosis.toFixed(2)),\n        oa_velocity: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].OAVelocity.toFixed(2)),\n        peakmg: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].Peakmg.toFixed(3)),\n        p2pd: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"][\"Peak-to-Peak Displacement\"].toFixed(1)),\n        rmsmg: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].RMSmg.toFixed(3)),\n        skewness: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].Skewness.toFixed(2)),\n        senevent: Number(msg.payload.object.payload.Accelerometer[\"Y-Axis\"].SenEvent.toFixed(1)),\n             },\n    z_axis: {\n        crest_factor: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].CrestFactor.toFixed(2)),\n        deviation: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].Deviation.toFixed(1)),\n        kurtosis: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].Kurtosis.toFixed(2)),\n        oa_velocity: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].OAVelocity.toFixed(2)),\n        peakmg: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].Peakmg.toFixed(3)),\n        p2pd: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"][\"Peak-to-Peak Displacement\"].toFixed(1)),\n        rmsmg: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].RMSmg.toFixed(3)),\n        skewness: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].Skewness.toFixed(2)),\n        senevent: Number(msg.payload.object.payload.Accelerometer[\"Z-Axis\"].SenEvent.toFixed(1)),\n             }\n        }\n\nreturn msg;\n",
        "outputs": 1,
        "timeout": "",
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 770,
        "y": 340,
        "wires": [
            [
                "d00b8a2a7bceb12a"
            ]
        ]
    }
]