IOT Sensors and connections

A sensor is a module that observes changes in its environment and sends information about these changes to a device.

Devices collect data from sensors and send it to the cloud. Devices can be very small and have very few resources in terms of compute, storage, and so on. They might be able to communicate only through networks that cannot reach a cloud platform directly, such as over Bluetooth Low Energy (BLE). Standard devices are more likely to resemble small computers and may have the ability to store, process, and analyze data before sending it to the cloud.

There are many sensors available for IoT and a number of ways of categorizing them. The categories discussed below are just a small sample of the ways sensors can be grouped.

Sensors can be divided by their external power requirements:

TypeDefinitionExample
passiveDoes not require external power to operate. They respond to input from their environment.A temperature sensor that changes resistance in response to temperature changes
activeRequires external power to operate.A camera

Type of signal the sensor produces:

TypeDefinitionExample
analogOutputs an analog continuous signalAccelerometers, temperature sensors
digitalThe output is converted to discrete values (digital 1s and 0s) before transmitting to a deviceDigital pressure sensor, digital temperature sensor

Type of measuring device:

TypeDefinitionExample
chemicalResponds to chemical changes in its environmentGas sensor
mechanicalResponds to physical changes in its environmentMicroswitch
electricalResponds to electrical changes in its environmentOptical sensor

Choosing sensors for your project requires a clear understanding of what you want to measure and what accuracy is required.


When selecting an IoT sensor, there are several things to consider. Typically, the goal for an IoT sensor and device is long life with little human interaction. You expect to place IoT sensors and devices into the desired environment and have them work for an extended period of time. They might be in a remote location or embedded deep within a system, inaccessible to humans. Replacing a sensor and device in this situation may be extremely costly, dangerous, or even impossible; all reasons to carefully consider your sensor and device decisions.

Your decision is based on many factors. As you design your system, you need to carefully consider the importance of each factor and its priority to the overall design.

The following list of considerations can be thought of as a starting point for any IoT sensor discussion.

Durability

Durability must be considered with regard to the environment of the sensor. You want to make sure your device is as durable as necessary to operate for a reasonable period of time, without incurring unnecessary costs.

For example, a water-resistant temperature sensor may be acceptable for a remote weather station, but it would be completely unsuitable for monitoring water temperature in a pool because it is not waterproof.

Accuracy

You want to have enough accuracy to correctly monitor an environment, but you don’t want to pay for more than you need.

For example, if you are designing a system to regulate the temperature in a remote household storage unit, you are probably willing to accept a sensor that might be accurate with +/- 2 degrees. This accuracy would be completely unacceptable if you were designing a medical device system. A medical device temperature sensor would need to be accurate to +/- 0.2 degrees!

Versatility

Sensors must be able to operate within reasonable variations of environment. Because most IoT network designs have many sensors, in a variety of environments, it is important to have sensors that can function accurately in all variations of the environment.

For example, if you are building remote weather stations for wilderness areas, you will need to use sensors capable of handling extremes of summer and winter temperatures. It would not be practical to have sensors that only operate accurately at room temperature.

Power Consumption

Depending upon the situation, your requirements might be for a low-power, or even very low–power device. You will need to decide whether power-saving features (like sleep mode or fast wake up) are necessary.

For example, a sensor or device powered by solar-charged batteries may need to spend a great portion of its life in sleep mode to prolong battery life during low-light times. It may also need fast wake times to accurately capture data.

Special Environmental Considerations

Sensor choice can even affect the final system design.

For example, when designing a system for monitoring water quality, a sensor that can be placed within the main water supply piping is far more cost-effective and accurate than a sensor that requires diverting water samples.

Cost

IoT networks usually involve hundreds or even thousands of sensors and devices. Every aspect of sensor design must be scrutinized from a cost perspective. These costs involve more than just the price of the sensor. Consideration must be given to the cost of placement, maintenance, reliability, etc.

A “Thing” in the “Internet of Things” is a processing unit that is capable of connecting to the internet and exchanging data with the cloud. Devices are often called “smart devices” or “connected devices.” They communicate two types of data: telemetry and state.

