Power Sentry — городская сеть контроля протечек ЖКХ на LoRaWAN

Методическое пособие: Power Sentry — от узла до городской сети ЖКХ

Уровень: старшая школа / студенты первых курсов. Это вершинный проект курса «Радио своими руками» и материал программы «Инженеры будущего»: ученик проходит путь от одного автономного датчика протечки до инженерного обоснования сети на весь город.

Стенд: три узла на E77-900MBL (STM32WLE5) с настоящим энергосбережением — спят в Stop2 (~единицы мкА), просыпаются только по делу (протечка — по фронту EXTI, климат — по таймеру RTC), шлют короткие LoRaWAN-уплинки в инфраструктуру ChirpStack → Node-RED → TimescaleDB → Grafana. Соль проекта — не датчики, а энергобюджет и масштаб: почему именно энергоэффективность LoRaWAN позволяет одному шлюзу нести десятки тысяч узлов, а узлу — жить годами от батарейки.

Технический разбор городской сети — в CityScale_PowerSentry.md, этапы сборки и «охота на микроамперы» — в Writeup_PowerSentry.md, железо — в README_PowerSentry.md. Python-стенд sentry_city_sim.py делает тезис масштаба измеримым: ползунками задаёте число узлов и частоту уплинков — и видите ёмкость шлюза и срок жизни флота.

Центральный тезис курса, который ученик должен уметь защитить:

Город масштабируется не дальнобойностью радио, а энергоэффективностью протокола. Редкость выхода в эфир даёт одновременно годы жизни от батарейки И десятки тысяч узлов на шлюз — это две стороны одной монеты.

Кто чем пользуется

1. Инженер отвечает за стенд: три узла, разводка, «охота на микроамперы» мультиметром, серверная цепочка до Grafana.
2. Учитель ведёт уроки от энергобюджета одного узла к арифметике города.
3. Методист привязывает энергетику, ёмкость сети и безопасность к программе.

Модуль 1. Энергия как бюджет: почему узел живёт годами

Урок 1. Ток сна решает всё, а не ток передачи

• Тема: заряд как ресурс (мА·ч), баланс мощностей, порядки величин.
• Стенд: sentry_city_sim.py (график срока жизни). Параметры: I_SLEEP, TX-бюджет.

Ход работы. Запустите uv run sentry_city_sim.py. Правый график — срок жизни узла от пары AA против частоты уплинков. Поставьте событийный режим (~2 уплинка/сут) — десятилетия; сдвиньте к «раз в минуту» — год. В нижней сводке смотрите долю бюджета, уходящую на сон.

На графике:

 срок жизни, лет (лог)
   30│●─────── событийный ЖКХ (2/сут): сон = 85% бюджета
     │      ╲___
    1│           ●── раз в минуту: эфир съел батарею
     └──────────────────► уплинков в сутки (лог)

Разбор. Заряд батареи — это бюджет в мА·ч, и он тратится двумя статьями: постоянный ток сна и импульсы активности (замер + передача). У событийного датчика активность редка, поэтому 85% заряда уходит на сон — и весь срок жизни определяется током сна (Stop2, ~2 мкА), а не пиком передачи (~45 мА). Контринтуитивно: передача жрёт в 20 000 раз больше тока, но длится доли секунды дважды в сутки, а сон «жрёт» микроамперы, но 24 часа. Отсюда инженерное правило событийных систем: воюй за ток сна. Один болтливый узел (уплинк в минуту) ломает бюджет — доля эфира растёт в сотни раз, и десятилетия превращаются в год.

Практическое задание. По формуле бюджета (в коде node_life_years) посчитайте на бумаге суточный расход при 2 уплинках/сутки и сравните вклад сна и эфира. Во сколько раз надо участить уплинки, чтобы эфир сравнялся со сном по расходу?

Урок 2. Охота на микроамперы: найти каждого едока

• Тема: измерение малых токов, методика, систематические ошибки прибора.
• Стенд: реальный узел + мультиметр (Writeup, этап 3). Параметр: DEBUG_NO_SLEEP.

Ход работы. По методике врайтапа: мультиметр в разрыв питания, диапазон мА → дождаться [СОН] → переключить на мкА → читать. Дети-детективы заполняют таблицу «едок → мкА → как поймали»: светодиод платы, LDO, неусыплённое радио, внутренняя подтяжка на мокром электроде, висящие входы.

Разбор. Реальный ток стенда узнаётся только измерением — кристалл в Stop2 ест ~1-2 мкА, но отладочная плата MBL добавляет своё (LDO, светодиоды, обвязка ST-Link). Это не баг проекта, а его главный урок: бюджет считает худшего участника цепи. Отдельно — измерительная культура: на диапазоне мкА шунт мультиметра роняет питание импульсной нагрузкой (burden voltage), поэтому TX-пик меряют на мА, а сон — на мкА, и ставят конденсатор 100-470 мкФ, чтобы пики брал он. Почему это важно на масштабе: в городе нет питания в колодце, и лишние 100 мкА «съеденные платой» умножаются на тысячи узлов и годы — становятся вагонами замен батарей.

Практическое задание. Датчик движения RCWL-0516 ест ~3 мА ВСЕГДА, даже при спящем камне. Посчитайте срок жизни такого узла от пары AA и объясните, почему «спящий процессор» его не спасает. Какие три выхода предлагает README?

Модуль 2. Событийная модель: send-on-change и две парадигмы

Урок 3. EXTI против RTC: разбудить по делу или по расписанию

• Тема: прерывания и события, энергоэффективная архитектура, компромисс.
• Параметры: attachInterruptWakeup (EXTI) vs deepSleep(ms) (RTC).

Ход работы. Разбор двух узлов по коду. Узел протечки спит НЕОГРАНИЧЕННО и будится самим датчиком (вода замыкает электрод → фронт на ноге → EXTI). Климат-узел будится таймером раз в период, меряет, решает слать или молчать. На стенде: мокрый палец на электроды мгновенно будит узел протечки из сна (EXTI ВОДА).

