Remove deviceId prefix from publish topics

[coderbyheart]

For every published MQTT message we are needlessly duplicating the client id, which is 15 bytes if IMEI is used, because it is the MQTT client ID AND part of the topic name.

In the firmware we are prefixing MQTT topics with the device id, however this is not neccessary: the device id can be inferred from the TLS certificate or the MQTT client id.

AWS IoT MQTT when connecting using certificate ${iot:Certificate.Subject.CommonName}, and the common name of our certificates contains the device id. It also provides the MQTT client id in the clientid() SQL function.

Both sources can be used to identify the device, given that the device is only allowed to use its IMEI as the MQTT client ID. However this is a requirement for secure IoT deployments: a device must only be able to connect and write to its own digital twin, never other digital twins. On AWS IoT this is enforced through the iot:Connection.Thing.IsAttached policy variable, which we use: it requires that the certificate used to connect is attached to an AWS IoT thing, and then forces the client id for the policy context evaluation to the ID of the AWS IoT thing.

Therefore we can remove the device id in the publish topics.

This could even include the AWS IoT MQTT shadow topics, they also required the device ID in them ($aws/things/thingName/shadow), however we can allow the device to publish to shadow/... and republish these messages under the correct shadow topic, inferring the device id from the connection. This can be solved with a IoT rule.

Affected topics:

• <deviceId>/messages → messages
• <deviceId>/batch → batch
• <deviceId>/ncellmeas → ncellmeas
• <deviceId>/pgps/get → pgps/get
• <deviceId>/agps/get → agps/get
• $aws/things/<deviceId>/shadow → shadow

Note on subscriptions: Because AWS IoT MQTT has no feature to provide a similar behaviour for subscribing to topics, these topics (<deviceId>/agps, <deviceId>/pgps, and shadow topics) still need to include the device id.

Breaking change

Changing the publish topics is a breaking change, because it affects cloud side policies and rules.

A way to turn this into a non-breaking change would be if it was possible to provide the MQTT topics as KConfig strings with optional placeholder, which would allow the user to configure whether the client id should be included for their MQTT broker, or not.

The user could provide the topic string in variants that suit their needs and the firmware replaces known placeholder (e.g. %IMEI% with the devices IMEI, 352656100391948 in the example below).

• %IMEI%/messages → 352656100391948/messages
• messages/%IMEI% → messages/352656100391948
• messages/%IMEI%/batch → messages/352656100391948/batch
• messages → messages