Device identification

[mstenta]

There needs to be a better way to identify sensor devices.

Currently, when the Atmospi web app is loaded, it searches through all the DATA (Temperature, Humidity, and Flags) tables to determine what different devices are available. This allowed for DS18B20 auto-detection, but it is very expensive when more and more data is recorded. There is also now way to label devices.

Requirements:

• Create a new table for managing device labels, with the following columns:
  • DeviceID (int - primary key)
  • Type (varchar): The type of sensor. Must be one of: ds18b20, dht22, dht11, am2302
  • SerialID (varchar): In the case of DS18B20 sensors, this will be the sensor's 64-bit serial code. In the case of DHT sensors, this will be the ID assigned to it in the settings.py file.
  • Label (varchar): The human readable label for the device.
• Load the list of devices from the device table, rather than scanning the data tables.
• When a new DS18B20 sensor is detected, automatically add a new record to the devices table, with the serial number as the default label.
• Change the way that DHT sensors are defined: stop using settings.py and instead instruct users to manually add a record to the devices table.

[mstenta]

Data consistency considerations:

If a device is moved or repurposed, we don't want to lose, or be confused by, old data. Should it start a new graph, or continue from the old one (and possibly use the Flags table to make a note of the move).

Similarly, if a device fails, and needs to be replaced with another (with a different serial number), how should that be handled? Should it be a continuation of the same graph as before? Or a new one?

Ultimately, it seems that we may need a higher-level concept of a measured value, separate from specific measurement sensors/devices. For example, "Basement Humidity" is what I want to see, but the specific sensor that measures that may change over time.

[ultima-originem]

Now I got Atmospi up and running, this seems the most useful enhancement. Your last remark summarizes the basic requirement and I agree with your analysis.

For now I'd me happy with a quick and dirty workaround as I have 5 sensors and it's hard to keep them apart.

[ultima-originem]

I have hard coded the required changes [not a pretty solution]. Apple the following code twice:

/**

• Load latest measurements. */ function loadLatestMeasurements() {

  var devName;

  // Load the latest temperature data. $.getJSON('data/latest/temperature', function(devices) { $.each(devices, function(device, data) {

  // map to a human-sensible name for each device

  switch (device) { case "28-000005fab89c": devName= "first name"; break; case "28-000005fab2e0": devName= "second name"; break; case "28-000005fb03d6": devName= "third name"; break; case "28-000005fab05d": devName= "fourth name"; break; }

where the device IDs will have to be changed into your device IDs and the device names will have to be customized.

It's not pretty but it works.

[ultima-originem]

See also my solution to https://github.com/mstenta/atmospi/issues/20

[mstenta]

I am working on this issue in the new "devices" branch: https://github.com/mstenta/atmospi/tree/devices

It will require a fair bit of database updating to get it to work, so I am documenting all of that in CHANGELOG.md: https://github.com/mstenta/atmospi/blob/devices/CHANGELOG.md

When it's all done, I will officially release v0.2.0. Until then, it's a work in progress (including the instructions in CHANGELOG.md) so don't do it unless you're comfortable fixing things that break (AND BACKUP BEFOREHAND!)

More soon...

[mstenta]

OK! This was a big one, but it's done!

Please read the release notes for instructions on how to update: https://github.com/mstenta/atmospi/releases/tag/v0.2.0

If you have any issues, let me know! And be sure to back up your database and custom code changes first! Chance are this will conflict with some of the work you did to hard-code things...