Single Gateway overview

[kschiffer]

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:

• basic info such as id, name, description, creation date
• status info (last seen)
• the gateways (antenna) location
• number of sent/received messages
• frequency plan
• hardware information (brand, model, signal strength, firmware)
• privacy (public/private gateway)

Implicitly, working on the overview will also contain:

• gateway parent view (with sidebar, breadcrumb container)

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?

• Quick discussion about what needs to be in there (are we missing anything)
• Wireframes and/or screendesigns
• Implementation

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.

[kschiffer]

I think we need some input here soon on what to show on the gateway overview page.
cc @htdvisser @johanstokking

[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.

[bafonins]

from #26 (comment)

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

1. If greater or equal to 200 and less than 300, then its connected
2. if 404
   2.1 if 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.
   2.2 if gtw_gs_address == console_gs_address -> status disconnected
   2.3 if gtw_gs_address != console_gs_address -> the gateway is not managed by this console
3. anything else -> the status of the gateway is unknown, the Gateway Overview page displays an error

UI:
connected (1)

unknown (2.1)

disconnected (2.2)

not this console (2.3)

@johanstokking @htdvisser @kschiffer

[htdvisser]

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):

• If console.gateway_server_address is empty, then the feature is disabled completely
• If gateway.gateway_server_address is empty, then either:
  1. assume console.gateway_server_address but also show the message
  2. the feature is disabled for this gateway and show the message
• If gateway.gateway_server_address is not equal to console.gateway_server_address, then the feature is disabled for this gateway and show the message

I 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)

[bafonins]

I would also change the message a bit.

What would be the message?

[johanstokking]

I agree with @htdvisser on the order.

So we have five states:

• If console.gateway_server_address equals gateway.gateway_server_address, then hit the GS:
  • 1. Connected if 200 <= status < 300
  • 2. Not connected if 404
  • 3. Error if otherwise
• Otherwise
  • 4. Unknown If gateway.gateway_server_address is empty; the gateway is not provisioned
  • 5. Other Cluster otherwise (i.e. addresses differ)

[kschiffer]

I 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.