Stop using MQTT integration by default on each application

ChirpStack (v4) Setup and configuration
1

Hello,

I would like to stop using MQTT integration by default in every application. And be able to use different MQTT servers to send the forwarded data using the MQTT integration. Like the HTTP integration is working, but with MQTT the problem is only appears “Generate certificates” and I can’t delete it or edit.

I have also tried to remove “mqtt” string from ‘Enabled integrations (global)’ inside chirpstack.toml.

Am I doing anything wrong? If this feature isn’t available, I think it would be a great addition for people that want to send each application to a different broker for example.

Thanks for your support!

Adrián

2

This is a pretty common point of confusion, I feel Chirpstack could do a better job of explaining/labelling the MQTT integration.

To enable what you are thinking as the MQTT integration, to forward events to a remote broker, all you have to do is change the “server=” line in your [integraion.mqtt] section of the chirpstack.toml to the details of your remote broker. This will forward all “integration” events from all applications to the third party broker. I believe if you needed to forward to a separate server per application you would have to create your own middle man to do that.

The “MQTT integration” through the UI that says “generate certificate” is in fact not an integration to forward data out. ALL that that does is sign a certificate you can use to connect to the MQTT Broker if you have already enabled TLS on your broker through this guide: Mosquitto TLS configuration - ChirpStack open-source LoRaWAN® Network Server documentation. After finishing that guide, any external connection (gateways for example) require the certificate generated through the UI to access the MQTT broker, and will only be able to access topics associated with the application the certificate was generated in.

2 Likes
3

First of all, thank you @Liam_Philipp for your explanation. I knew how it worked, but an explanation like this would have been helpful when I started, as it would have allowed me to progress more quickly.

That said, I wonder if it would be very complicated to implement something similar to the HTTP integration. To me, they seem quite similar; you would “just” have to specify a server and have Chirpstack route all messages from each application to the broker defined in the integration.

Currently, through trial and error, I have managed to have the incoming messages go through an MQTT broker (Mosquitto in my case) and then use another broker as an integration (another Mosquitto, but this time on port 1884). I don’t know if I explained myself well, but basically, I use two brokers: the one that Chirpstack uses internally receives the LoraWan messages via MQTT (raw), and once the payloads are decoded, I forward them to another MQTT broker, this time with all the JSON that can be seen in the Events (Up) section of the device.

If I can do this currently and send absolutely everything through the same broker, what additional difficulty would there be in making the forwarding broker per application instead of global? This would give much more granularity in how Chirpstack is used. I also propose that this implicit “integration,” which always sends everything through MQTT, can be disabled. It would be nice to disable it if, for example, I am already sending one of the applications via HTTP.

I hope I have explained myself well.

Thanks,

Adrián

4

To my knowledge it is not built in to send MQTT to different brokers depending on Application. The only way I know to forward MQTT events out is enabling it in the Chirpstack.toml to forward all events regardless of application to a single broker.

I don’t see why you would ever need to forward each application to a separate broker though, since you have the functionality to restrict access to topics through your mosquitto.conf, you could have all of your external applications only retrieve that applications events, which would function the same as each of those external applications having their own broker with only that applications events.

If it were absolutely necessary for you to split the data to a separate broker per application I would recommend just making a middle man to do that. It shouldn’t be difficult to create a script running on your Chirpstack server that forwards the events to different brokers depending on the application.

5

OMG I didn’t know I could restrict topics using mosquitto :cold_face:, do you have an example of this setup? If not, don’t worry, I’ll look for it myself. I think that might solve my problem :slight_smile: (at least part of it). Thanks!

@brocaar Do you think it would still be possible to easily make MQTT integrations not global but per Application? I mean to configure it like HTTP integration, where you have to indicate the server (IP and Port). And as a future proposal, make a kind of filter for topics, all from the interface. Since it would definitely be faster than modifying the mosquitto.conf configuration files or making an intermediate APP that acts as a proxy.

The thing is, I don’t know if my proposal makes sense, but MQTT integration is not by default, but rather you would choose what to send and through where the key would be. Since now, as explained by @Liam_Philipp, I understand that Chirpstack forwards everything that comes to it through the MQTT integration and that this cannot be deactivated for a specific application but for the entire Chirpstack server. Since you can remove it from:

[integration]
 enabled=["mqtt"]

By doing this, what I would expect to happen is what I propose, if it is not activated globally, simply that it appear independently in each application and that it can be configured from them.

For example, it would be very useful for me if I could simply disable the MQTT integration of an application and activate the HTTP integration in exchange. This way I would be sure that EVERYTHING that comes through MQTT I want on that server. This would save me filtering, for example, for each Tennant if in 2 of the 10 applications they have I do not want them to arrive via MQTT but rather via HTTP.

Depending on what you tell me, I can open an issue on Github to propose this new feature. If not, I’ll figure it out some other way.

Thank you all.

Adrián

PS: One last question related to the case, the integration section of the chirpstack-gateway-bridge.toml configuration, what is it for? And what difference does it have with chirpstack.toml?

6

@Liam_Philipp Thanks for your explanation.
So the description for MQTT is misleading / incorrect.

I also think this MQTT integration will push uplink data to another broker too.

image
image989×508 21.3 KB

7

I totally agree. What the user expects and what actually happens can be a bit confusing. I keep thinking it’s a design problem because, to me, all integrations should work the same way and be configurable through the UI. This would open the doors to a lot of new (and less experienced) users.

Yes, it definitively does. I have a setup with 2 brokers, one for Chirpstack internals (configured in the region_XXXX.toml) and the other config files (chirpstack-gateway-bridge.toml) and also in chirpstack.toml I’ve set another broker. For example: mosquitto:1884

8

Hi,
So does it forward events based on the application?
Or just a place for uploading certificate?
Thanks a lot.

9

It forwards all the events of all the chirpstack server. And the button of generate certificate is the only that appears. But each forwarded event has the APP in the Topic and the gateway and I don’t remember but you can change this but always at global level… not on each application. That would be awesome :slight_smile:

1 Like
10

The guide I previously shared to secure your mosquitto broker with self signed certs has an example of restricting by topic. It uses the ACL file to restrict topics depending on the name on the certificate used to connect, that is why you then generate the certificates through a specific application in the UI. You could have it restrict topics however you want through the ACL but you’ll need to look for your own tutorials.

I’m sure Brocaar has a long list of features to work on and this seems relatively niche IMO, although I do think the labelling should be adjusted.

On the Chirpstack documentation page you can find all the options for the .toml configuration files with some descriptions:
https://chirpstack.io/docs/chirpstack-gateway-bridge/configuration.html

3 Likes
11

Thank you very much for your help @Liam_Philipp. I’ll leave this topic open if you don’t mind, to make it more visible to people, since it’s not a “problem” that needs to be solved. It’s more of a discussion, and maybe others will want to participate. I propose leaving the topic open until it closes on its own or an admin does it (or tells me to do it). This way it will serve more people and more new people will be able to participate.

Thanks for everything!

Adrian

12

The issue is that the MQTT integration is always connected to the MQTT broker, where the other integrations that can be configured through the web-interface are adhock HTTP POST requests. Making it possible for end-users to initiate persistent connections from ChirpStack to any MQTT broker could introduce security and performance issues.

1 Like
13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.