How would the SXL be implemented in MQTT?

[otterdahl]

What is the best practice to implement the SXL in MQTT?

S0001 (signalgroupstatus):

status/<id>/main/signalgroupstatus as a text field, just like today
status/<id>/main/signalgroupstatus/sg1 as separate characters, one for each signal group. The benefit is that we can handle gaps in the numbering, but it requires many separate updates - one for each signal group.

I believe that the first approach is better, for efficiency.

S0007 (controller switched on)

status/<controller_id>/<intersection_id>/dark_mode/status as boolean
status/<controller_id>/<intersection_id>/dark_mode/source as enum - reason for dark mode.

or is it better to have JSON payload?
status/<controller_id>/<intersection_id>/dark_mode with payload:

{
  "status": true,
  "source": "forced"
}

• Is it better to call status as enabled instead? I might make it easier to understand.

[emiltin]

S0001:
I agree that posting a message for each signal group is inefficient.

It bugs me a bit to use the main component since signal group status is not really related to the main component. Would it be cleaner to have a way to address all components of a particular type? Either to get status updates from them all, or to send a command to them all.

[emiltin]

With the new latest suggestion for topic paths, you can refer to the main component, all signal groups, or a specific signal group:

4a33e/status/tlc/cycle: an empty component path means the main component
4a33e/status/tlc/phase/sg: all components of a specific type
4a33e/status/tlc/phase/sg/6: a specific component

See #6

[emiltin]

I think we should use a single topic path for each status, with all attributes send in the payload:

5f23d/status/tlc/dark with payload {"enabled": true, "source": "forced}

You typically send several attributes together, and having a topic path for each attribute feels bloated and you would need to send multiple messages:

5f23d/status/tlc/dark/enabled with payload true
5f23d/status/tlc/dark/source with payload "forced"

I also suspect there could be issues related ordering if you split it into several messages. For example, which value does the forces source refer to here:

5f23d/status/tlc/dark/enabled with payload true
5f23d/status/tlc/dark/source with payload "forced"
5f23d/status/tlc/dark/enabled with payload false

[emiltin]

On the other hand, using separate paths for each attribute would mean you can send only the attributes that change. If only enabled changed but forced is the same, you don't have to send both. What would be most effective probably depend on the use cases.

Note that MQTT 5 supports topic path alias, where you can replace commonly use topic paths with an integer, to reduce bytes send, see https://www.hivemq.com/blog/mqtt5-essentials-part10-topic-alias/.

Regarding synchronization, we probably need to include a timestamp anyways. We could also consider a form an event id. So not sure it's a blocker, although sending all attributes together in a single mesages seems to make things a lot easier with regard to synchronization.