Пасека: журнал ульев, привесы и погода — маленькая система на маленьком сервере

MAATRIX

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

Почему тетрадь и Excel перестают работать уже на втором сезоне

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

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

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

Что на самом деле нужно фиксировать: три потока данных, а не один

Прежде чем говорить про сервер и базы данных, стоит явно разложить, что вообще нужно записывать — потому что именно тут чаще всего экономят и потом жалеют.

Журнал по каждому улью. Дата осмотра, номер улья, состояние семьи (сила, расплод, наличие и возраст матки, признаки роения), санитарное состояние (клещ, вредители, обработка — чем и когда), кормовая база на момент осмотра, действия пчеловода (расширение, объединение, отводок, откачка). Это самая объёмная часть журнала, и именно её тяжелее всего вести в таблице — записи разной структуры: то короткая пометка «всё хорошо», то развёрнутое описание проблемы.

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

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

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

Почему для этого хватает маленького и недорогого сервера

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

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

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

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

Журнал ульев: простая база вместо блокнота

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

Вариант А — SQLite и простая веб-форма. Подходит, если систему настраивает один человек для себя и близких, без параллельного доступа многих пользователей одновременно. SQLite — это файл, никакого отдельного сервера БД не нужно, бэкап — это просто копия файла.

CREATE TABLE hives (
    hive_id     INTEGER PRIMARY KEY,
    name        TEXT NOT NULL,
    location    TEXT,
    started_at  DATE,
    notes       TEXT
);

CREATE TABLE inspections (
    id          INTEGER PRIMARY KEY AUTOINCREMENT,
    hive_id     INTEGER REFERENCES hives(hive_id),
    checked_at  DATE NOT NULL,
    strength    TEXT,      -- сила семьи: слабая/средняя/сильная
    queen_seen  BOOLEAN,
    brood       TEXT,      -- есть расплод, какой
    varroa      TEXT,      -- признаки клеща / обработка
    feed_status TEXT,
    action      TEXT,      -- что сделано: расширение, откачка и т.д.
    notes       TEXT
);

Вариант Б — PostgreSQL, если планируете доступ с нескольких устройств одновременно (например, вы и помощник вносите данные параллельно) или хотите позже подключить Grafana для графиков — Postgres она поддерживает нативно, без дополнительных плагинов.

Интерфейс для ввода не обязан быть красивым — на старте достаточно готового инструмента вроде Baserow или NocoDB (self-hosted аналоги Airtable, разворачиваются одним docker-compose файлом и дают табличный веб-интерфейс с формами прямо поверх Postgres) или даже минимальной формы на Python/Flask, если хочется контролировать структуру полей самостоятельно. Ключевое требование — форма должна открываться с телефона, потому что записи чаще всего вносятся прямо на пасеке.

# docker-compose.yml — минимальный стек: Postgres + Baserow
version: "3.8"
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: paseka
      POSTGRES_USER: paseka
      POSTGRES_PASSWORD: замените_на_свой_пароль
    volumes:
      - pgdata:/var/lib/postgresql/data
  baserow:
    image: baserow/baserow:1.25.2
    environment:
      DATABASE_HOST: db
      DATABASE_NAME: paseka
      DATABASE_USER: paseka
      DATABASE_PASSWORD: замените_на_свой_пароль
    ports:
      - "8080:80"
    depends_on:
      - db
volumes:
  pgdata:

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

Привесы с весов и погода: как довести данные до сервера

Тут важно сразу развести два реалистичных сценария, потому что весовое оборудование у пчеловодов сильно разное и универсального «просто подключите API» не существует.

Если весы умеют сами куда-то отправлять данные (у части электронных весов для контрольного улья есть модуль связи — Wi-Fi или GSM — и собственное облако производителя), самый надёжный путь — не пытаться перехватить их протокол, а либо периодически экспортировать данные из облака производителя (если такая функция есть), либо, если весы отдают показания в локальную сеть, написать небольшой скрипт-приёмник. Здесь многое зависит от конкретной модели, поэтому универсальную инструкцию давать нечестно — сверьтесь с документацией именно вашего весового блока на предмет экспорта данных (CSV, локальный API, отчёт на почту).

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

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

#!/usr/bin/env python3
# weather_pull.py — тянет вчерашнюю погоду по координатам пасеки в Postgres
import requests, psycopg2, datetime

LAT, LON = 55.75, 37.61  # координаты вашей пасеки
yesterday = (datetime.date.today() - datetime.timedelta(days=1)).isoformat()

resp = requests.get(
    "https://archive-api.open-meteo.com/v1/archive",
    params={
        "latitude": LAT, "longitude": LON,
        "start_date": yesterday, "end_date": yesterday,
        "daily": "temperature_2m_max,temperature_2m_min,precipitation_sum,windspeed_10m_max",
        "timezone": "auto",
    },
    timeout=15,
)
resp.raise_for_status()
d = resp.json()["daily"]

conn = psycopg2.connect("dbname=paseka user=paseka password=... host=localhost")
with conn, conn.cursor() as cur:
    cur.execute(
        """INSERT INTO weather_log (day, temp_max, temp_min, precip_mm, wind_max)
           VALUES (%s, %s, %s, %s, %s)
           ON CONFLICT (day) DO NOTHING""",
        (yesterday, d["temperature_2m_max"][0], d["temperature_2m_min"][0],
         d["precipitation_sum"][0], d["windspeed_10m_max"][0]),
    )

Ставится в cron на сервере — например, запуск каждое утро в 6:00:

0 6 * * * /usr/bin/python3 /opt/paseka/weather_pull.py >> /var/log/paseka-weather.log 2>&1

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

Как смотреть на накопленные данные: графики важнее самой таблицы

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

Если база — Postgres, самый практичный вариант — Grafana: она подключается к Postgres напрямую и позволяет за полчаса собрать дашборд с несколькими графиками — привес по дням, погода за тот же период, число осмотров по ульям. Grafana изначально сделана для мониторинга серверов, но ничто не мешает применить её к данным пасеки: SQL-запрос к таблицам weather_log и hive_weight_log — и график готов.

Если полноценная Grafana ради пасечных графиков избыточна, более лёгкий вариант — скрипт на Python с matplotlib, который раз в неделю строит пару графиков и отправляет картинкой в Telegram-бот пчеловода. Выбор между дашбордом и еженедельной картинкой в чат — вопрос того, сколько времени вы готовы потратить на настройку, а не вопрос принципиальной возможности.

Отдельно стоит не забывать про резервные копии — сезонные данные накапливаются годами, и терять их обидно. Для такого объёма (обычно единицы-десятки мегабайт) подходит самая простая схема бэкапа, без сложной инфраструктуры — как в общем случае описано в материале правило 3-2-1 для бэкапов недорого: копия на сервере, копия в другом месте, и хотя бы одна — не в облаке того же провайдера, что и сам сервер.

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

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