[SOLVED] MQTT subscription data differing by organizational token

Ubidots API
,
1

I have gotten everything to work successfully, publish and subscribe over MQTT (TLS and plain), using my main as well as organization tokens, when working direct from a client.

What I need to do is setup an MQTT broker for our device LANs. I’m using Mosquitto. I’ve gotten this to work perfectly when using my default token.

However, when I create organizational tokens, the data is able to be published and subscribed via industrial.api.ubidots.com just fine. On the broker, I only see the data subscribed to when using the default token, not the organizational token.

Checking Ubidots directly with either token works:

$ mosquitto_sub -h industrial.api.ubidots.com -t /v1.6/devices/fin3/health.uptime -v -u <default or org token> -C 1

/v1.6/devices/fin3/health.uptime {"value": 1.0, "timestamp": 1566432993932, "context": {"text": "1 week, 6 days, 17 hours, 7 minutes"}, "created_at": 1566432994962, "id": "5d5ddee293f3c307c31220c2"}

At my local broker, using the default token for its connection to Ubidots mirrors everything in realtime, but using the organizational token on the broker outputs nothing.

I’ve tried both using an existing device that I assigned to the organization, as well as a new device assigned to the organization but created from the client using the organizational token.

2

I have tracked this down to the difference (in my bridge configuration, but also in general subscriptions) between:

/v1/devices/+/+

and

/v1/devices/<device name>/+

The +/+ version doesn’t work directly at industrial.api.ubidots.com either way, so thus isn’t propagated to my local broker.

If I specify the device name manually in the subscription or bridge config, things come down properly.

Should I ever be able to use the topic /v1.6/devices/+/+ and have it be scoped to the current token’s permissions? Or should this never return anything, despite being valid MQTT?

3

To clarify:

  • Using the default token allows subscriptions to /v1.6/devices/+/+ to return data.

  • Using an organizational token only allows subscriptions to /v1.6/devices/<device name>/+ to return data (for organization devices).

This is for a regular client or for a bridging broker.

Is this intentional behavior?

4

Greetings, organizational tokens are allowed only to retrieve data to device-label based topics, while your default token may access to any available topic at your account.

All the best

5

Could this be documented for future users? It seems like an MQTT wildcard (+ or #) should work as expected and should be documented if that is not the case.

Thanks for the clarification!