Detecting Anomalous Devices With Notehub Smart Fleets

Earlier this year we released smart fleets, a Notehub feature that lets you automatically categorize devices based on their data.

Since then we’ve made heavy use of the feature internally for our air-quality-monitoring project, Airnote, as well as the radiation-monitoring project we help run in collaboration with Safecast and SaveDnipro, Radnote.

In this article, I’ll share a few of the smart fleets we’ve created and found useful, as they might inspire ideas you can build into your own projects. I’ll also announce a new feature in Notehub that makes smart fleets even more powerful.

Detecting Bad Mounting

We designed both Airnote and Radnote to be mounted vertically to ensure their solar panels are optimally positioned.

And while it would be ideal if every deployed device were installed correctly and stayed that way, we know that’s not always the case: devices can be mounted poorly and fall, be tampered with, or suffer damage from the elements.

But how do you detect this?

At the end of each session (a unique connection between Notecard and Notehub), Notecard sends a variety of metadata to Notehub in a _session.qo Notefile. One of the fields in that Notefile is orientation, which Notecard sets to one of six values ("face-up", "face-down", "portrait-up", "portrait-down", "landscape-right", "landscape-left") using readings from its onboard accelerometer.

note

A fun thing you can try: open the In-Browser Terminal, connect a Notecard, and run card.motion requests while tilting your device—it’s a quick way to see how Notecard’s orientation detection works.

Because the orientation data exists in Notehub events, it means you can write smart fleet rules that categorize your devices based on this data.

For example, here’s a smart fleet rule that detects devices with bad mounting.

(
  $testThisEvent := (file = "_session.qo" and $exists(body.opened));
  $badMounting := (orientation != "face-up");
  $result := $testThisEvent ? ($badMounting ? $addToFleet() : $removeFromFleet()) : $leaveFleetAlone();
)

note

Smart fleets rules use JSONata expressions. In this article I’ll cover the basics so you can follow along. For a deeper dive into the syntax, see Using Smart Fleet Rules in our documentation.

Let’s break this down. The first line of this expression acts as a filter to ensure this expression only operates on certain types of events.

$testThisEvent := (file = "_session.qo" and $exists(body.opened));

Notehub executes smart fleet rules for all incoming events. The logic above sets a boolean variable that indicates whether this is an event we care about for this fleet. In this case we care about events from the _session.qo Notefile ("file":"_session.qo") that were sent at the start of a session "body":{"opened":true}.

Next, we set another boolean, in this case to determine whether the device is mounted incorrectly. Correctly mounted Airnote devices have their orientation set to "face-up", so this check looks for devices that have some other value in this field.

$badMounting := (orientation != "face-up");

The last line puts everything together.

$result := $testThisEvent ? ($badMounting ? $addToFleet() : $removeFromFleet()) : $leaveFleetAlone();

Here’s what that line does in detail:

• If $testThisEvent is false we call $leaveFleetAlone(). There’s no categorization to perform in this case.

• If $testThisEvent is true and $badMounting is true we call $addToFleet(). This is the condition that adds incorrectly mounted devices to our fleet.

• If $testThisEvent is true and $badMounting is false we call $removeFromFleet(). If a device was previously mounted incorrectly, and then was fixed, this check ensures the device gets removed from our fleet.

Once a fleet’s smart fleet rules have been saved they’ll immediately start categorizing devices as events flow into your Notehub project. In the case of the Airnote project, this has helped us determine how many devices are not installed face up.

Detecting Bad Sensors

Meanwhile, on our Radnote project we’ve been using smart fleets to detect a different problem: devices that have a bad Geiger-Müller (GM) tube.

In a radiation monitor a Geiger-Müller (GM) tube is used to measure radiation levels. In Radnote, those radiation readings are sent in _air.qo events that look like this.

