Limiting the number of events. Can it be optimized?

Ideas
1

Hello. There are situations when limiting the number of events to 100 per day is not enough and this leads to the fact that an extremely important function disappears completely, and this is a big problem. Let me explain. Most often, events are used as alarms, and there are not too many of them, everything is ok. But when some kind of emergency or malfunction occurs, one accident often leads to another - this is a feature of the construction of many engineering systems. As a result, a dozen or more events can be sent at a time. Further, when the engineer fixes the malfunction, events usually also occur during the work and during the start-up of the equipment, their number varies, but a situation may arise when the limit has been exhausted. As a result, after the fault is cleared, the event function (critical function!) disappears completely. This is very bad.

In addition, in the type setting of each event, in addition to the “critical” and “attention” types, there is also the “information” type. But after all, information is not an abnormal type of event, but a completely working, current one, that is, it is the type of data that constantly comes in like a regular variable. For example: a door has opened or the appliance has heated up to the set temperature, etc. How can current information be limited to 100 per day?

I don’t really understand the reason for this limitation. After all, we can use a huge number of integer or float variables, data on them goes continuously, they are stored in the archive, there are a lot of them, they are not limited (and cannot be limited, because then the meaning is lost), why are events limited , and such a small number?

It would be great if the Founders reconsidered this critical function.

Thank you for reading to the end :blush:

2

Limits could be changed for the white labeled plan users.

3

I am aware of what is indicated in the documentation.
The topic is “ideas”, I indicated the reasons and arguments.

4

@Serg_Grn thanks for the feedback. Your arguments are valid. The reason for this limitation is the global system performance. The problem is we use “event” table for multiple queries that use joins. That’s why having that huge table is undesired, taking into account “realtime” nature of many events.

What if you have a “reset” button per device for the events that will reset the counter to 0. Would that help/solve issues you described?

1 Like
5

Yes, a reset button would be a good compromise. This would allow in an emergency situation, when the event resource has been exhausted, to restore the system to working capacity, and this is the main thing.
Thank you for your attention to the issue.

6

Question about notifications and events.
I realized that a large event table is undesirable.
But “event” and “notification” are different concepts.
For example, my system has a problem that causes the same event to repeat every 10 minutes. This event triggers a push notification. So I don’t need this event to accumulate in the table, but I need the push notification to come every time, because it’s important!
It turns out that the limit of 100 events limits the number of push notifications - and this is a significant drawback.
I don’t need more than 100 events, but I often need a lot more notifications!
Therefore, the question to Blink: Can you somehow separate events and push notifications? Let the limit of events remain 100 per day, but so that there are no limits on the number of push notifications, this is really very important!
Thank you.