Задокументировать два принятых ограничения
Отсутствие ретраев webhook — сознательное решение: автономная работа без отправки событий это штатный режим. Пауза мониторинга до 2 минут при старте без сохранённой сети (блокирующий портал WiFiManager в setup()) — принята как есть, с указанием способа лечения, если понадобится. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -267,6 +267,18 @@ STATUS: OK
|
||||
* События, произошедшие без Wi-Fi или при неудачной отправке, не буферизуются
|
||||
и не повторяются — webhook теряется, флаги `mainAlarmSent` /
|
||||
`emergencyActiveSent` выставляются независимо от результата POST.
|
||||
Ретраи и очередь сознательно не реализованы: контроллер рассчитан на работу
|
||||
и без отправки событий, автономность — штатный режим, а не отказ.
|
||||
* **Пауза мониторинга при старте без сохранённой сети.** `wm.autoConnect()`
|
||||
поднимает портал настройки и блокирует `setup()` в цикле ожидания до
|
||||
истечения `setConfigPortalTimeout(120)`. Пока `setup()` не завершён, `loop()`
|
||||
не выполняется: дребезг не считается, аварии не формируются, выходы не
|
||||
переключаются (они остаются в безопасном `LOW`, выставленном до Wi-Fi).
|
||||
В установке, где сеть не настраивается никогда, эти 2 минуты повторяются
|
||||
при каждом включении питания. Принято как есть; при необходимости лечится
|
||||
`wm.setConfigPortalBlocking(false)` + `wm.process()` в `loop()` — с оговоркой,
|
||||
что в неблокирующем режиме `setConfigPortalTimeout` не применяется и гасить
|
||||
портал придётся своим таймером.
|
||||
* Логика аварии — «оба стоят»: остановка одного насоса штатной ситуацией
|
||||
не считается и никак не сигнализируется.
|
||||
* Webhook URL хранится в EEPROM в открытом виде и отдаётся веб-панелью всем,
|
||||
|
||||
Reference in New Issue
Block a user