Add device version and hardware version to `devices`

[oscgonfer]

Currently we use the kit representation for filling up several fields in the front-end (both in popups, tooltips, cards...). These are:

kit:
  id: 26
  slug: "sck:2,1"
  description: "Smart Citizen Kit 2.1"
  name: "SCK 2.1"

Since we are removing the /kits endpoint, we need to now populate these fields with data coming from the device/<id> or the device/world_map. I suggest some changes to the device representation as below:

Serialised JSON for API:

device
    name: OSCAR Sensor
    description: A sensor I have in my living room for whatever
    hardware:
        slug: "sck:2,1" (auto-generated based on hardware_type and hardware_version)
        type: SCK (autogenerated by the existence of hardware info or migrated)
        version: 2.1 (autogenerated by hardware info or migrated)
        description: Smart Citizen Kit 2.1(migrated and the we have basic logic to generate based on the rest)

In the device model:

device
    name: OSCAR Sensor
    description: A sensor I have in my living room for whatever
    hardware_slug: "sck:2,1" (auto-generated based on hardware_type and hardware_version)
    hardware_type: SCK (autogenerated by the existence of hardware info or migrated)
    hardware_version: 2.1 (autogenerated by hardware info or migrated)
    hardware_description: Smart Citizen Kit 2.1(migrated and the we have basic logic to generate based on the rest)

For each field:

• slug: "hardware_type:hardware_version"
• hardware_type: whether or not this is a Smart Citizen kit or something else. There are some cases of "extraneous" devices such. I was initially not going to suggest it, but I think it makes sense.
• hardware_version: the version of the hardware (potentially only set for our devices)
• hardware_description: a more verbose description of the hardware

Why? We have no way of guaranteeing that a certain version of a device has a valid hardware_info field except for very recent versions of the device.

Process

In general, we need to make sure that for, that the hardware_version field is easily parseable in the FE so that we can enable or disable features, and that there is a clear distinction between (what we call) legacy devices and non-legacy devices (i.e. kit_id <4). I suggest using the naming above with ., and making sure that both migrated and new devices are clearly defined.

I suggest a strategy for each:

For migrated devices:

• We migrate based on kit with some exceptions
  • hardware_type = I will provide a list of SCK and non-SCK devices based on the kit.id
  • hardware_version = for the majority it would be kit.name.split(' ')[1] except for some cases
  • hardware_description = kit.description

For new devices:

• New non-legacy devices will have hardware_info population (hardware_info[hw_ver] is 2.1 or 2.2...)
  • hardware_description: Smart Citizen Kit {hardware_info[hw_ver]}
  • Examples:
    • Before: Smart Citizen Kit 2.1 with CO2
    • Now: Smart Citizen Kit 2.1
  • hardware_version: {hardware_info[hw_ver]}
  • hardware_type: SCK unless set otherwise specifically (we can think that through)
• New legacy devices have no hardware_info available:
  • hardware_description: Smart Citizen Kit
  • hardware_type: SCK
  • hardware_version: to be populated with setuptool in the FE...

TO-DO

• [x] Agree on the proposed fields above
• [x] Implement logic in back-end and migration strategy as described
• [ ] Make sure setuptool works as needed for the new fields

[oscgonfer]

Let's kill hardware.description @timcowlishaw

[oscgonfer]

Done in https://github.com/fablabbcn/smartcitizen-api/pull/246