MQTT AppEUI

[ymkins]

Hi Brocaar
After the "Update MQTT handler so that it uses name of app and node" 249fe86 change it's harder to deploy configuration when a few existing applications are subscribed to own topics for data in particular formats. And there are no more AppEUI even in payload.

So, could you please add AppEUI info. For example, as field in payload.

[ymkins]

It's seems too overhead to call the API for obtain the AppEUI on every RX packet.
So, I propose put the AppEUI in topic as: application/[applicationID]/app/[appEUI]/node/[devEUI]/rx.
It allows create simple handlers for parsing different data formats.
Makes sense?

[brocaar]

Hi @ymkins I think there has been some misunderstanding what the AppEUI actually means (I think the LoRaWAN specs was not really clear on this in previous versions).

Latest specs (1.0.2):

19 6.1.2 Application identifier (AppEUI)
20 The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies
21 the entity able to process the JoinReq frame.
22 The AppEUI is stored in the end-device before the activation procedure is executed.

So it shouldn't be used to distinguish the payload format that you're using. E.g. two different AppEUI values could still have the same purpose (e.g. sensing the temperature). Also, two equal AppEUI values could do something completely different (as they will probably be bound to a vendor). When you have control over the node, you could of course use the AppEUI to define which payload should be handled how.

Therefore the ApplicationID was introduced, so that you can define which nodes are serving which purpose.

[ymkins]

Well, I agree with that two equal AppEUI values could do something completely different, as we can't control vendors).

I saw in the "Update MQTT handler so that it uses name of app and node" 249fe86 the "application/[applicationName]/node/[nodeName]/rx" schema. But in the "Update docs and changelog. Add app description in migration" 2b05632 there is the "application/[applicationID]/node/[devEUI]/rx" schema.

The ApplicationID depends on the registration process. It can be troubled to have the same ApplicationIDs on different environments.
@brocaar, what about ApplicationName?

[brocaar]

Yes, the initial approach was to use names for both the application and node. However, the issue is that these names are mutable (thus can break any integration you made), where using the ApplicationID and devEUI are static. You can still change the names of your applications and nodes without breaking any integrations.

[ymkins]

So, if we want provide integrations with the consistent ApplicationID on different environments, we can change the starting value of the id sequence in DB on deployment.
Something like ALTER SEQUENCE application_id_seq RESTART WITH 10000;
It allows consistent static values for applications with deferred registering.
Thanks.

[ymkins]

Another option to have reserved ids after deployment, just create with API few application records for future using.

[ymkins]

So, no more sense to have ApplicationName and NodeName with restricted values because of ApplicationDescription and NodeDescription. Isn't it?