Add function to retrieve names for given data object IDs

[martinjaeger]

This is a key function for the binary protocol mode that is currently still missing.

[b0661]

This is part of a concept I'm currently working on. Maybe it is of interest to you.

Basically the ID<->name translation data is requested by a post to object id 0x17 (instead of a fetch) and provided by a statement such that any device can update it's local translation table.

The problem is that different devices have different translations. In my case this is solved by extending the object path with the device id. Another solution would be to get the device id as part of the translation statement.

Here part of the concept:

Path

Text Mode

Mesh object path:

path = "/" device-id [ "@" user ] "/" object-name [ "/" object-name ]

General object path:

path = object-name [ "/" object-name ]

Binary Mode

Mesh object path - CBOR string (same as text mode):

path = "/" device-id [ "@" user ] "/" object-name [ "/" object-name ]

Mesh object path - CBOR array (device-id: uint, user-id: uint, device-object-id: uint):

path = device-id [ user-id ] device-object-id

General object path - CBOR string (same as text mode):

path = object-name [ "/" object-name ]

Device object path - CBOR uint (device object ID instead of device object path):

path = device-object-id

Translation Table

To use the binary mode ThingSet mesh devices hold a translation table to
translate from object path to object identifier. Most object identifiers are
specific to the device that holds the object. An exception are the fixed object
identifiers in the range 0x10-0x1F and >= 0x8000.

User identifiers are specific to a device, too. The translation table is also
used to translate between user names and user identifiers.

A device holds it's identifier to name mapping in the .name object (ID 0x17).

Whenever there is a translation request by an application or by the mesh stack
and the translation is not available in the translation table the device
requests the translation from the remote device:

• if the ID is given

  bin-post path=(device-id 0x17) cbor-array(ID...)
  bin-statement path=(device-id 0x17) cbor-map(id : name, ...)

• if the name is given

  bin-post path=(device-id 0x17) cbor-array(name...)
  bin-statement path=(device-id 0x17) cbor-map(id : name, ...)

On the reception of the statement any device updates it's translation table if
possible (space available or entries outdated/ unused).

[martinjaeger]

That's very interesting and goes into a similar direction as the URL schema in the esp32-edge-firmware, where you can talk to a device with ID abcd1234 via a GET request to /api/v1/ts/abcd1234/conf, for example.

The topic layout for MQTT should also contain a user name in addition to the device ID, like {user}/{device-id}/tx/{path} for published reports. If an @ should be used for the user name, I would probably add it before the device ID, like in an email address: user@device-id.

Which sort of mesh network are you currently thinking of? Bluetooth mesh? Or more something like a CAN bus, where all messages can also be received by any device?

I like the idea to have a method to trigger broadcasting of a statement. Maybe that could be generalized for all data objects and not only the .name.

[b0661]

Which sort of mesh network are you currently thinking of? Bluetooth mesh? Or more something like a CAN bus, where all messages can also be received by any device?

The current concept looks like this:

The upper controller is an ESP32, the lower is a STM32 derivate. Finally both shall run on Zephyr. It is very similar to your architecture. The gateway is replaced by virtual ports that look like and in fact are mesh instances on one side and are a BT mesh device, a web server, or a terminal/ shell on the other side. They translate between two (or more) worlds.

I am to start with the mesh instance, the SPI hard port and the terminal/ shell virtual port. This is what is most needed in my project.

like {user}/{device-id}/tx/{path} for published reports. If an @ should be used for the user name, I would probably add it before the device ID,

I like to have the '/' as a starting character in text mode to distinguish a mesh object path from a general object path that does not have a starting '/'. This is the reason why also user should not be the first element of the path. Regarding /user@device_id or /device_id@user there is no big difference. The second one looked easier to scan because device_id is always a 64bit (8 byte) value. But you are right, the first one looks more "natural".

In binary mode a mesh object path is characterized by the CBOR type of the path. It is a CBOR-array with two (device-id, object-id) or three (device-id, user-id, object-id) elements.