Closed ymgupta closed 1 year ago
Implementation wise this is not complex. On the NS/AS/IS side we just need to add it to the allowed field mask, and on the IS side we need to add another column to the {gorm|bun}store
.
The question is - do we want to implement this ? My understanding is that serial_number
ended up in EndDeviceVersionIdentifiers
because it is part of the QR code specification, but it does not necessarily have anything to do with the end device version identifiers themselves.
The intent here is to basically inject a form of metadata into the uplink message, and this pushes the sliding window for what we include in the uplink messages. I'm inclined to not implement this.
Any thoughts @johanstokking ?
Honestly I think that we made a mistake by introducing https://github.com/TheThingsNetwork/lorawan-stack/blob/v3.21/api/identifiers.proto#L163-L167 to EndDeviceVersionIdentifiers
. As you say, these aren't version identifiers.
The serial number is metadata of the end device. It should be a toplevel field of EndDevice
, stored in IS. And shouldn't go in upstream messages.
The Vendor and Profile IDs are something typical TR005.
@KrishnaIyer can we deprecate these fields based on progressive insight? The required changes are here: https://github.com/TheThingsNetwork/lorawan-stack/pull/5134/files
Ok I agree indeed, we can deprecate it and add it to EndDevice
. I'll add a quick PR
Summary
While creating the device using APIs, we see that the
version_ids.serial_number
field is ignored. We have included theversion_ids
values (brand_id
,model_id
,serial_number
) in the request body of Identity Server API call and field mask. But, we see that onlybrand_id
, andmodel_id
are stored for the device. The API response doesn't contain theserial_number
field. However, as per the API reference documentation, we see thatserial_number
is part of the version identifiers. And, it is stored in Entity Registry, Network Server and Application Server.Steps to Reproduce
version_ids
as follows:Also, set the following values in the field mask of the API call:
Current Result
brand_id
andmodel_id
are stored successfully for the device with the IS API call, but theserial_number
is ignored.serial_number
.serial_number
in the field mask. Including it in the API calls raisesforbidden path
error.Additionally, we don't see the flag to create the
version_ids.serial_number
in CLI as well.Expected Result
The IS, AS and NS should store the
serial_number
value from the API requests.Relevant Logs
Response:
2. Network Server
Request:(Didn't mention the
serial_number
in the field mask as it is not supported in this call)Response:
3. Application Server
Request: (Didn't mention the
serial_number
in the field mask as it is not supported in this call)Response:
4. Join Server
Request:
Response:
URL
No response
Deployment
The Things Stack Cloud
The Things Stack Version
v3.21.0
Client Name and Version
Other Information
Currently, the details such as
brand_id
andmodel_id
are available in theversion_ids
object of uplink messages. They are used to route the messages in the user's application based on those values. However, the user wants to route the messages based on theserial_number
value as well.Ref: https://github.com/TheThingsIndustries/lorawan-stack-support/issues/821
Proposed Fix
No response
Contributing
Code of Conduct