Types of information

Each device can provide or consume various types of information. Each form of information might best be handled by a different backend system, and each system should be specialized around the data rate, volume, and preferred API.

Device metadata

Metadata contains information about a device. Most metadata rarely, if ever, changes. Examples of metadata fields include:

  • Identifier (ID) – An identifier that uniquely identifies a device.
  • Class or type
  • Model
  • Revision
  • Date manufactured
  • Hardware serial number

Telemetry

Data collected by the device is called telemetry. This is the eyes-and-ears data that IoT devices provide to applications. Telemetry is read-only data about the environment, usually collected through sensors.

State information

State information describes the current status of the device, not of the environment. This information can be read/write. It is updated, but usually not frequently.

Commands are actions performed by a device.

Commands might be valid for a limited period of time, so they should include a time-to-live (TTL) or other expiration value.

Examples of commands include:

  • Spin 360 degrees to the right.
  • Run self cleaning cycle.
  • Increase the rate by ten percent.

Operational information

Operational information is data that’s most relevant to the operation of the device as opposed to the business application. This might include things such as CPU operating temperature and battery state. This kind of data might not have long-term analytical value, but it has short-term value to help maintain the operating state, such as responding to breakages and correcting performance degradation of software after updates.

Operational information can be transmitted as telemetry or state data.

In IoT, the definition of a device can change depending on the needs of the project. You want to think about levels of abstraction as you design your project. There may be times when you want to consider each device as a separate entity, and other times when you want to consider a group of sensors as a single reporting device.

The specific requirements of your application will help you understand whether something that generates information should be treated as a device, and therefore deserves its own ID, or is simply a channel or state detail of another device.

For example, consider a project for monitoring the temperature in hotel rooms. Each room has three sensors: one near the floor, one near the bed, and one near the ceiling.

In this design, data is sent to the cloud as three different devices, each sending temperature information to the cloud.

{deviceID: “dh28dslkja”, “location”: “floor”, “room”: 128, “temp”: 22 }

{deviceID: “8d3kiuhs8a”, “location”: “ceiling”, “room”: 128, “temp”: 24 }

{deviceID: “kd8s8hh3o”, “location”: “bedside”, “room”: 128, “temp”: 23 }

Or, you can model the room as a single device, send the data for the entire room.

In this design the data is sent to the cloud as a single device with three sensors. Note that an additional field has been added to the data, ‘average temperature.

{deviceID: “dh28dslkja”, “room”: 128, “temp_floor”: 22, “temp_ceiling”: 24, “temp_bedside”: 23, “average_temp”: 23 }

The design you choose will depend upon how you intend to use the information, now and potentially in the future.

When connecting devices to Google Cloud Platform, you will need to specify which communication protocol your devices will use. The choices are MQTT, HTTP, or both.

MQTT is an industry-standard IoT protocol (Message Queue Telemetry Transport). It is a publish/subscribe (pub/sub) messaging protocol.

The publish/subscribe model is event-driven. Messages are pushed to clients that are subscribed to the topic. The broker is the hub of communication. Clients publish messages to the broker, and the broker pushes messages out to subscribers.

HTTP is a “connectionless” protocol: with the HTTP bridge, devices do not maintain a connection to the cloud. Instead, they send requests and receive responses.

In connectionless communication, client requests are sent without having to first check that the recipient is available. This means that devices have no way of knowing whether they are in a conversation with the server, and vice versa. This means some of the features that Cloud IoT Core provides, for example, last Heartbeat detected, will not be available with an HTTP connection.

Comparison of MQTT and HTTP general features

MQTT is considered to be data focused, while HTTP is document focused. Which means MQTT is better suited to the rigors of IoT.

Delivery Guarantees

MQTT has three levels of service:

  • At most once. Guarantees at least one attempt at delivery.
  • At least once. Guarantees the message will be delivered at least once.
  • Exactly once. Guarantees the message is delivered only once.

MQTT also has:

  • Last will and testament. If a client (ie device) is disconnected unexpectedly, the subscribers will be notified by the MQTT broker.
  • Retained messages. New subscribers will get an immediate status update.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s