Check Twice Before Sending
A firmware check will validate an extreme reading twice before sending out a notification alert.
Many anomalies could happen in reading a value between the input on the microcontroller, the connectors, and the sensor itself. There are cases where an abnormal reading gives you a value that would trigger an alert. Those cases are unreproducible. The alerts they trigger have you chasing ghosts.
To avoid phantom alarms and verify the seriousness of the extreme value, Zentser always does a double-check. The extra validation goes a long way in raising the alarm only in cases that require your attention.
As this happens digitally, the extra validation step adds a few milliseconds to the regular alert delay. The difference was negligible even in extreme situations.
10 Minute Interval
Zentser powered devices bridge the local sensor readings with the internet.
However, there’s a natural discrepancy in the timings of the readings. Your digital devices usually sample values every few milliseconds. However, making a Web API call every few milliseconds is not a viable approach. It will generate tons of trash traffic, take up unnecessary resources from the microcontroller, and require even more resources from the server.
This is why the historic sensor value graphs you see provide you with a sensor reading of every 10-minute interval. The 144 daily readings we store on the server give enough data to observe trends and derive conclusions.
The values that exceed the threshold and trigger the alert go out ASAP. So alarms and extreme conditions get to you right away. A double validation check happens locally on the device, and then the Web API call sends a notification and email to you. That puts the monitoring Zentser device in alert mode.
Once the device is in alert mode, the following email you get will go out at the regular 10-minute interval. If the sensor reading exceeds normal conditions, you will get continuous notifications and emails at 10-minute intervals.
Once the sensor readings go back to normal range, Zentser sends the email that the device deescalates from alert mode to normal mode. That email will also go out at the 10-minute interval.
There’s a selfish reason for the 10-minute interval. It’s a way for Zentser to save on a cloud bill. We are a scrappy, bootstrapped startup offering a free monitoring service. Any cost savings count. High-frequency API calls would run up that cloud bill faster than a budget airline with all add-ons added in.
Finally, there’s a proper security layer on top of our cloud implementation.
In case of a security breach, IF someone takes control of our API, they could hypothetically create a distributed denial-of-service (DDoS) attack. Last thing a scrappy startup needs is to be a weak point in a global cyber attack. Sure, big companies can get away from cyber crimes unscathed. Zentser is not “too big to fail” yet :)
The security layer checks have a straightforward rule. One device cannot send us more than 3 web calls within a minute. If you read the above 10-minute interval section, that should make sense.
So in cases, we start getting more than 3 calls from a device in 1 single minute, the security layer blocks that device for 24 hours.
If your thirst for knowledge isn't satisfied, the video below covers more topics around the Zentser platform. The video goes into more detail around:
- Use Cases
- Best Practices
- Common Terminology
- Alert Best Practices
- Monitoring On-the-Go