Feature to pass organization ID into MQTT topic

[hallard]

As discussed in this topic would it be possible to add organization ID into the topic to subscribe only to topics belonging to this organization.

May be something like that?

  # MQTT integration backend.
  [application_server.integration.mqtt]
  # Event topic template.
  event_topic_template="organization/{{ .OrganizationID }}/device/{{ .DevEUI }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="organization/{{ .OrganizationID }}/device/{{ .DevEUI }}/command/{{ .CommandType }}"

and of course still have application if needed

  # MQTT integration backend.
  [application_server.integration.mqtt]
  # Event topic template.
  event_topic_template="organization/{{ .OrganizationID }}/application/{{ .ApplicationID }}/device/{{ .DevEUI }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="organization/{{ .OrganizationID }}/application/{{ .ApplicationID }}/device/{{ .DevEUI }}/command/{{ .CommandType }}"

Anyway, another option could be to have tag or variable to application that will be pass into json, like that we could filter by tags other side, don't know which one is simpler to you.

[liangyuanpeng]

We can keep the application level topic by default, and support {{ .OrganizationID }} for template.

@brocaar What do you think?

I want to try it if possible.

[brocaar]

I'm planning to do a bit refactoring on this configuration soon, to align it with the topic_prefix, which is used in other configuration parts (ChirpStack v4). Then I will also look at this item.

[djairhogeuens]

I suppose the organization ID being referenced here is the tenant ID in v4?

Next to being able to use the tenant ID, it would also be useful to have the following parameters available:

• Tenant name
• Application name
• Device name

in order to be able to control the topic through the configuration. For example, I want to integrate with an existing tenant on my external MQTT broker and I can't control the tenant ID or application ID as these are automatically generated so there's no way for me to publish to the topic of my existing broker tenant.

Has there been any progress on enabling this? If not, any suggestion on the implementation approach so we can consider contributing? We're new with the project and not experienced with Rust.

[bconway]

With that amount of logic, you may be better off writing a slim service to consume MQTT data, convert it as needed for your use case, and then forward it on.

[djairhogeuens]

I'm not sure where the additional logic is in what I would like to achieve. I'm just trying to adhere to existing topic naming conventions. All data is available in ChirpStack on the same objects as other fields that can already be used in the topic templates (application ID and device EUID). The template rendering engine has just been hardcoded to only support these fields and not others. Some more flexibility sounds like a good improvement to me.

Specifically in my case, if I could use the application name instead of its ID I would already be helped. The other field suggestions just seemed appropriate to also be supported.

While a topic translation layer could indeed also realize what I want, it would introduce an additional potential point of failure in the chain and would thus require additional monitoring. Improving the flexibility of the topic template rendering engine therefore seems like a nicer solution.

[brocaar]

Please note that other than the identifiers (UUID / EUIs), there is no guarantee that these fields are valid for MQTT topic usage.

[djairhogeuens]

Indeed. That would be the responsibility of the configurator to ensure that proper governance is in place for admins/provisioning when using these fields in the templates.