Разбор. Две парадигмы пробуждения — соль энергоэффективности. EXTI идеален для редких событий (вода, движение, дверь): средний ток = ток сна, потому что событий может не быть месяцами. RTC — для величин, которые надо мерить регулярно (температура), но и тут спасает send-on-change: слать только изменения плюс редкий heartbeat. «Молчит по расписанию» = «всё стабильно», а не «умер» — за это отвечает heartbeat, и именно его возраст мониторит диспетчер. Каждый несостоявшийся уплинк — это заряд, оставшийся в батарее, И место, освобождённое в эфире для других узлов.

Практическое задание. Почему для датчика протечки выбрана EXTI, а не «проверять воду раз в минуту по таймеру»? Посчитайте разницу в сроке жизни между этими двумя подходами (в стенде: 2 уплинка/сут против пробуждения раз в минуту).

Урок 4. Подтверждение и дребезг: брызги — не потоп

• Тема: фильтрация ложных срабатываний, гистерезис, надёжность решения.
• Параметры: LEAK_CONFIRM_MS, DRY_CONFIRM_MS, LEAK_REPEAT_MS.

Ход работы. На стенде: короткое касание мокрым пальцем (<2 с) → ложная (брызги), никакого уплинка. Держать дольше → подтверждение 2 c → ТРЕВОГА. Убрать → через 30 с сухо → ОТБОЙ.

Разбор. Событие «вода» подтверждается 2 секундами непрерывного контакта: брызги, конденсат, случайная капля не должны поднимать аварийный наряд. Отбой — наоборот, требует 30 с сухости (гистерезис: пороги входа и выхода разные, чтобы не «дребезжать» на границе). Пока мокро — повтор в эфир не чаще раза в 10 минут: duty cycle и батарея дороже паники. Это тот же компромисс «ложные тревоги ↔ пропуски», что в проектах RFCurtain и BeaconRadio, но здесь ценой ошибки становятся реальный наряд бригады и реальный заряд батареи в недоступном колодце.

Практическое задание. Почему подтверждение воды — 2 с, а подтверждение сухости — 30 с (в 15 раз дольше)? Что хуже для города: на 30 с позже увидеть, что подвал высох, или на 30 с раньше снять тревогу с ещё мокрого подвала?

Модуль 3. Масштаб города: арифметика LoRaWAN

Урок 5. Ёмкость шлюза: почему редкость уплинков = десятки тысяч узлов

• Тема: ALOHA, вероятность коллизии, пропускная способность канала.
• Стенд: sentry_city_sim.py (левый график PDR). Параметр: частота уплинков.

Ход работы. В стенде поставьте событийный режим (2 уплинка/сут) и двигайте число узлов — PDR держится у 100% до десятков тысяч. Теперь поставьте «раз в минуту» — PDR обваливается уже на сотне узлов. Один и тот же узел, разная частота эфира.

На графике:

 PDR, %
  100│●●●●●●●●●●●●●●● событийный (2/сут): 95% до ~30 000 узлов
     │              ╲
     │  раз/мин: ●╲__ 95% уже на ~100 узлах
     └──────────────────► узлов на шлюз (лог)

Разбор. Приём в LoRaWAN — это ALOHA: узлы передают когда захотят, два наложившихся во времени кадра гибнут. Доля доставленных кадров ≈ e^(−2G), где G — нагрузка канала, пропорциональная числу узлов × частоту уплинков × airtime кадра. Отсюда ключевой факт масштаба: ёмкость сети упирается не в радио, а в суммарный трафик. Сенсор, шлющий раз в сутки, позволяет 30 000+ узлов на шлюз; раз в минуту — меньше сотни. Разница в 300 раз — это не разное железо, а разная частота выхода в эфир. Вот почему городская сеть ЖКХ обязана быть событийной: только так один шлюз на район несёт десятки тысяч точек контроля.

Практическое задание. По формуле G из кода посчитайте нагрузку канала для 10 000 узлов при 2 уплинках/сут (SF10, airtime 0.29 с, 8 каналов). Оцените PDR по e^(−2G). Во сколько раз упадёт допустимое число узлов, если перейти с SF10 на SF12 (airtime ~1 с)?

Урок 6. ADR и Class A: как протокол экономит за узел

• Тема: адаптивные системы, приёмные окна, разделение ответственности.
• Параметры: setADR, sendReceive (Class A), SF vs airtime.

Ход работы. Разбор по документу CityScale, §3. В стенде двигайте ползунок SF и смотрите, как airtime кадра растёт с SF7 (~40 мс) до SF12 (~1 с) — и как это бьёт по ёмкости и энергии одновременно.

Разбор. Два механизма LoRaWAN работают на энергоэффективность бесплатно для узла. Class A: узел — инициатор, радио включается только на передачу и два коротких приёмных окна после неё; всё остальное время выключено — потому средний ток и решает сон, а не приём. ADR: сеть сама подсказывает каждому узлу минимальный достаточный SF — близкий к шлюзу уходит на быстрый SF7 (короче эфир = меньше энергии И меньше занятого канала), дальний в подвале — на дальнобойный SF12. Меньше SF выгоден дважды: экономит батарею узла и освобождает канал для соседей. Это пример разделения ответственности: тяжёлую работу (выбор SF по качеству линка) делает сервер, узел лишь исполняет — и остаётся простым и экономным.

Практическое задание. Почему на стенде ADR намеренно выключен (setADR(false)), а в городе включён? Что даёт городу переход тысячи узлов с фиксированного SF10 на индивидуальный ADR — по энергии и по ёмкости сети одновременно?

Урок 7. Безопасность инфраструктуры: почему город — не игрушка

• Тема: шифрование, целостность (MIC), защита от повтора, управление ключами.
• Параметры: AES-128/AES-CMAC LoRaWAN, FCnt, ABP vs OTAA.

