Gateway ID and Gateway Name is not coming when requesting the deviceId context variable
I am setting up a context variable to use the data as tags and attributes of a device. However, the Id and Name of the connected Gateway is not coming in the request.
Request result:
It is noticed that it does not contain the ID and the Name of the Gateway to which the device is connected, that is, the device information is incomplete.
Hi @lucasbtsuchiya,
This is intended behavior. My recommendation would be to add the Gateway Name and Gateway ID as Device Tags to the device since Device Tags are available in Device Context.
Thank you,
Heath
I understand, @Heath!
However, don’t you think that this can cause future problems when the Gateway is changed?
Because I will have to keep changing and updating the information in several places, which can cause inconsistency in the application.
Would you be able to tell me more about what you would be using Gateway Name and ID for in a dashboard?
I can certainly see where this could cause inconsistencies in your application, but with more information about your use case, I might be able to suggest a better path forward.
Thank you,
Heath
I need to list the Gateway that the device is connected to and also make a redirect link to the Dashboads of the Gateway. If the Gateway is replaced in the application, the link will redirect to a non-existent gateway dashboard or a wrong gateway, different from what the device is connected to.
Do you already have a solution for this problem? Recalling that this was already requested 8 months ago.
@lucasbtsuchiya As of now the best solution we have is the one proposed about a month ago.
To elaborate on why this is not an easy addition:
When we first built the feature allowing users to opt in to returning the full device object with dashboard context, we limited what was returned to the device’s:
If we were to begin including additional information - such as the deviceClass, gatewayId, and gatewayName - then we would be returning more info in the context object than users originally opted into. While this is desirable to some, and probably inconsequential to most users, there are some out there who would not welcome these new values being returned and would even consider it a security concern. And even if this information is not being displayed onscreen, it is still being returned in the network response and is thus exposed.
I am filing a feature request to allow for defining more granularly which properties to return for a given device in the context object, but at this time I do not have a timetable for when we will be delivering that.
