Summary:
The console needs an overview page for gateways, complementary to our overview pages for applications and devices. See also #26.
The overview page should contain:
Implicitly, working on the overview will also contain:
Why do we need this?
The overview pages of our entities serve as quick access to the most important information in low click-depth.
What is already there? What do you see now?
The corresponding API endpoints. For reference, an example GET /gateways/{gateway_ids.gateway_id}
response from the gateway registry:
{
"ids": {
"gateway_id": "string",
"eui": "string"
},
"created_at": "2019-03-06T08:55:43.727Z",
"updated_at": "2019-03-06T08:55:43.727Z",
"name": "string",
"description": "string",
"attributes": {
"additionalProp1": "string",
"additionalProp2": "string",
"additionalProp3": "string"
},
"contact_info": [
{
"contact_type": "CONTACT_TYPE_OTHER",
"contact_method": "CONTACT_METHOD_OTHER",
"value": "string",
"public": true,
"validated_at": "2019-03-06T08:55:43.727Z"
}
],
"version_ids": {
"brand_id": "string",
"model_id": "string",
"hardware_version": "string",
"firmware_version": "string"
},
"gateway_server_address": "string",
"auto_update": true,
"update_channel": "string",
"frequency_plan_id": "string",
"antennas": [
{
"gain": 0,
"location": {
"latitude": 0,
"longitude": 0,
"altitude": 0,
"accuracy": 0,
"source": "SOURCE_UNKNOWN"
},
"attributes": {
"additionalProp1": "string",
"additionalProp2": "string",
"additionalProp3": "string"
}
}
],
"status_public": true,
"location_public": true,
"schedule_downlink_late": true,
"enforce_duty_cycle": true,
"downlink_path_constraint": "DOWNLINK_PATH_CONSTRAINT_NONE"
}
What is missing? What do you want to see?
How do you propose to implement this?
Complementary to our application implementation.
What can you do yourself and what do you need help with?
I would like to follow up with a quick wireframe, once I have some input about the requirements.
I think we need some input here soon on what to show on the gateway overview page.
cc @htdvisser @johanstokking
I would keep it simple; ID, EUI, name, description and frequency plan.
Nice would be to show an online indicator by hitting the GS and checking the connection stats. If 200 <= status < 300 it's connected, if 404 it's not connected, and anything else is an error. This is a call per entry shown but it's worth it and cheap to serve from GS as it comes from memory.
from https://github.com/TheThingsNetwork/lorawan-stack/issues/26#issue-404416151
display connection statistics per gateway (if the gateway_server_address matches the Gateway Server API config of the current console)
and
Nice would be to show an online indicator by hitting the GS and checking the connection stats. If 200 <= status < 300 it's connected, if 404 it's not connected, and anything else is an error.
We should agree on what we show to user.
let
gtw_gs_address
be the address of the gateway server configured for the gateway
console_gs_address
be the address of the gateway server of the current cluster passed to the console
connected
gtw_gs_address
or console_gs_address == empty
-> status unknown
. this can happen if the gateway server address is not present in the current cluster or the address was not added when creating the gateway, or if both.gtw_gs_address == console_gs_address
-> status disconnected
gtw_gs_address != console_gs_address
-> the gateway is not managed by this console
unknown
, the Gateway Overview page displays an errorUI:
connected (1)
unknown (2.1)
disconnected (2.2)
not this console (2.3)
@johanstokking @htdvisser @kschiffer
I would use different logic for the connectivity indicator. It should start with the gateway server address, and not with the request to the GS (because it doesn't make sense to call a GS that we already know doesn't serve the gateway):
console.gateway_server_address
is empty, then the feature is disabled completelygateway.gateway_server_address
is empty, then either:console.gateway_server_address
but also show the messagegateway.gateway_server_address
is not equal to console.gateway_server_address
, then the feature is disabled for this gateway and show the messageI would also change the message a bit. We're trying to tell the user that the selected gateway is not assigned to the gateway server in the cluster of the current console. It's still possible to read/write stuff of the gateway that is in the identity server and not in the gateway server (basically everything other than connectivity state and traffic)
I would also change the message a bit.
What would be the message?
I agree with @htdvisser on the order.
So we have five states:
console.gateway_server_address
equals gateway.gateway_server_address
, then hit the GS:gateway.gateway_server_address
is empty; the gateway is not provisionedI would also change the message a bit.
What would be the message?
In any case, I don't know if the top part is a good location to display the notification. To have a meaningful message we likely need a longer text which won't look good there. I would say that Unknown
or Other Cluster
as a status is enough and we should look into another place to inform the user about specifics later.
Most helpful comment
I would keep it simple; ID, EUI, name, description and frequency plan.
Nice would be to show an online indicator by hitting the GS and checking the connection stats. If 200 <= status < 300 it's connected, if 404 it's not connected, and anything else is an error. This is a call per entry shown but it's worth it and cheap to serve from GS as it comes from memory.