Automated sensor updates – Info

Build a solution for an IoT company which checks large amounts of sensors if they are ready to be shipped.


You are part of an IoT (IoT stands for Internet of Things) company shipping sensors to a vast amount of clients. We deal in sensors that can measure for example temperature, pressure, humidity, etc… After measuring, these sensors send the data over the internet. These sensors are manufactured somewhere else. Your company orders new sensors when needed in batches of up to 250 sensors at the time. These sensors have  firmware from their original manufacturer, which is pretty trustworthy. 

In your company, before the sensors are shipped to customers, the people from the operations team have to configure these sensors. In other words, they need to upload configuration to these sensors. An example of something that can be configured is the server to where the sensors should send their measurements. 

While testing sensors of type TS50X with the latest configuration, the people of the operations team noticed a compatibility problem with older firmware. Some new features which can be configured do not seem to work with older firmware. So the sensors only do a part of what they should be doing. Your company cannot ship those sensors to customers. Your company stands for high quality and happy customers.

The people of the operations team should check every incoming batch of sensors (up to 250) if they can be shipped or not. However, these people are very valuable. They shouldn’t manually check up to 250 sensors to check if the firmware version will work with the latest firmware. They have other more important work to do. 

What they need is an automated solution that can check up to 250 sensor serial numbers (or ids) and give the current status of that sensor. 

If the firmware version is not compatible, the sensor can’t be shipped. So the solution should take the next step to make it shippable. 

In addition, while automating sensor work anyway, have the solution update the configuration automatically as well.

Use case 1: Update sensors from the given list of IDs

You have a list of sensor IDs and you want to know if these sensors are ready to be shipped or not. If not, you need to schedule the next step in order to make it shippable. A sensor is ready to be shipped when its firmware is appropriate and if the configuration is the latest configuration.

So for each sensor with its id in the list, you need to check if the firmware is appropriate so that the latest configuration can run without problems. Currently, firmware with version 59.1.12Rev4 or higher is appropriate. Don’t forget to schedule a task for the configuration and if needed, a task for to updte the firmware.

You need to use the API of the original manufacturer to get the current sensor information and to schedule tasks such as a firmware update and a configuration update.

Additional information

  "serial": 123456789098789,
  "type": "TS50X",
  "status_id": 1,
  "current_configuration": "some_oonfiguration.cfg",
  "current_firmware": "59.1.12Rev4",
  "created_at": "2022-03-31 11:26:08",
  "updated_at": "2022-10-18 17:53:48",
  "status_name": "Idle",
  "next_task": null,
  "task_count": 5,
  "activity_status": "Online",
  "task_queue": [124355, 44435322] 

Getting sensor information

Use the following endpoint to get sensor information:{id}

For the record, this endpoint is a fake. But use it to fetch the current state of senors.

Status field:

A sensor can be in one of the next statuses:

Status name Status id Description
Idle 1 The sensor doesn’t have any tasks
Awaiting 2 A task has been scheduled, the device is waiting for execution
Updating 3 The device is doing an update

Activity status field:

A sensor can have the following activity statuses:

Status name Status id Description
Online 1 The sensor is online and capable of sending information
Disconnectd 2 The sensor is not online and cannot send information
Error 3 The sensor is in an error state and cannot function normally

Scheduling a task

Use the following endpoint to schedule a task: 

The result of this operation is the unique id of the task itself. For example: ‘33458223415’

Task type

A task can have be one of 2 types:

Type Description
update_firmware A task to update the firmware
update_configuration A task to update the configuration

Both types of tasks actually need a file (either the firmware installation file or the configuration file) to be able to do their job. That is why the API is showing a file_id, which is a reference to an existing file.

  "sensor_serial": 234545767890987,
  "file_id": "a3e4aed2-b091-41a6-8265-2185040e2c32",
  "type": "update_configuration"


What are evolutions again? Evolution are extra challenges which you can complete after you have done the base challenges. Evolutions are exactly what you think they are: they are evolutions of the problem, changes in requirements of users and stakeholders. They are meant to test the design of your solution.

Evolution 1:

Deal with ongoing updates

The solution is a bit off. We didn’t take into account that there might already be ongoing updates or that there might be a queue of tasks. Only one task at the time can be completed anyway.

You have to adapt the solution. Before scheduling updates, check if there is already an update/task ongoing. If there is a useful ongoing task, we don’t need to schedule a new update.

If there is an ongoing update, check the update. In case of a firmware update, check to which version it is updating. You can do that by checking the filename of the update file. If the version is below the desired version, cancel the task and schedule a new one.

In case of a configuration update, check if it is the latest configuration. This can also be checked by verifying the filename. If not, cancel the task.

In case there is a queue of tasks for a specific sensor, delete all the tasks in the queue. Because any new task would end up at the end of the queue and we can’t have that.

Extra information

You need to know about some more endpoints of the manufacturer API in order to make this work.  

Get task information

Use the following endpoint to get information of a specific task: 

GET #{id}

The request returns the following information: 

  "id": 16624171,
  "sensor_serial": 12345678909789,
  "type": "update_firmware",
  "status_id": 2,
  "attempt_count": 3,
  "created_at": "2022-10-17 16:00:07",
  "updated_at": "2022-10-17 16:49:39",
  "file_id": "a3e4aed2-b091-41a6-8265-2185040e2c32",
  "status_name": "Completed"

Status field:

A task can be in one of the next statuses:

Status name Status id Description
Pending 1 The task is waiting to start
Completed 2 The task has successfully completed
Error 3 The task was either interrupted by an error or it completed causing an error
Ongoing 4 The task is ongoing

Delete a task

Use the following endpoint to delete a task. Deleting a task will cancel it if it was ongoing.

DELETE #{id}

Get file information

Use the following endpoint to to get more information about an update file that is used for sensor update tasks.

DELETE #{id}/info

The request returns the following information: 

"id": "a3e4aed2-b091-41a6-8265-2185040e2c32",
"name": "",
"created_at": "2023-09-23 10:31:54"

Evolution 2:

A different type of sensor with a different way of versioning firmware.

The solution is a success! Therefor your managers would like to use this solution for other sensors as well, namely the P100T. It turns out that these sensors have a different way of versioning firmware. They use dates followed by a release number. For example: 2023-09-10R2.

You have to extend the solution so that we can give a list of P100T ids to check and update.