After some further digging, I believe the issue lies with the way my 3rd party gateway is formatting the MQTT payload. It is not declaring ‘data’ as an object.
If the payload is formatted like so (using a manual MQTT client): {"data":{"mac": "00:0b:57:1c:3b:8a", "rssi": -30, "adv": "020106020a080f094b656774726f6e20314333423841", "scan": "1effffff49ef2331056501534e380000000000000000000000000000000000"}}
…then things work OK. While I understand why this is happening, the challenge will be implementing a fix given the gateway is an existing, legacy component.
Any chance Losant could accommodate the payload data in the form from the original post?
There is a way to work around this using a workflow. First, create a workflow using the MQTT trigger where you will want to choose the Losant Broker as your broker, and then set the topic. Next, add a node to parse your message because it will come in as a string on the payload. Finally, add a Device State Node to set the MQTT data as your device state data.
Are there any gotchas or other concerns (e.g. with device management, etc.) by using this workaround vs. the conventional device attribute configuration method? Just trying to assess if I need to push the gateway vendor hard to bring them inline with your conventional format.
Should others try this, be aware that you can’t use the same topic format as you would normally use for devices (e.g. losant/DEV_ID/state). The MQTT Trigger node requires that the topic does not use ‘losant’ in the name.
