Миттєві сповіщення про зникнення/відновлення 220/380В на вводах A/B/C, анти-flap фільтри, журнали інцидентів, графіки простоїв і звіти по SLA/uptime — без складних SCADA і довгих впроваджень.
Для об’єктів із двома й більше вводами головне — час реакції та коректне перемикання. Бот приймає сигнали з лічильників/релє/АВР, застосовує анти-flap (debounce, hysteresis, M/N-підтвердження), сповіщає команду, веде журнал інцидентів і рахує доступність. Ви бачите, який ввод упав, коли відновився, тривалість і частоту подій, а також агреговані звіти для керівництва й орендарів.
- Онлайн-сповіщення: «Немає напруги на A/B», «Перемикання на резерв», «Відновлено».
- Anti-flap: затримки/підтвердження для ігнорування «миготіння» мережі.
- Статистика простоїв: тривалість інцидентів, частота, сумарний даунтайм.
- SLA/uptime: доступність по кожному вводу та по об’єкту (A∨B∨C).
- Інциденти: відповідальні, чек-лісти, нотатки, ескалації за часом.
- Звіти: XLS/CSV із агрегатами, графіки, таблиці для керівництва/орендарів.
- Інтеграції: сухі контакти АВР/реле, статуси лічильників, API з АСКОЕ.
- Джерела подій: сухі контакти «є/нема 220/380В», статуси лічильників, датчики фаз.
- Шлюз: мікроконтролер/промисловий шлюз (ETH/LTE/NB-IoT) → MQTT/HTTPS.
- Сервіс подій: нормалізація, debounce/hysteresis, M/N-підтвердження, контекст.
- Бот-ядро: маршрутизація алертів у чати, тредування, підтвердження, ескалації.
- Сховище/аналітика: БД подій, агрегати MTTR/MTBF/uptime, дашборди, експорти.
- Політики: карти відповідальності, робочі вікна, «тихий режим», ескалації по часу.
- Loss A: після N підтверджень — алерт «Ввід A відсутній», старт інциденту.
- Auto-switch: за наявності АВР і OK на B — фіксуємо «Перемикання на B».
- Recovery A: відновлення → закриття інциденту, тривалість, рекомендація повернення.
- Multi-loss: падіння на A і B — критичний інцидент, червона ескалація.
- Partial phase loss: втрата однієї з фаз → попередження та статистика часткових відмов.
| Метрика | Опис |
|---|---|
| Uptime, % | Частка часу з напругою на хоча б одному вводі |
| Uptime(A/B/C) | Доступність кожного вводу окремо |
| MTTR | Середній час відновлення |
| MTBF | Середній час між відмовами |
| Incidents/mo | Кількість інцидентів на місяць |
| Total downtime | Сумарний час простоїв за період |
Приклад щомісячного звіту (фрагмент)
| Ввід | Інцидентів | Сумарний даунтайм | MTTR | MTBF | Uptime |
|---|---|---|---|---|---|
| A | 3 | 2 год 10 хв | 43 хв | 9 дн | 99,70% |
| B | 1 | 25 хв | 25 хв | 27 дн | 99,94% |
| Об’єкт (A∨B) | 0 критичних | 0 год | — | — | 100% |
Об’єкт зберіг 100% доступності завдяки резервуванню на вводі B.
Вхідні дані: бізнес-центр, 35 орендарів, вартість простою 3 200 грн/год на орендаря.
Без бота
- 3 інциденти/міс × 0,5 год × 35 × 3 200 = 168 000 грн/міс потенційних втрат
З ботом + АВР
- Тривалість інциденту ≈ 10 хв, ескалації вчасні
- 3 × (10/60) × 35 × 3 200 ≈ 56 000 грн/міс
Економія: близько 112 000 грн/міс. Пакет «Pro» окупається за 1–2 місяці.
| Пакет | Вводи/об’єкти | Канал подій | Фільтри/Anti-flap | Звіти/Експорт | SLA | Орієнт. бюджет, грн/міс* |
|---|---|---|---|---|---|---|
| Start | до 2 вводів / 1 об’єкт | HTTP(s)/MQTT (1 шлюз) | Базові | XLS/CSV | 8×5 | 2 900 – 5 900 |
| Pro | 2–4 вводи / 1–3 об’єкти | + LTE/NB-IoT | Розширені (M/N) | Дашборди + експорт | 12×5 | 6 900 – 12 900 |
| Enterprise | 4+ вводів / 3+ об’єкти | Гібрид (ETH+LTE), HA | Політики/ескалації | Звіти SLA, API | 24×7 | від 18 000 |
*Інтеграція зі «сухими контактами»/АСКОЕ та апаратна частина рахуються окремо.
- Жовтий Зникнення на одному вводі > 5 сек (3 із 5 підтверджень) → чат чергових.
- Помаранчевий Відсутність ≥ 2 хв → дубль керівнику + інцидент.
- Червоний Втрати на всіх вводах або «флапи» → ескалація ланцюжком + SMS черговому.
- Зелений Відновлення → закриття інциденту, розрахунок тривалості, нотатка.
- Джерела сигналів: реле контролю напруги, сухі контакти АВР, статуси лічильників.
- Шлюзи: ETH/LTE, буфер ≥ 1 000 подій, автоповтори при втраті зв’язку.
- Зв’язок: HTTPS/MQTT (TLS 1.2+/1.3), allow-list IP, взаємні сертифікати опційно.
- Зберігання: історія подій 12–36 міс, щоденні бекапи, ролі доступу (RBAC).
- Месенджери: технічний чат + опційно керівництво, «тихі вікна» для неробочого часу.
| Параметр | Рекомендоване значення | Опис |
|---|---|---|
| Debounce | 3–5 сек | Ігнорування імпульсних збоїв |
| Confirm window | 5 вимірів | Вікно для M/N-підтверджень |
| M/N | 3/5 | Поріг «відмова/відновлення» |
| Min incident | 10 сек | Коротші події → «попередження» |
| Cooldown | 60 сек | Повторні алерти не частіше раз/хв |
Параметри підбираються під конкретну якість мережі та вимоги до чутливості.
- Шифрування/автентифікація: TLS, взаємні сертифікати для шлюзів, підписи повідомлень.
- Аудит: журнали входів/налаштувань, історія ескалацій, контроль змін політик.
- Мінімізація даних: передаються лише технічні стани без ПДн; звіти — агреговані.
- Ввід A/B/C
- Незалежні лінії живлення, що резервують одна одну.
- АВР
- Автоматичне введення резерву — перемикання на інший ввод.
- Uptime
- Частка часу з наявною напругою на об’єкті.
- MTTR/MTBF
- Середній час відновлення/між відмовами.
- Anti-flap
- Запобігання «миготінню» алертів фільтрами/підтвердженнями.
Чи потрібні зміни в щиті?
Сухі контакти/реле контролю напруги з кожного вводу або статусні виходи лічильників.
Що, якщо немає інтернету?
Шлюз буферизує події; після відновлення зв’язку бот надсилає зведення й позначає відкладені.
Чи є графіки доступності?
Так. Дашборд uptime/інцидентів та експорт у XLS/CSV.
Скільки чатів підтримує бот?
Принаймні один «технічний» і опційно «керівництво». Є «тихі вікна» й ролі.
Візьміть під контроль доступність електроенергії на об’єкті з 2+ вводами.
AVGZ запустить пілот за 3–5 днів: підключимо один об’єкт, налаштуємо фільтри та ескалації, підготуємо перший звіт по uptime.