{
  "event": "e0da0363-e29e-4913-9bfa-b9e485a8f51b",
  "when": 1753464678,
  "file": "_air.qo",
  "body": {
    "cpm": 13,
    "sensor": "lnd7317",
    "usv": 0.038922155688622756
  },
  ...

The cpm is a counts-per-minute reading from the GM tube, and represents the number of particles that strike the detector in one minute.

The usv, or μSv/h, is derived from the cpm using a sensor-specific calculation, and is the value commonly used to determine radiation rates. The reading from this event is ~0.04 μSv/h, which indicates normal background radiation.

Although GM tubes generally have a lifespan of 10+ years, occasional failures do occur due to environmental stress or component degradation. For the Radnote project we have devices deployed globally, and some of our devices are subjected to harsh environmental conditions. (See this writeup from our friends at Safecast for a recent example.)

Over time, we’ve noticed that when tubes fail they stop reporting cpm in their _air.qo events.

{
  "event": "9952316f-cacd-48b0-88e2-400020a4cc35",
  "when": 1750401250,
  "file": "_air.qo",
  "body": {
    "sensor": "lnd7128"
  },
  ...
}

This difference in the event data gives us a chance to build a smart fleet containing only devices with bad tubes. Here is the smart fleet rule we’ve been using.

(
  $testThisEvent := (file = "_air.qo" and $exists(body.sensor));
  $badData := ($exists(body.cpm) = false or body.cpm = 0);
  $result := $testThisEvent ? ($badData ? $addToFleet() : $removeFromFleet()) : $leaveFleetAlone();
)

Let’s break this down. The first line of this expression again acts as a filter to ensure this expression only operates on certain types of events. In this case we only care about events from the _air.qo Notefile that contain a body.sensor field.

$testThisEvent := (file = "_air.qo" and $exists(body.sensor));

Next, we perform the following check to determine whether we have bad data. In the case of Radnote, we consider bad data to be an _air.qo event that does not contain a body.cpm field, or an _air.qo event that has a body.cpm field set to 0.

$badData := ($exists(body.cpm) = false or body.cpm = 0);

Finally, we again put everything together. We use the $testThisEvent and $badData booleans to determine whether to add the device to the fleet ($addToFleet()), remove it ($removeFromFleet()), or to perform no action ($leaveFleetAlone()).

$result := $testThisEvent ? ($badData ? $addToFleet() : $removeFromFleet()) : $leaveFleetAlone();

This check has helped us find four devices with potentially bad hardware we need to investigate.

These are just a couple of the smart fleets we’ve built—and they’ve already helped us catch real-world issues in the field.

And to make smart fleets even more powerful, Notehub now includes a new feature that gives you more control over how data from different fleets is routed and processed across your system.

Excluding Fleets From Routing

Notehub routes allow you to forward your data from Notehub to other cloud services or to custom MQTT/HTTP endpoints.

Routes are highly configurable. When setting a route up, you can choose to forward all of your data or to apply filters that limit the data you send. For example, an alerting service, a dashboarding service, a diagnostics service, and an archiving service all expect different types of data.

New in Notehub is another filter: Fleets to Exclude. As the name implies, Fleets to Exclude gives you a quick way to prevent data from specific fleets from being routed to your cloud service. This is especially useful in cases where you want to filter out known-bad data—such as from devices with malfunctioning sensors—before it hits your downstream systems.

In the example below, we use Fleets to Exclude to prevent devices in the Bad Tube fleet from being routed to AWS.

Fleets to Exclude gives you another layer of control when managing how data flows through your system. Whether you want to prevent bad data from entering an external analytics pipeline, or simply reduce noise in downstream services, this feature makes it easier to build clean, intentional routing strategies around your smart fleets.

Wrapping Up

Smart fleets have become a powerful tool in how we manage and monitor our own device deployments—and we're just scratching the surface. Whether you want to detect bad installs, faulty sensors, or define your own custom criteria, smart fleets give you a flexible way to automatically categorize and act on your device data.

If you haven’t tried smart fleets yet, now’s a great time to start. With just a bit of setup, they give you a powerful way to categorize devices and uncover issues faster.