Hello,
so I was reading the MQTT documentation and if I get this right I can also use it to publish generic payloads from devices outside Losant.
Now I am having trouble publishing generic payloads (it cannot even connect with a standard MQTT library) so I am wondering … does the client_id is still validated? e.g. do I have to create a bogus device and the use that client_id in the MQTT authentication even for generic payloads?
Cheers.
I can actually confirm this is the case because when I change the clientid to a a custom string the connection is refused.
This should be at least described in the documentation.
We do mention here that authenticating against the broker requires providing a device ID as the client ID. Where were you looking so that I can get that noted in the same spot?
And to answer your question, yes, you’ll need to create a device in Losant to serve as the client. We have talked about allowing for arbitrary connections using the application as the client (or setting your own client ID) but we do not have any timelines for when that would be implemented.
You can also use our REST API to subscribe to an MQTT topic as an SSE stream or publish a message on a topic if that works for your use case.
Yes I know that but I assumed that since the device doesn’t exist because is external, the client_id wouldn’t apply in that case. Maybe you can reference that in the paragraph called Custom Topics like “you do still need to create a device for this to work etc etc”.
Oh nice, I guess this will be useful if I want to transform and display those messages in real time in a UI component (experiences)?
For security reasons, I wouldn’t recommend accessing the Losant REST API directly through client-side JavaScript on an experience page. This is because you’d have to expose an API token client-side, which means anyone viewing the page can obtain the token.
To do this securely, the client-side JavaScript can make requests to an Experience Endpoint, which in turn can access the Losant REST API. This extra layer gives you an opportunity to verify the user has access to do whatever they’re about to do.
We’ve also added Streaming Endpoints, which are specifically designed to securely allow experience pages to subscribe to MQTT topics through SSE streams. The client-side JavaScript can make an SSE connection to an Experience Endpoint, which in turn replies with an SSE stream. Just like before, this gives you an opportunity to verify the request before replying.