Рыбхоз: кислород в прудах и тревога ночью — что будет, если связь с облаком пропала

MAATRIX

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

Почему падение кислорода ночью — это счёт на часы, а не на дни

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

При высокой плотности посадки (что типично для товарного выращивания) запас кислорода в толще воды невелик, и его падение до критичных для конкретного вида значений может занять не сутки, а несколько часов. Конкретные пороговые значения зависят от вида рыбы, температуры, стадии роста и плотности посадки — это епархия ихтиопатолога и действующих нормативов для вашего хозяйства, и мы не будем выдумывать универсальные цифры. Важно другое: это не постепенный процесс, растянутый на дни, который можно заметить утром и спокойно исправить. Замор в товарном пруду при неблагоприятном стечении обстоятельств может произойти за одну ночь, и цена ошибки — не просроченный отчёт, а гибель партии рыбы, на выращивание которой ушли месяцы.

Типовая схема облачного мониторинга и её слабое место

Стандартная поставка «умного» рыбхоза выглядит так: датчик растворённого кислорода в пруду → локальный контроллер вендора → передача данных по Wi-Fi или сотовой сети в облако производителя → облако считает пороги и решает, отправлять ли тревогу → тревога уходит вам push-уведомлением, SMS через шлюз вендора или звонком через его сервис. Схема удобна, пока всё звено цело. Проблема в том, что это именно звено — цепочка из нескольких внешних зависимостей, и достаточно разрыва в любом месте, чтобы тревога не дошла:

• пропал интернет на площадке (обрыв провода, авария у провайдера, сбой роутера);
• у вендора легло облако или конкретный сервис отправки уведомлений — от вас это никак не зависит и вы об этом не узнаете заранее;
• проблема на стороне SMS-шлюза или push-сервиса вендора — доставка уведомлений сторонним сервисом не гарантирована с той же надёжностью, с какой вам обещали в презентации;
• контроллер вендора завис или перезагрузился и не смог переподключиться.

Ни один пункт по отдельности не выглядит катастрофой — обычно это несколько часов простоя связи, которые для большинства применений вообще незаметны. Для пруда с рыбой ночью это именно то окно, в которое всё решается.

Что происходит в пруду, пока «нет связи с сервером»

Здесь есть тонкость, которую часто упускают на этапе внедрения: далеко не каждая облачная система умеет отличать «данных нет, потому что пропала связь» от «всё в порядке». Если логика тревоги в облаке настроена только на превышение порога по последнему полученному значению, а данные перестали поступать вовсе — тревога может просто не сработать, потому что формально порог не был нарушен по факту получения данных. В интерфейсе в лучшем случае появится тихая строчка вида «последние данные час назад», но её должен кто-то заметить, а ночью это некому — персонал спит, а телефон не звонит именно потому, что канал уведомления сам зависит от того же самого интернета, который и пропал.

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

Локальный сервер на площадке: тревога, которая не зависит от интернета

Решение не в том, чтобы отказаться от удобства цифрового мониторинга и вернуться к ручным замерам, а в том, чтобы вынести критичную логику «прочитать датчик → сравнить с порогом → поднять тревогу» на площадку, туда, где стоят пруды, и сделать её независимой от внешнего интернета. Общий принцип:

1. Датчики кислорода передают показания не напрямую в облако вендора, а на локальный сервер (мини-ПК, промышленный контроллер или обычный сервер, физически стоящий в помещении на площадке рыбхоза).
2. Локальный сервер сам считает пороги — без похода в интернет и без ожидания ответа от чужого дата-центра.
3. При превышении порога сервер запускает тревогу через каналы, которые физически не требуют интернета: сирену/маяк через релейный модуль, автодозвон по обычной телефонной линии, включение резервного аэратора через силовое реле.
4. Уведомление в Telegram или push на телефон остаётся — но как дополнительный, а не единственный канал: если интернет есть, вы получите его быстро; если интернета нет, сирена и автодозвон всё равно сработают.

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

Из чего это собирается технически

Ниже — рабочая схема сборки, без экзотики и без привязки к одному вендору датчиков.

Датчик. Оптический или гальванический датчик растворённого кислорода с открытым локальным выходом — аналоговый сигнал 4–20 мА или цифровой RS-485/Modbus. Это принципиально важный выбор на старте: датчик, который умеет отдавать показания только в закрытое облако производителя без локального протокола, для этой схемы не подходит в принципе, сколько бы у него ни было других плюсов.

