First Proof-of-concept meshtastic integration

[timcowlishaw]

First attempt at supporting infrastructure for meshtastic ingestion (as outlined in #398 ) for the Fab25 hackday.

Data model changes

This adds a few new fields:

• Devices now have an optional meshtastic_id
• Measurements also have an optional meshtastic_id
• Measurements also have an optional meshtastic_default_sensor_id, which should point to the ID of a sensor for that measurement

These can all be updated through the API in the usual way, by device owners /admins as appropriate

New internal endpoints

The meshtastic ingestion script being developed elsewhere needs to be able to resovle meshtastic node IDs and telemetry keys to smartcitizen device tokens and sensor IDs, so we create a couple of internal endpoints to enable that:

/meshtastic/device_token?meshtastic_id=MESHTASTIC_ID&ingest_token=SECRET_INGEST_TOKEN - this returns the device token for a given meshtastic ID.

/meshtastic/sensor_id?device_meshtastic_id=DEVICE_MESHTASTIC_ID&measurement_meshtastic_id=MEASUREMENT_MESHTASTIC_ID&ingest_token=SECRET_INGEST_TOKEN - this returns the sensor id for the sensor on that device which senses that measurement if one exists, or the meshtastic_default_sensor_id for the measurement otherwise.

In both cases, the SECRET_INGEST_TOKEN is a shared secret, provided in the MESHTASTIC_INGEST_TOKEN environment variable, to ensure that only our ingestor script can access these endpoints.

Onboarding meshtastic devices

The "legacy" device registration page, when accessed by "researchers" and "admins" now includes the option to select a "Smartcitizen Meshtastic Prototype" hardware version, leave the MAC address field blank, and add a meshtastic node ID in the "researcher options" section.

[timcowlishaw]

Am closing this as a Spike for now, as the hackday is over, pending further discussion. We can re-open when we're ready to think about how to productionise this