Ход работы. Разбор по CityScale, §6, в связке с проектом FoxHunter (где однобайтовая подпись ломается брутфорсом за минуты). Противопоставить игрушечную подпись FoxHunter и 4-байтовый MIC LoRaWAN.

Разбор. Сеть, поднимающая аварийные наряды города, — инфраструктура, и её защита обязательна. LoRaWAN несёт её из коробки: полезная нагрузка шифруется AES-128, каждый кадр подписан 4-байтовым MIC (AES-CMAC) — подделать без ключа нереально (2³² вариантов против 256 у игрушечной подписи FoxHunter). Монотонный счётчик FCnt отбивает replay-атаку (тот же механизм, что охотник в FoxHunter применял вручную). На проде — OTAA вместо стендового ABP: сессионные ключи выдаются при подключении, не лежат в прошивке, компрометация одного узла не вскрывает сеть. Приватный ChirpStack держит данные ЖКХ и ключи под контролем города, а не в чужом облаке.

Практическое задание. Сравните защиту FoxHunter (1-байтовая подпись, ручной счётчик) и LoRaWAN (AES-CMAC 4 байта, FCnt, OTAA). Какие три слабости игрушечного протокола закрывает LoRaWAN и каким механизмом каждую? Почему для городской сети это не опционально?

Модуль 4. Экономика и защита проекта

Урок 8. От микроампера до городского бюджета: обоснование сети

• Тема: инженерно-экономическое обоснование, CAPEX/OPEX, окупаемость.
• Материалы: CityScale §1-2, §7 (дорожная карта).

Ход работы. Дискуссия и расчёт. Потери воды в сетях — крупная скрытая статья ЖКХ: поднятая, очищенная, закачанная вода утекает через свищи, а счётчик потребителя её не видит. Раннее обнаружение переводит «прорвало-затопило-экстренная бригада» в «датчик увидел воду ночью — слесарь к открытию». Обсудите: CAPEX сети (шлюзы + узлы, узлы бесплатны в эфире) против экономии на потерях и авариях; почему LoRaWAN бьёт альтернативы не радио, а экономикой (нет абонплаты за SIM × тысячи узлов, нет прокладки кабеля в каждый подвал).

Разбор. Инженер будущего защищает не поделку, а решение с четырьмя опорами: энергобюджет (годы автономии), ёмкость сети (город на нескольких шлюзах), модель безопасности (AES, OTAA, приватная сеть) и экономическое обоснование (окупаемость на сокращении потерь). Все четыре — прямые следствия правильного выбора технологии и событийной архитектуры. Это и есть переход от «датчик мигает» к «система, за которую город платит деньги».

Практическое задание (защита проекта). Подготовьте 5-минутную защиту сети Power Sentry для «города»: формат пакета, бюджет энергии (со своими измеренными числами из урока 2), расчёт ёмкости шлюза (из стенда), модель безопасности, фазы развёртывания. Критерий — воспроизводимость: может ли другая команда по вашему обоснованию повторить расчёт.

Приложение: таблица переноса концепций в индустрию

Заключение

Power Sentry ведёт ученика от одного микроампера тока сна к сети на весь город — и на каждом шаге показывает, что масштаб рождается не из мощности радио, а из энергоэффективности протокола. Событийная модель, за которую воюют в первых уроках ради лишнего года жизни от батарейки, оказывается тем же самым решением, которое позволяет одному шлюзу нести десятки тысяч узлов: редкость уплинков — это и годы, и ёмкость сразу. LoRaWAN складывает энергосбережение, дальность, ёмкость и безопасность в одну технологию, идеально совпадающую с профилем задачи ЖКХ, — и в этом совпадении, а не в отдельном рекордном параметре, и состоит инженерное решение. Стенд sentry_city_sim.py делает весь этот тезис измеримым: подвигайте ползунки и увидите своими глазами, где проходит граница между «датчик на столе» и «инфраструктура города».

📊 Презентация проекта: Power Sentry — городская сеть ЖКХ на LoRaWAN

«Инженеры будущего»: от одного датчика до сети на весь город

Слайд 1: Задача — протечки как статья городского бюджета

• Проблема: потери воды в сетях ЖКХ — крупная скрытая статья расходов: поднятая, очищенная, закачанная вода утекает через свищи, а счётчик потребителя её не видит.
• Решение: тысячи дешёвых автономных датчиков в подвалах и колодцах, годы без обслуживания, мгновенная тревога диспетчеру.
• Три требования: автономность годами, связь сквозь бетон, масштаб на город.
• Тезис проекта: город масштабируется не дальнобойностью радио, а энергоэффективностью протокола LoRaWAN.

Слайд 2: Почему LoRaWAN, а не Wi-Fi / сотовая / провод

• Wi-Fi — умирает за часы (десятки мА), не пробивает стены.
• Сотовая (NB-IoT) — ближе, но абонплата за SIM × тысячи узлов = OPEX.
• Провод — идеально по связи, но CAPEX прокладки кабеля в каждый подвал.
• LoRaWAN — годы-десятилетия автономии, связь сквозь бетон, свой шлюз на район, узлы бесплатны в эфире. Побеждает совпадением с профилем задачи: датчик молчит месяцами и говорит редко и коротко.

Слайд 3: Три механизма энергоэффективности LoRaWAN

• Class A: узел-инициатор — радио включается только на передачу + два коротких приёмных окна; средний ток решает сон, а не приём.
• ADR: сеть сама подсказывает минимальный SF под каждый узел — короче эфир = меньше энергии И меньше занятого канала. Бесплатно, работу делает сервер.
• Событийная модель + send-on-change: датчик протечки будит камень только по воде (EXTI); климат шлёт только изменения + редкий heartbeat → 1-2 уплинка в сутки.

Слайд 4: Арифметика масштаба — редкость уплинков решает всё

