What I do is to have a general MQTT broker on my server, which will be recieving info from your end nodes. Then you can forward all the topics you want to Tago MQTT, where you can set the connection to a general handler device, and then route each message to the real device in Tago.
I have a very similar problem: I have a SeeedSense Device (SenseCAP 4G) that I would like to connect to Tago to send data via MQTT.
However,
the device has a 32 byte limit on the number of characters that can be input
into the password field and the device token generated by Tago.io is 36 bytes, which is too long.
@Freddy Minuzzi, your response above “That is definitely a valid way to circumvent this issue.” suggests there may be other workarounds. Although I can use my own broker on my server as an intermediate, this is exactly the sort of kludge I am moving to Tago to avoid - are there any other options?
We are also currently investigating the possibility of creating custom tokens through the use of profile ids in conjunction with network ids. This would necessitate the modification of the API URL.
Currently, we don’t have a date yet but we intend to have this completed soon.
TagoIO’s public MQTT broker authenticates with Device Tokens as passwords, and we don’t have a near-term plan to change that on the public broker.
If your device cannot accommodate the token length, a practical workaround is to deploy a dedicated MQTT broker via TagoDeploy. This gives you a standalone broker connected to your TagoIO account where you can:
Define your own username/password format (shorter credentials supported).
Optionally use client certificates.
Manage credentials according to your security policies.
We’re also working on two enhancements:
An Restful API to programmatically manage credentials and automate provisioning.
An option to sync Device Tokens with your TagoIO profile as credentials, if you prefer to align with the current public-broker model.