Шлюз. Modbus-RTU-to-Ethernet конвертер (или LoRa-шлюз, если пруды разнесены далеко друг от друга и тянуть кабель нецелесообразно) собирает показания с нескольких точек и отдаёт их в локальную сеть.

Локальный сервер. Здесь подойдёт связка Node-RED или Home Assistant поверх Linux — обе платформы умеют опрашивать Modbus/MQTT и запускать локальные автоматизации без выхода в интернет. Пример простой логики на Node-RED в псевдокоде потока:

[Modbus Read: регистр О2, пруд №1] 
  -> [Function: если значение < порог_тревоги]
       -> [GPIO Out: реле сирены = ON]
       -> [GPIO Out: реле аэратора = ON]
       -> [Exec: локальный автодозвон через GSM-модем]
       -> [MQTT Publish: событие в лог]

Для минимального варианта без Node-RED достаточно короткого Python-скрипта, который раз в 1–2 минуты опрашивает Modbus-регистр и при превышении порога дёргает GPIO/USB-реле:

import time
from pymodbus.client import ModbusTcpClient

client = ModbusTcpClient('192.168.10.20')
POROG = float(config['alarm_threshold'])  # берётся из настроек хозяйства, не из статьи

while True:
    result = client.read_holding_registers(0, 1, unit=1)
    o2_value = result.registers[0] / 100.0
    if o2_value < POROG:
        trigger_relay('siren')
        trigger_relay('aerator_backup')
        send_local_sms(f'Пруд 1: О2 {o2_value} ниже порога')
    time.sleep(60)

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

Каналы оповещения без интернета. GSM/SMS-модуль (например, на базе SIM800/SIM7600) даёт канал через сотовую сеть — она физически не зависит от вашего проводного интернета или Wi-Fi, хотя сама тоже не гарантирована на 100%. Проводной автодозвонщик на аналогичную линию, если она есть на площадке, — ещё один независимый канал. Сирена и включение резервного аэратора по реле не требуют вообще никакой связи, кроме локальной электропроводки.

Центральный сервер (по желанию, но полезно). Арендованный VPS — например, в UK-локации — не участвует в критичной цепочке тревоги, но полезен как второй уровень: локальный сервер синхронизирует показания и события туда, когда связь есть, там же можно держать веб-панель для удалённого просмотра истории по всем прудам и Telegram-бота как дополнительный канал. Настройка такого бота подробно разобрана в статье про алерты в Telegram на VPS — принцип тот же, просто здесь это не единственная линия обороны, а бонус поверх локальной.

Если на площадке уже используются датчики по Zigbee или похожим протоколам для других задач (температура воды, уровень, погода), у вас наверняка пригодится опыт из статьи про Zigbee2MQTT на сервере и частые ошибки — многие грабли с потерей связи устройств и переподключением решаются одинаково независимо от конкретного датчика.

Резервирование: почему один канал связи и один источник питания — не резервирование

Собрать локальный сервер с реле и сиреной — только половина дела. Вторая половина — честно продумать, что именно может отказать вместе с интернетом, и не завязать всё на одну точку отказа.

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

Каналы связи. Не полагайтесь на один канал. Таблица ниже — не готовое решение, а ориентир для собственной схемы резервирования:

Логика простая: чем критичнее событие, тем меньше оно должно зависеть от внешних сервисов. У вас на площадке уже наверняка есть похожий печальный опыт — если нет, прочитайте историю про SMS об аварии, которая пришла через сорок минут из-за очереди на упавшем узле: даже когда канал формально работает, задержка доставки сама по себе может стоить вам критичного времени. Для кислорода в пруду сорок минут задержки — это уже не «неприятно», это может быть поздно.

Эскалация. Если дежурный не подтвердил получение тревоги за несколько минут (например, не поднял трубку автодозвона), логика должна сама звонить следующему по списку. Это несложно реализовать и в локальном скрипте — не нужно облако, чтобы перебрать два-три номера по очереди.

Честная оговорка. Такая схема требует больше настройки и обслуживания, чем готовая коробка вендора с приложением на телефон — вы сами отвечаете за то, чтобы Modbus-опрос не завис, реле не залипло, а SIM-карта в GSM-модуле не осталась без баланса. Это компромисс, на который стоит идти именно там, где цена отказа облака — гибель поголовья за одну ночь, а не там, где речь о неудобстве отчётности.

Частые вопросы