• Ёмкость шлюза (ALOHA, PDR ≈ e^(−2G)): событийный ЖКХ (~2 уплинка/сут) → ~30 000 узлов на шлюз; наивный «раз в минуту» → ~100 узлов. Разница ×300 — та же плата, разная частота эфира.
• Срок жизни узла: при 2 уплинках/сут 85% заряда уходит на сон → десятилетия по арифметике (раньше умрёт саморазряд); «раз в минуту» → год.
• Вывод: ёмкость и автономия растут от ОДНОГО решения — выходить в эфир редко.
• Стенд sentry_city_sim.py делает это измеримым: ползунки → PDR и срок жизни.

Слайд 5: Архитектура, безопасность, дорожная карта

• Сеть города: тысячи узлов → резервирование шлюзов (кадр слышат 2+, сервер дедуплицирует — лечит ALOHA-коллизии) → ChirpStack (ADR, дедуп) → диспетчер.
• Безопасность из коробки: AES-128 шифрование + 4-байтовый MIC (AES-CMAC) + счётчик FCnt против replay + OTAA на проде + приватный ChirpStack. Это «взрослое» решение той задачи, где игрушечная подпись FoxHunter ломается за минуты.
• Фазы: пилот (район, ~50 узлов) → район (ADR, OTAA, тысячи) → город (сеть шлюзов, планирование покрытия методом WarWalk) → развитие (давление, уровень, теплотрассы).
• Защита проекта: энергобюджет + ёмкость + безопасность + окупаемость — четыре опоры инженерного решения, за которое город платит деньги.

Power Sentry: городская сеть контроля протечек ЖКХ на LoRaWAN

Инженерный документ проекта «Инженеры будущего»

Стендовый Power Sentry — три узла на столе. Этот документ отвечает на вопрос, ради которого проект и затевался: как из трёх узлов вырастает сеть на весь город — и почему технологией, которая это позволяет, оказывается именно LoRaWAN, а не Wi-Fi, не сотовая связь и не проводка. Тезис один и он технический:

Город масштабируется не «дальнобойностью» радио, а энергоэффективностью протокола. Редкость выхода в эфир (событийная модель) одновременно даёт годы жизни от батарейки И десятки тысяч узлов на один шлюз. Это две стороны одной монеты, и обе — прямое следствие того, как устроен LoRaWAN.

Числовые утверждения этого документа воспроизводятся стендом sentry_city_sim.py.

1. Задача: протечки как статья городского бюджета

Потери воды в сетях водоснабжения — одна из крупнейших скрытых статей расходов ЖКХ. Значительная доля поднятой, очищенной и закачанной в сеть воды не доходит до потребителя — утекает через свищи, старые стыки, затопленные подвалы и техэтажи. За неё уже заплачено энергией насосов и реагентами очистки, а счётчик потребителя её не видит. Раннее обнаружение переводит аварию из категории «прорвало, затопило, экстренная бригада» в категорию «датчик в подвале дома №12 увидел воду в 3:40, диспетчер выслал слесаря к открытию» — и разница в деньгах между этими двумя сценариями и есть экономическое обоснование сети.

Инженерная формулировка: нужна сеть из тысяч дешёвых автономных датчиков в подвалах, тепловых пунктах, колодцах и на вводах, каждый из которых годами работает без обслуживания и мгновенно сообщает диспетчеру о появлении воды. Три требования, которые из этого следуют, и определяют выбор технологии.

2. Почему LoRaWAN, а не альтернативы

Сравнение — не «что лучше вообще», а «что удовлетворяет трём требованиям сразу».

Ключевое преимущество LoRaWAN для города — не техническое превосходство в вакууме, а совпадение с профилем задачи: датчик протечки молчит месяцами и говорит редко и коротко. Ровно в этом режиме LoRaWAN недосягаем: свой шлюз (разовый CAPEX), нулевая абонплата за узел, годы от батарейки, связь сквозь бетон. Абонентская сотовая связь проигрывает не радио, а экономикой (SIM × тысячи узлов); Wi-Fi — энергией и покрытием; провод — стоимостью монтажа.

3. Три механизма LoRaWAN, которые дают энергоэффективность

Именно они превращают «датчик с радио» в «узел, живущий годами». Все три уже реализованы в PowerSentry.ino — здесь показано, ЧТО в протоколе делает их возможными.

3.1. Class A: приёмник открывается только после передачи

LoRaWAN Class A — самый экономный класс. Узел инициатор: он спит, просыпается, передаёт уплинк и лишь затем на короткое время открывает два приёмных окна (RX1/RX2) на случай ответа сервера. Всё остальное время радио выключено. Именно поэтому средний ток определяется сном, а не приёмом: у датчика протечки нет «постоянного слушания эфира», которое съело бы батарею за дни. Стендовый узел реализует это буквально — node.sendReceive() в Class A, между событиями LowPower.deepSleep() (Stop2).

3.2. ADR: сеть сама выбирает минимальный SF под каждый узел

Adaptive Data Rate — сервер по качеству принятых кадров подсказывает каждому узлу минимально достаточный коэффициент расширения SF. Узел близко к шлюзу с чистым линком уходит на SF7 (airtime кадра ~40 мс), дальний в глубоком подвале — на SF10-12 (до ~1 с). Меньше SF → короче эфир → меньше энергии на кадр И меньше занятого канала. ADR — это одновременно энергосбережение и увеличение ёмкости сети, и он бесплатен: работу делает сервер. (На стенде ADR выключен ради предсказуемости отладки — node.setADR(false); в городе его включают, и это отдельная статья экономии.)

3.3. Duty cycle и событийная модель: редко — значит можно много

