Currently, measurements belong to many sensors and sensors belong to many kits (using components/board)
That allows multiple sensor combinations to be used in many different kits. However, when a sensor has a measurement, this can't be changed per kit.
By allowing measurements to be defined (via components) per kit, it will enable us the same hardware sensor to be presented as different measurements by changing the kit only.
Example:
When an SCK detects an "Atlas Scientific EZO™ Temperature" sensor on the auxiliary bus, it starts publishing its values using sensor_id: 51
However, sensor_id: 51 could be used either to measure soil temperaturemeasurement_id: 24 or water temperaturemeasurement_id: 17
Now even if a different kit_id (device blueprint) is used, we can't change this. Being the only way to fix it by publishing them as two separate sensor_id those requiring to specify on the device firmware how it is being used. Instead, if measurements are defined by kits without any hardware / firmware change users will be able to select it when choosing their kit during the device on-boarding Advanced Kit Selection.
That feature is especially crucial for the upcoming Analog Sensors Board where final measurements will change, but the firmware will consider the sensors always the same, Analog Sensors Board inputs 0-3. That way sensors are the hardware components providing a metric (see also parent_id for parent sensors) and measurements the actual name of the parameter.
Behaviour
As sensors have already measurements we have two options:
A. We move measurements to components, measurements belong to many components and create a task to move existing measurements sensor relation to measurement components.
B. We allow measurements belong to many components and measurements belong to many sensors. The components relation will be optional and once set will overwrite the existing one on sensors for that particular component, so kit.
Currently,
measurementsbelong to manysensorsandsensorsbelong to manykits(using components/board)That allows multiple sensor combinations to be used in many different kits. However, when a sensor has a measurement, this can't be changed per kit.
By allowing measurements to be defined (via components) per kit, it will enable us the same hardware sensor to be presented as different measurements by changing the kit only.
Example:
When an SCK detects an "Atlas Scientific EZO™ Temperature" sensor on the auxiliary bus, it starts publishing its values using
sensor_id: 51However,
sensor_id: 51could be used either to measure soil temperaturemeasurement_id: 24or water temperaturemeasurement_id: 17Now even if a different
kit_id(device blueprint) is used, we can't change this. Being the only way to fix it by publishing them as two separatesensor_idthose requiring to specify on the device firmware how it is being used. Instead, if measurements are defined by kits without any hardware / firmware change users will be able to select it when choosing their kit during the device on-boarding Advanced Kit Selection.That feature is especially crucial for the upcoming Analog Sensors Board where final measurements will change, but the firmware will consider the sensors always the same, Analog Sensors Board inputs 0-3. That way sensors are the hardware components providing a metric (see also parent_id for parent sensors) and measurements the actual name of the parameter.
Behaviour
As sensors have already measurements we have two options:
A. We move measurements to components,
measurementsbelong to manycomponentsand create a task to move existing measurements sensor relation to measurement components.B. We allow
measurementsbelong to manycomponentsandmeasurementsbelong to manysensors. The components relation will be optional and once set will overwrite the existing one on sensors for that particular component, so kit.