I’m trying to configure and mqtt pub/sub integration but I always (tried 2 different brokers) get the following error.
What does it means?
These kind of Pub/Sub integrations are disabled on the deployment you’re using. While these integrations do work on small deployments, they don’t scale well (or reliably) on large deployments, which is why large deployments often disable them.
When disabled, the integrations should be hidden from the Console as well to prevent confusion. We’ll work on fixing that.
Thanks @htdvisser
So, there will be no pub/sub integration in The Things Network Community v3 (https://eu1.cloud.thethings.network)?
No, The Things Stack (in this configuration) will not publish/subscribe to an external broker. The Things Stack still exposes its own MQTT server if you want to subscribe to that from a client.
The most scalable and reliable way to integrate The Things Stack with external platforms is to use webhooks.
Thank you @htdvisser
Webhooks are nice, but the decision of moving the downlink api key to the header will break some integrations, like the ThingsBoard Community one.
It would be nice to have the api key in the body of the webhook.
I’m not sure how the ThingsBoard integration works. I think @snejra knows more about that one.
1 Like
Ok I’ll wait.
The problem with ThingsBoard is that you don’t have access to the header of the request; just the body and with a very tight format
At this point, ThingsBoard integration in V3 is implemented only via MQTT, not Webhooks → did you take a look at our documentation?
1 Like
Thanks @snejra
It’s a pity that the ThingsBoard Community Edition (not Professional) are left behind.
We will find a alternative
@htdvisser, not fully clear on this …
V3 TTN Stack - no MQTT, use Web Hooks.
V3 self hosted / TTI / AWS Stack - yes to MQTT but recommend Web Hooks.
Not clear to me as well.
Do you mean there is no MQTT support for The Things Network V3 for customer applications at all, or MQTT not available for integrations with other service providers like ThingsBoard?
No. There is an MQTT broker where you can subscribe for your messages just like there was in V2. For TTI implementations of V3 there is an option to have the stack connect to an external MQTT broker as a client to publish uplinks (and receive downlinks). That functionality is not available in the community stack because it does not scale (backend would potentially have to subscribe to thousands of mqtt brokers)
1 Like
OK, I’ll paraphrase so I’m clear and hopefully it will give a different take for others:
I can run a client to subscribe to topics on TTN V3 to get uplinks and other things, just like we do now.
If I pay for a TTI V3 instance or run my own, I can setup the stack to subscribe as a client to my MQTT server so I can publish downlink requests rather than use web hooks / API. This connection can also be used for the stack to publish uplinks to my MQTT server if I want, saving on having a client somewhere else receiving uplinks.
In all deployments:
- The Things Stack can send and receive Webhooks
- this is preferred
- The Things Stack can act as an MQTT server, allowing connections from MQTT clients
- this is similar to what v2 had
In some deployments:
- The Things Stack can act as an MQTT Client, connecting to an external MQTT server
- this does not scale on multi-instance deployments, so is typically disabled on large networks
- The Things Stack can act as a NATS Client, connecting to an external NATS server
- this is expensive to scale on multi-instance deployments, so is typically disabled on shared networks, including The Things Network
3 Likes
Very good - please try not to upset our Chi by adding more options.
And please please don’t ever say this in public / earshot of TTN until after the migration - every extra option doubles the muddle!
Love your work, it will come good, but from down here it’s going to take a bit of thinking to figure out a game plan.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.