Регулятор ограничивает долю времени в эфире (в поддиапазоне 868.1 — 1%). Это не помеха, а дисциплина, которая и делает сеть плотной: раз каждый узел обязан молчать 99% времени, тысячи узлов уживаются в одном канале. Проект использует это как принцип проектирования, а не как ограничение: событийная модель (датчик протечки будит камень только когда появилась вода — EXTI) плюс send-on-change для периодических датчиков (слать только изменения + редкий heartbeat). В сумме — 1-2 уплинка в сутки на узел вместо непрерывного потока.

4. Арифметика масштаба: почему редкость уплинков решает всё

Здесь тезис становится числом. Две величины, обе — следствие редкости уплинков.

4.1. Ёмкость шлюза (сколько узлов он вынесет)

Шлюз слушает 8 каналов по 125 кГц. Приём в LoRaWAN — это по сути ALOHA: узлы передают когда захотят, два наложившихся во времени кадра на одном канале и SF гибнут. Для ALOHA доля успешно принятых кадров ≈ e^(−2G), где G — нагрузка канала в Эрлангах (средняя доля занятости уязвимого окна). G растёт с числом узлов и с частотой уплинков:

 G ≈ (узлов × уплинков_в_сутки / 86400 / 8_каналов) × airtime_кадра

Подставим airtime SF10 (10-байтовый кадр ≈ 0.29 с) и порог рабочего качества 95% PDR:

Разница между первой и последней строкой — в 300 раз, и это не разные радио, а разная частота выхода в эфир одного и того же узла. Отсюда практический вывод для города: один шлюз на район покрывает десятки тысяч точек контроля — но только пока узлы событийные. Стоит сделать их «болтливыми» — и та же сеть схлопывается до сотни.

4.2. Срок жизни узла (сколько лет от батарейки)

Бюджет заряда пары AA (~2500 мА·ч): ток сна Stop2 (~2 мкА) плюс активность на каждый уплинк (TX ~45 мА × ~0.3 с эфира + замер). При 2 уплинках в сутки:

 сон:   24 ч × 2 мкА                 ≈ 48   мкА·ч/сут   (≈85% бюджета)
 эфир:  2 × (0.3 с × 45 мА)/3600     ≈ 8    мкА·ч/сут
 итого ≈ 56 мкА·ч/сут → по арифметике десятилетия

По расчёту выходят десятилетия — на практике раньше умрёт саморазряд батарейки (поэтому честная цифра проекта — «первым сдаётся не бюджет, а химия элемента»). Но вывод неизменен: в событийной системе срок жизни определяет ток сна, а не ток передачи — 85% бюджета уходит на сон. Сделайте узел болтливым (уплинк в минуту) — и жизнь падает с десятилетий до года: доля эфира вырастает в сотни раз.

Обе величины — ёмкость и жизнь — растут от одного и того же решения: выходить в эфир редко. Это и есть «вся мощь LoRaWAN для энергоэффективности», выраженная числом.

5. Архитектура городской сети

  РАЙОН А                        РАЙОН Б
  [тысячи узлов протечки]        [тысячи узлов]
        │ LoRaWAN 868.1                │
        ▼                              ▼
    [шлюз А]  ────┐            ┌──── [шлюз Б]      резервирование: узел слышат
    [шлюз А']─────┼── backhaul ┼──── [шлюз Б']     2+ шлюза → кадр не теряется
                  ▼            ▼
              [сетевой сервер ChirpStack]   дедупликация, ADR, безопасность
                  │
                  ▼
        [Node-RED] декодер + маршрутизация тревог
                  │
          ┌───────┼─────────┐
          ▼       ▼         ▼
     [TimescaleDB] [диспетчер] [аварийная бригада]
      история      Grafana     Telegram/наряд

Что даёт масштаб по сравнению со стендом:

• Резервирование приёма шлюзами. В городе узел почти всегда слышат 2+ шлюза; сетевой сервер дедуплицирует кадр. Это лечит те самые ALOHA-коллизии из §4.1: кадр, погибший на одном шлюзе от наложения, принят соседним.
• ADR включён. Каждый узел на своём минимальном SF — экономия энергии и канала по всему флоту (§3.2).
• Диспетчерский слой не меняется. EAV-схема readings и логика тревог из стенда масштабируются добавлением строк, а не миграцией: новый узел = новый node_id.
• Мониторинг «молчания». Главный индикатор здоровья флота — возраст последнего heartbeat каждого узла (в стенде уже есть панель «молчание узлов»). На тысячах узлов это автоматизируется alert-правилами.

6. Безопасность на масштабе города

Один датчик в подвале — игрушка; сеть, управляющая аварийными нарядами города, — инфраструктура, и её безопасность обязательна. LoRaWAN несёт её в себе, и это ещё один довод в его пользу против самодельных протоколов (см. соседний проект FoxHunter, где показано, как ломается наивная однобайтовая подпись).

• Шифрование и целостность из коробки. LoRaWAN шифрует полезную нагрузку (AES-128, AppSKey) и подписывает каждый кадр 4-байтовым MIC (AES-CMAC, NwkSKey) — подделать или прочитать кадр без ключа невозможно. Это «взрослое» решение той задачи, которую FoxHunter решает игрушечной подписью специально, чтобы показать разницу.
• Защита от повтора — счётчик кадров. Монотонный FCnt в каждом кадре: сервер отвергает повтор старого кадра. (Отсюда практическая деталь стенда: после сброса питания узла FCnt обнуляется — на проде сессию сохраняют в EEPROM, иначе сервер начнёт молча выкидывать кадры. Это уже отмечено как TODO в прошивке.)
• OTAA вместо ABP на проде. Стенд использует ABP (ключи зашиты — просто для отладки). Город разворачивают на OTAA: узел получает сессионные ключи при подключении, ключи не лежат в прошивке, компрометация одного узла не вскрывает сеть.
• Приватная сеть. Свой ChirpStack + свои шлюзы = данные ЖКХ не уходят в чужое облако; ключи и трафик под контролем города.

7. Дорожная карта развёртывания (фазы)

