MQTT AppEUI about chirpstack-application-server HOT 7 CLOSED

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?

from chirpstack-application-server.

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.

from chirpstack-application-server.

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?

from chirpstack-application-server.

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.

from chirpstack-application-server.

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.

from chirpstack-application-server.

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

from chirpstack-application-server.

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

from chirpstack-application-server.