Alerts Versus Analysis/Parameters

Team,

When a system needs to scale, you might add a bunch of devices that each have a different “normal” (say a water level), a different “too low” level, and a different “too high” level - each of the too low and too high you would want to alert the user.

I see a couple of strategies and I thought I would query ALL OF YOU for your opinions on this.

  • Strategy 1 - Create an Alert for each device
    • Very simple - fits well with Tago.io
    • Might end up with LOTS of alerts
    • Cumbersome
    • Flexible for the customer
  • Strategy 2 - Create an Alert that tag matches all the devices
    • One alert which is nice
    • Requires meta-data on the device, which is nice, but cumbersome
    • run analysis which check the meta-data (parameters) then decides to send alert

Cheers,

Marlan

Hi @marlanw,

Here is a high-level breakdown of the two strategies and where each fits best:

Strategy 1: Create an Alert for each device
This approach is straightforward and utilizes TagoIO’s native Actions effectively. However, it is strictly recommended for use cases with a single device or a very small, static fleet. As you correctly pointed out, managing individual alerts becomes a significant administrative bottleneck as your project scales.

Strategy 2: Create an Alert using tags to match all devices
This is the recommended approach for scenarios requiring scalability. By using a single Action triggered by tags and routing the data to an Analysis, you establish a dynamic, centralized logic structure.

  • Handling Metadata: You can manage specific thresholds (such as too_high and too_low) natively using Device Configuration Parameters. Your Analysis can dynamically fetch these parameters per device during runtime to evaluate the alert conditions.
  • Handling Concurrency: To ensure optimal performance as you scale, avoid processing devices sequentially. We recommend implementing asynchronous concurrency patterns within your Analysis. This allows you to process multiple devices in parallel while safely managing platform rate limits.

Building for scale requires a bit more initial setup using Strategy 2, but it will easily accommodate your customer growth without requiring constant architectural changes.