1. Пилот (1 район, 1 шлюз, ~50 узлов). Проверить проникновение в реальные подвалы (SF, запас линка), откалибровать пороги протечки под местную воду, обкатать диспетчерский сценарий «вода → наряд → устранение». Стенд Power Sentry — прямой прообраз этой фазы.
2. Район целиком (1-2 шлюза, тысячи узлов). Включить ADR, перейти на OTAA, ввести резервирование шлюзов, настроить alert-правила на «молчание» и низкий заряд.
3. Город (сеть шлюзов). Единый ChirpStack, планирование размещения шлюзов по покрытию (цифровые двойники/замеры RSSI — методика из соседнего проекта WarWalk!), интеграция с аварийно-диспетчерской службой ЖКХ.
4. Развитие. Те же узлы и сеть — под давление в сети (манометр), уровень в резервуарах, температуру теплотрасс: архитектура SensorDriver и EAV-схема это уже предусматривают. Один флот — много городских задач.

8. Как это связано с остальным курсом

Power Sentry — вершина линейки «Радио своими руками»: он собирает воедино всё, что рождалось в предыдущих проектах, и выводит на реальную городскую задачу.

Проект «Инженеры будущего» — это момент, когда школьный стенд из трёх плат предъявляется как прообраз настоящей городской инфраструктуры, и ученик защищает не поделку, а инженерное решение с бюджетом энергии, расчётом ёмкости, моделью безопасности и экономическим обоснованием. Ровно этого и ждут от инженера.

POWER SENTRY — врайтап: этапы, проверки, охота на микроамперы

Стиль тот же, что в маячке: этап = код + проверка + маркерные строки в логе. Этап не принят — дальше не идём. Маркер сборки: === POWER SENTRY СБОРКА-1.

Этап 0 — стенд и разводка (без прошивки)

Собрать три узла по README. Отдельно проверить омметром датчик протечки: сухие электроды = обрыв, замкнутые мокрым пальцем = единицы-десятки кОм (да, кОм — вода из-под крана проводит хорошо; резистор 4.7 МОм всё равно сверху, делитель даёт уверенный LOW). Пометить маркером контакт 9 (PB0).

Проверка: визуально + омметр. Электрод на PA1, резистор 4.7 МОм на 3.3V, AHT20 питается с PB2, не с шины.

Этап 1 — каркас без сна (DEBUG_NO_SLEEP 1, DEMO_FAST 1)

Прошить все три узла со своими NODE_ID/SENSOR_*/ключами. Сон подменён delay — консоль живёт непрерывно, отлаживаем ЛОГИКУ, не питание.

Проверка (маркеры):

• init: бипы 1-2-3, в консоли [УЗЕЛ] id=... тип=..., [ДАТЧИК] ... OK, [OK] радио готово. Писк 400/400 = смотреть код в [FATAL].
• узел протечки: [TX] FPort=10 ... flags=0x28 (heartbeat + первый старт) сразу после включения; мокрый палец на электроды → [ВОДА?] подтверждение 2 c... → [ТРЕВОГА] ПРОТЕЧКА! + сирена → убрать палец → через ~30-60 c [ОТБОЙ]. Короткий палец (<2 c) → ложная (брызги) и никакого TX.
• климат-узлы: [ЗАМЕР] T=... RH=... раз в 30 c; при стабильном климате — -> без изменений, МОЛЧУ; дыхнуть на датчик → -> изменилось, шлю; фен → -> ПОРОГ ПРЕВЫШЕН, тревога (FPort=20), остыло → отбой.
• кнопка PA0 на каждом узле: [ТЕСТ] кнопка... — событие без воды и фена.
• на шлюзе/в Node-RED debug видны уплинки всех трёх DevAddr.

Ловушка этапа: если [TX] ошибка с руганью на duty cycle — DEMO-интервалы плюс частые изменения могут упереться в лимит эфира; это правильное поведение, узел просто подождёт (лог RadioLib это скажет кодом).

Этап 2 — настоящий сон (DEBUG_NO_SLEEP 0)

Тот самый «шаг 3» маячка. Главная перемена в голове: консоль между пробуждениями МОЛЧИТ — это норма, а не зависание. Отличаем сон от смерти по чекпоинтам: узел жив, если события его будят.

Проверка (маркеры):

