MQTT publishing

[Lars_Andersson]

When posting device data via MQTT, and since the ClientID is the DeviceID, can one device publish data to other devices topics?

[Heath]

Hey @Lars_Andersson,

I think I know what you’re asking, but please correct me if I’m wrong.

Connection to the clientID will happen regardless, but if you try to report state to a different deviceID than the clientID, the connection to the clientID will break, and no state will be published.

Please let me know if I’ve interpreted incorrectly, or if you have any further questions.

Thank so much!
Heath

[Lars_Andersson]

I think you understood me correctly.

So there is not another way I could do this?
I’m doing a demo and already have dashboards made using several devices.
But now I want to test another device submitting data in place of several devices. Does it help if I create a gate device that will do this?

[Heath]

Hey @Lars_Andersson,

There are two options based on your use case:

1. You can set up a gateway/peripherals relationship to for your devices. Like you mentioned, the gateway can report state on behalf of your peripherals.
2. You could set up a custom topic to accept state data for all of the devices. You would trigger the custom topic from the broker and include your device information and values in the JSON. You can then add nodes to “route” your workflow and report state for the devices.

If you have any additional information on your use case, please let me know, just in case neither of the above work for you.

Thank you!
Heath

[Lars_Andersson]

So if I go with option 1 and create a new deviceID as a gateway type deice, will I then be able to use the gateway’s deviceID as MQTT client ID and publish data for the other device ID’s as part of the /state topic?

[Heath]

@Lars_Andersson,

Unfortunately, no. To do this, you would need to set up a custom topic as I mentioned above in option 2.

Thanks!
Heath

[Lars_Andersson]

Can you show some screenshots of how I would do that?

[Heath]

Hey @Lars_Andersson!

Below are some screenshots on how you can set a custom MQTT topic and set up a workflow to report state for devices. It is important to note that for this example, the MQTT message included a “devices” array in the message.

First, with an MQTT node, you can set the custom MQTT topic.

Once you’re sending MQTT messages to that topic, you can use a JSON: Decode node to format the string to an Object.

Using a Loop Node, you can loop through all the devices in the “devices” array sent along with the MQTT package.

The Loop Node can then report state to each deviceID listed in the “devices” array.

Here’s the example payload that was used to trigger this workflow.

{
  "devices": [ 
{
"deviceId":"5d35d2ece9bcf1000957fa02",
    "temperature": 72
  },
{
"deviceId":"5dcedf089285680007ea7974",
    "temperature": 40
  } 
] 
}

And, here’s the workflow export:
mqtt-state-ingest-develop.flow (3.2 KB)

Thanks,
Heath

[Lars_Andersson]

I’m trying to change the “additional mqtt topic access” values for an access key assigned to a device.
I selected “Only the following additional topic” and entered “devices” as the topic name, and “Publish” in topic access.

When trying to publish from this device , should I specify topic as : “losant/{{deviceID}}/devices” or something else?

When I try this I see permission errors in the device debug log.

[Aidan_Zebertavage]

@Lars_Andersson,

When granting access to additional MQTT topics, they can only be non-device MQTT topics, and not MQTT system or Losant-specific topics. In your above example, including the word Losant in that path will result in permission errors.

The docs can help explain this a bit more: https://docs.losant.com/applications/access-keys/#additional-mqtt-topics-access

If you are creating a custom topic, you can follow Heath’s workflow example above (option 2), and the topic subscription path in the configuration could be for example: myapplication/{{deviceID}}/devices.

Thanks,
@Aidan_Zebertavage

[Lars_Andersson]

before I received your reply, I tested with just using topic “devices” from the device, and that worked!

What if someone else would use that same topic? Is that possible?
Or is it still tied to the client ID used so that can’t happen?

[Aidan_Zebertavage]

@Lars_Andersson,

Glad you were able to get it working.

In response to your follow up question, the custom topic is scoped only to your application and therefore the client ID associated with your application. So even if another user defined that custom topic, it would only be referencing values within their application.

Thanks,
@Aidan_Zebertavage

[Jose_Cruz]

I’ve seen a couple of threads of this issue, I’ve read them extensively but I’m still having some questions. In my case, the MQTT client and Losant MQTT broker work as long as:

1. MQTT Broker URL is correct (which it is)
2. MQTT path matches (whether device or non-device, depending on access key; which it does)
3. Access Key and Secret are correct (which they are)
4. ClientID matches device clientID (which it does but for just that one device):
   

#4 is my predicament (and what I’m getting at in the threads, seems to be, the same issue) because the client’s MQTT message is/will not just be on that one device but many. How do I solve the clientID for not just this one particular device but for all MQTT device msgs? I know I’m beating a dead here, but is the solution to my case the same as discussed herewith? I want to make sure, before I keep that I’m on the right track…

[Aidan_Zebertavage]

Hi @Jose_Cruz,

As I understand it, your issue stems from using a single MQTT client to report data for multiple devices. While there is not a perfect way to resolve this, I do think we’ve identified a workable solution.

You’ll need to create a custom MQTT topic to report to. Then, in an application workflow, begin with an MQTT Trigger Node with the same MQTT Topic/Path that is configured in your MQTT client - so in your case the topic configured in your MQTT Client should match what is configured in the MQTT Trigger node, which is devices.

With this setup, we need a way to differentiate your devices as they report on the same topic to the Application Workflow. A unique identifier needs to be sent with each device report through your MQTT client, such as a custom unique number that you manage, a serial number, mac address, or something along those lines.

From there, use a Device: Get node and query to Match All Tags, with your key template set to the macId of your devices (or some other unique identifier) - this allows you to make the association between the specific device that is currently reporting data and its deviceID in Losant. Should that device be recognized, you can then set the device state using the Device: State node.

I’ve provided a couple of screenshots below of what this configured workflow would look like.

Hope this helps!
@Aidan_Zebertavage

[Jose_Cruz]

@Aidan_Zebertavage, I got it working including following your advice on ‘matching’ the device to a unique identifier that comes along with the MQTT message. Problem is, Client/Losant broker still expect a ‘ClientID’ as shown above as #4 as part of the MQTT ‘authentication’, which of course belongs ONLY to 1 device in Losant regardless of my unique identifier (i.e. macID-ish). If I don’t provide this specific ClientID, the MQTT message is not even routed. What could I be missing and/or need to do in this case? Thanks,

[Jose_Cruz]

I see more MQTT discussions, including @Alex_Ullrich 's Managing Multiple MQTT CONXs . @Aidan_Zebertavage, @anaptfox mentioned on that post that there will be a “follow up on that feature” - does this mean Losant is ‘working’ on some kind of ‘added’ feature(s) to the current MQTT brokerage, and if so, when can we ‘expect’ +/- an update on it? Thanks!

[anaptfox]

@Jose_Cruz,

Unfortunately, we can’t give exact updates on when new features will be released. However, yes, this is a feature ticket within our system right now.

But, what I can do is, add your +1 to that, and if you have any ideas and expectations, I can provide that input to the product team!

[Jose_Cruz]

Excellent; thanks!