Proposal: Implementing a device metric notification system with configurable threshold alerts
Hi everyone 
,
I would like to propose an enhancement to ChirpStack that enables configurable high-low threshold notifications for device metrics.
The aim is to help users monitor conditions such as temperature, humidity or other custom sensor values and receive timely alerts whenever these metrics fall outside defined acceptable ranges.
Motivation
In many LoRaWAN deployments, sensors provide critical environmental or operational data that must remain within certain parameters. For example, cold-chain monitoring systems need to ensure that temperature levels stay within strict limits. When these thresholds are breached, prompt notifications can make a real difference, preventing product spoilage or damage.
While I am aware there are several integrations that can already achieve this purpose, these often assume a level of technical proficiency that not all users possess.
ChirpStack, being highly regarded for its reliability and features, has the potential to improve the out-of-box experience(OOBE) for users who may not be fully comfortable extending ChirpStack into a broader integrated environment.
If these capabilities were native and more intuitive, it would allow a wider range of users to benefit directly from ChirpStack’s functionality without relying solely on technical overhead or additional systems.
Proposed Features
-
Configurable Thresholds:
Administrators or end-users would have the ability to set high and low thresholds for specific device metrics. A simple configuration panel in the ChirpStack application server interface would allow users to define acceptable ranges based on their unique requirements. -
Notifications and Alerts:
When a threshold is exceeded, ChirpStack would generate an alert event. This event could be forwarded to standard notification systems via email, SMS or messaging platforms such as Slack or Teams. By leveraging ChirpStack’s existing webhook structure, users could customise alert delivery channels while still benefiting from a straightforward, integrated experience. -
Granular Settings and Frequency Control:
To reduce alert fatigue, the feature could incorporate parameters to control when and how often alerts are sent. For instance, notifications might only trigger after conditions persist beyond a certain time, or alerts could be batched at regular intervals. Different thresholds could also be assigned to various device profiles or applications to suit a range of use cases. -
Reporting and Historical Insights:
Integrating threshold alerts with ChirpStack’s existing data retention mechanisms could enable simple reporting. This would help users identify recurring issues and refine their threshold settings over time, offering a more holistic, user-friendly approach to monitoring and alerting.
Benefits to the ChirpStack Community
*Improved oversight of monitored conditions leads to better decision-making and quicker response times.
- Reduced reliance on external integrations that might be intimidating for less tech-savvy users, encouraging broader adoption.
- An integrated notification feature would position ChirpStack as a fully featured LoRaWAN network server capable of serving diverse use cases out-of-the-box.
I’m willing to assist in the development of these features, but sought to first understand what the appetite and opinion of the community was, for this proposal.
Let me know your thoughts!
- Fish