• [СОН] Stop2 на N c... → тишина → [ПРОБУЖДЕНИЕ #k] причина: RTC таймер строго по расписанию (климат: 30 c).
• узел протечки: в тишине сна мокрый палец будит МГНОВЕННО: [ПРОБУЖДЕНИЕ #k] причина: EXTI ВОДА. Кнопка — EXTI кнопка (тест).
• wake_counter в каждом пакете растёт на пульте «пилой» — перезагрузка узла видна как срыв пилы в ноль (плюс флаг FIRST_BOOT).
• ЕСЛИ после первого deepSleep консоль больше не печатает никогда, а бипы идут — UART не пережил Stop2 на вашей версии ядра: добавить Serial.begin(115200); первой строкой после LowPower.deepSleep(...) в goToSleep(). Известная особенность, лечится одной строкой.
• ЕСЛИ первый TX после сна падает с ошибкой — смотреть строку реанимация: activateABP + повтор: одна реанимация зашита. Если и повтор не уходит стабильно — прислать код ошибки, это следующий слой отладки.
• ABP и счётчики кадров: RAM в Stop2 жива, сессия переживает сон. НО сброс питания обнуляет FCnt — сервер начнёт молча выкидывать кадры. На стенде: разрешить в настройках сервера «reset frame counters» (как у маячка, EEPROM-сохранение сессии — тот же TODO).

Этап 3 — ОХОТА НА МИКРОАМПЕРЫ (гвоздь программы)

Цель: измерить реальный ток сна и найти всех едоков. Дети работают детективами: каждая находка — конкретный виновник и число.

Методика измерения — читать до, а не после:

1. Мультиметр В РАЗРЫВ питания (минус батареи → COM, плюс → узел), режим мА. НИКОГДА не начинать с диапазона мкА: TX-пик ~45 мА сожжёт предохранитель диапазона мкА или просадит питание burden-напряжением так, что камень уйдёт в ресет прямо при передаче. Порядок: диапазон мА → дождаться [СОН] → переключить на мкА → читать → ПЕРЕД пробуждением вернуть мА.
2. Burden voltage: на диапазоне мкА внутренний шунт мультиметра — сотни Ом; импульсная нагрузка через него роняет питание. Страховка: электролит 100-470 мкФ параллельно питанию узла (пики берёт конденсатор). Честный способ мерить и сон, и пики одним прибором — шунт 10 Ом + вольтметр/ осциллограф на нём, но для урока хватает «мкА только во сне».
3. USB отключить! Питание только от батареи: подключённый ST-Link/USB меняет картину полностью.

Лестница едоков — искать в таком порядке (типичные величины):

Проверка этапа: заполненная детьми таблица «едок → мкА → как поймали» и итоговое число тока сна стенда. Абсолютное значение не нормируется (оно зависит от платы!) — принимается ПОНИМАНИЕ: кто ест, сколько, и что нужно сделать, чтобы дойти до микроампер кристалла. Финал — расчёт срока жизни от пары AA по формуле из README со СВОИМИ измеренными числами.

Этап 4 — пульт: Node-RED + Grafana

Импортировать flow и дашборд (README, раздел «Пульт»). Прогнать сценарии:

Проверка:

• debug-нода после декодера показывает разобранные поля (t, rh, batt, wake, alarm) и теги node_id/node_type; битый пакет (испортить байт в инжекторе) ловится по CRC и в базу не идёт — в debug warning CRC!.
• палец на электроды → на дашборде лента протечки краснеет, в ветке тревог сообщение «УЗЕЛ 1 ПРОТЕЧКА»; высохло → отбой и лента зеленеет.
• фен на узел 2 → график температуры взлетает, тревога порога; климат стабилен → графики ровные, точки редкие (send-on-change видно ГЛАЗАМИ: плотность точек = изменчивость среды — красивый разговор с детьми).
• обесточить любой узел → возраст последнего пакета на пульте растёт; «узел молчит дольше 2×heartbeat» = диспетчерский повод для тревоги (в Grafana — alert rule на возраст, настроить по вкусу).

Этап 5 (бонусы)

Четвёртый узел по архитектуре SensorDriver (свет/движение — см. README, там же ловушка RCWL про 3 мА); EEPROM-сохранение FCnt (закрывает TODO маячка); Standby вместо Stop2 для протечки (сотни нА, но старт «с нуля» при каждом событии — обсудить цену); downlink «пискни» для поиска узла.

POWER SENTRY — стенд «диспетчерский пульт» на микроамперах

Три автономных узла-датчика на E77-900MBL (STM32WLE5) шлют LoRaWAN-уплинки в существующую инфраструктуру (шлюз → ChirpStack → Mosquitto → Node-RED → TimescaleDB → Grafana). Соль проекта — не датчики, а энергобюджет: узлы живут в Stop2 (~единицы мкА на кристалле) и просыпаются только по делу.

 [узел 1 ПРОТЕЧКА]──┐  событие (EXTI)                       ┌──────────┐   ┌───────────┐
 [узел 2 ТЕМПЕРАТУРА]─┼─ LoRaWAN 868.1 → шлюз → ChirpStack →│ Node-RED │──→│TimescaleDB│──→ Grafana
 [узел 3 ВЛАЖНОСТЬ]──┘  таймер (RTC)          (MQTT, json)  │ декодер  │   │ readings  │   «пульт»
                                                            │ тревоги  │   │ (EAV)     │
                                                            └────┬─────┘   └───────────┘
                                                                 └→ уведомления

Состав комплекта

Железо и разводка

Библиотеки: RadioLib 7.7.1, STM32LowPower (+ зависимость STM32RTC). Ядро — официальное STM32.

Узел 1 — протечка (событийный). Два электрода (полоски фольгированного текстолита / оголённые концы): один → GND, второй → PA1. Между PA1 и 3.3V — внешний резистор 4.7 МОм. Почему не внутренняя подтяжка: она ~40 кОм, и мокрые электроды тянули бы ~80 мкА всё время потопа; через 4.7 МОм — меньше 1 мкА, и только пока мокро. Это первый экспонат «охоты на микроамперы».

Узлы 2 и 3 — климат (периодические). AHT20: SCL → PB6 (конт. 24), SDA → PB7 (конт. 25), GND → GND, а VCC → PB2 (не на шину 3.3V!). Питание датчика от ноги GPIO — это power gating: датчик существует только на время замера. Для AHT20 (µА в покое) это почти символично, но приём обязателен архитектурно — см. «расширение» ниже.

Общее: buzzer PB5 (конт. 23), тест-кнопка PA0 (конт. 27) → GND — симулирует событие (протечку / внеочередной замер) без воды и фена.

Запреты те же, что всегда: PB0 = VDDTCXO (не GPIO), PA2/PA3 = консоль.

Прошивка трёх узлов

В шапке скетча правится только конфиг-блок:

Каждому узлу — свои ABP-ключи (зарегистрируй три девайса, DevAddr = база + NODE_ID). DEMO_FAST 1 — стендовые интервалы (heartbeat 2 мин, замер 30 с), для боевого режима поставить 0 (сутки / 10 мин). DEBUG_NO_SLEEP 1 — первый прогон: сон подменён delay, консоль живёт непрерывно; ток в этом режиме мерить бессмысленно.

Две парадигмы пробуждения (ядро урока)

EXTI (событийная), узел протечки. Камень спит неограниченно; будит его сам датчик — фронт на ноге PA1, когда вода замыкает электрод на GND. Средний ток определяется ТОЛЬКО сном: событий может не быть месяцами. Логика: подтверждение 2 с (брызги ≠ потоп) → тревога FPort 20 + сирена → пока мокро, перепроверка раз в минуту и повтор в эфир раз в 10 мин (duty cycle и батарея дороже паники) → сухо 30 с → отбой.

RTC (периодическая), климат-узлы. Таймер будит раз в период; узел подаёт питание на датчик, меряет, снимает питание и решает: send-on-change — слать только если |ΔT| ≥ 0.3 °C или |ΔRH| ≥ 2 %, либо пришло время heartbeat (каждый N-й замер), либо пересечён аварийный порог. «Молчит по расписанию» = «всё стабильно», а не «умер» — за это отвечает heartbeat, и именно его возраст мониторит пульт.

Энергобюджет — арифметика для урока

Ток сна кристалла в Stop2 ~1–2 мкА, радио во сне <1 мкА. Активность: замер AHT20 ~1 мА × 0.2 с; TX SF10 ~45 мА × 0.4 с ≈ 5 мкА·ч на пакет. Для климат-узла (замер раз в 10 мин, TX ~20 раз в сутки):

Пара AA (~2500 мА·ч) — десятки лет по арифметике, то есть на практике первым умрёт саморазряд батарейки. Вывод, ради которого проект и затевается: в событийных системах всё решает ток сна, а не ток передачи.

Честная оговорка про плату MBL: микроамперы ест кристалл, а не отладочная плата целиком — на MBL живут LDO, светодиоды и обвязка ST-Link, и они дадут свои сотни мкА или больше. Сколько именно — заранее не скажу, это и есть измерительный этап врайтапа («охота на микроамперы»): найти и посчитать каждого едока, а для рекордных цифр — питать сам модуль в обход лишнего. Реальный итог стенда узнаётся только мультиметром.

Расширение: свет, движение, пыль (заложено в архитектуру)

Новый узел = свой TYPE_* (4 = свет, 5 = движение, 6 = пыль уже зарезервированы в payload и декодере) + инициализация + блок в loop по одной из двух парадигм:

• Микроволновый датчик движения RCWL-0516 — событийный: OUT → свободный GPIO, attachInterruptWakeup, дальше калька с протечки. Ловушка, ради которой он и интересен: сам RCWL ест ~3 мА всегда — спящий камень его не спасает. Урок: бюджет считает худшего участника цепи; выходы — дежурное питание датчика отдельно, скважность (гейтить сам датчик по расписанию) или выбор другого сенсора.
• Освещённость — оба варианта сразу: BH1750 по I2C периодически (калька с климата, power gating тот же), или фоторезистор + компаратор → EXTI («стало темно» будит камень) — красивое сравнение двух парадигм на одной физике.
• Пыль (PMS5003/GP2Y) — периодический, но вентилятор/нагреватель = десятки-сотни мА: гейтить MOSFET-ключом, не ногой GPIO (предел ноги ~20 мА). Плюс прогрев 30 с перед честным замером — статья бюджета, которую дети должны найти в расчёте сами.

Payload (менять синхронно с декодером в node-red-flow.json!)

10 байт LE: [0] node_id, [1] node_type (1 протечка / 2 темп / 3 влажн / 4 свет / 5 движение / 6 пыль), [2] flags (б0 тревога активна, б1 начало тревоги, б2 отбой, б3 heartbeat, б4 low_batt, б5 первый старт), [3..4] value1 int16 (T×100 или wet 0/1), [5..6] value2 int16 (RH×100), [7] батарея %, [8] wake_counter (uint8 с обёрткой — на пульте видна «пила» активности и перезагрузки), [9] CRC8 (poly 0x07). FPort 10 = телеметрия, FPort 20 = тревога/отбой. Значение −32768 в value = «замер не удался», узел жив, датчик — нет.

Пульт: Node-RED + Grafana

0. В ChirpStack зарегистрировать три ABP-девайса (DevAddr = база + NODE_ID из скетча), в настройках девайсов разрешить сброс frame counters (сессия в RAM — сброс питания узла обнуляет FCnt; EEPROM-сохранение — TODO, как у маячка).
1. Импортировать node-red-flow.json как новую вкладку рядом с эталонными. После импорта: mqtt-ноду перевесить на существующий конфиг брокера (креды юзера nodered вводятся руками, как в README-flow), postgresql-ноду — на существующий конфиг БД (роль nodered, INSERT-only — flow пишет только параметризованным INSERT ... VALUES (now(), $1, 'lorawan', $3, $4) в readings, никакой конкатенации). Внутри function-ноды заполнить NODE_ID_MAP (DevEUI → sentry_leak/sentry_temp/sentry_humi) — без записи в карте узел пишется как sentry_<id> из payload. Белый список метрик ALLOWED_METRICS — тот же приём, что в эталоне: новые поля прошивки молча отбрасываются, пока их явно не разрешили.
2. Импортировать grafana-dashboard.json, при импорте указать существующий датасорс grafana-postgresql-datasource-iot (роль grafana_ro). Панели: «молчание узлов» (секунды с последнего пакета — главный индикатор «узел жив»; пороги в панели выставлены под DEMO-интервалы, для боевых поменять на 2×heartbeat = 172800 c), батареи, лента протечки, T/RH (плотность точек = send-on-change глазами), «пила» wake_counter (срыв в ноль = перезагрузка), тревоги.
3. Ветка тревог в flow заканчивается debug-узлом — вместо него подключается telegram/e-mail нода по вкусу. Для проверки без железа в flow есть inject «ТЕСТ: тревога протечки».
4. EAV-схема readings расширения не требует: новый тип узла = новые значения node_id/metric, ни одной миграции.

Статус

Обвязка радио и LoRaWAN-путь — 1:1 из проверенного маячка; связка Stop2 + RadioLib + AHT20, декодер и дашборд написаны для этого стенда и обкатываются по этапам врайтапа — прогон этапов обязателен, первый — с DEBUG_NO_SLEEP 1.