Solutions Architecture: Device overview

[janhalen]

@andreasDroid: Lets discuss implementations and possible technology choices here!

The higl level goal i understand is a solution that can deliver:

1. table like page with overview of connected devices
2. map view of devices

criteria was first proposed by @andreasDroid in this issue: ⬇️

Solutions architecture: Registration tool for devices #13

[janhalen]

To understand the user perspective better maybe a user story discussion should be startet?

As a [ user-role]
I would like to [ ? ] (have acces to an overview page?? with devices on both a list and a map? or?)
to be able to [ ? ] (the business function / need that this would support)

[andreasDroid]

Let's separate the three defined functionalities:

Registration
As a technical user with knowledge and responsibility of GPSes in the municipality
I would like to be able to register new GPS devices and get feedback on the connectivity status
to be able to succesfully registering a device and start collecting fleet data for analysis and optimisation.

In solving this (#13), it would be beneficial to utilise the library suggested by @janhalen, json-registration to allow a general way of defining device meta-data for various types of IoT devices.
That said, we still need to develop specific code for handling the user flow to support the configuration of the different gps types. Done smartly, the flow could still be developed in a descriptive manner where configuration defines the steps.

Overview
As a fleet manager or business analyst
I would like to have a table like overview of all registered devices and their associated meta-data
to be able to view and update the vehicles registered for maintaining data

This is a simple one page table view that would pull all associated meta-data associated to a GPS and allow the user to edit it.

Map
As a fleet manager or business analyst
I would like to be able to view, on a map, where a GPS has been registered in the active data period.
To be able to validate the activity of vehicles and ensure the validity of the registered GPS locations.

The map needs to allow the user to filter on vehicle meta-data and date range. Hence, pulling both meta-data and activity from the timeseries db is necessary.

API layer needed?
As much as I would like to avoid it, I think we should introduce a thin API-layer for managing authentication for the frontend and handling authentication with external integrations such as FleetOptimiser. This will also be useful in the future for allowing external providers to deliver data.