Від pet-проєкту до розумної пасіки: ESP32, SMS та Android без сервера

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Мій проєкт для бджільництва, у якому контрольний вулик на пасіці та Android-застосунок працюють разом без власного сервера. Пристрій збирає виміри й передає їх через SMS, а телефон зберігає дані та дає змогу переглядати їх у застосунку.

Я починав його як заняття у вільний час, щоб залишатися пов’язаним із бджільництвом. У цій статті розповім про початкові вимоги та рішення, з яких склалася система: як поєднати автономний пристрій із корисним відображенням даних на телефоні, коли на пасіці слабкий мобільний зв’язок і немає інтернету.

Все почалося значно простіше

Розробка почалася наприкінці 2023 року. На той час я вже мав значний практичний досвід у бджільництві, підкріплений хорошою теоретичною базою. Це було улюблене хобі, у якому я добре розбирався. Початок повномасштабної війни перервав можливість ним займатися.

Зосереджуватися лише на роботі довго не виходило: я постійно повертався думками до бджіл. Хотілося знайти заняття, яке дозволило б у вільний час зберігати зв’язок із цією справою. Так виникла ідея власного технічного проєкту для пасіки.

Планів виходити на ринок у мене не було. Це був pet-проєкт із можливістю спробувати щось нове й розвиватися. Почав я з вивчення того, що вже зробили інші: які пристрої існують і як побудовані системи навколо них.

Для власного пристрою хотілося використати ESP32. Мене приваблювали підтримка цього сімейства з боку програмних інструментів і великий вибір доступних на ринку модулів та плат. Далі потрібно було визначити, як пристрій отримуватиме живлення, передаватиме виміри й де ці дані зберігатимуться.

Здається, так виглядає більшість PoC-плат: головне, щоб ідея запрацювала. ))))

Пристрій і Android без власного сервера

Однією з головних вимог була автономність: я хотів, щоб пристрій працював щонайменше три місяці від невеликого акумулятора. Це була початкова мета, від якої я відштовхувався, обираючи спосіб передавання даних.

Інша вимога стосувалася зв’язку. Я орієнтувався на кочові пасіки, де доводиться зважати на слабке мобільне покриття та відсутність інтернету. Хотілося мінімізувати кількість і тривалість виходів пристрою в ефір, щоб зменшити витрати енергії на передавання.

Водночас у телефоні я хотів бачити графіки, середні значення та зміни показників за вибраний період. Для цього потрібен був застосунок із базою даних. Власний сервер означав би ще одну частину системи, яку довелося б розробляти й підтримувати, тому дані вирішив зберігати на Android.

Для зв’язку між пристроєм і застосунком обрав SMS. Така схема не вимагала інтернету для передавання вимірів; залежність від доступності мобільної мережі залишалася.

Вимірювати щогодини, передавати пакетами

Наступне питання — як скоротити кількість надсилань. Я розділив частоту вимірювання та частоту передавання: пристрій щогодини збирає показники налаштованого набору датчиків і зберігає їх до наступного запланованого надсилання. Дані за кілька годин пакуються в одне SMS.

Наприклад, за інтервалу передавання вісім годин повідомлення містить вісім погодинних наборів показників. За добу виходить три SMS із даними за кожну з 24 годин — за умови, що вимірювання й доставлення відбулися штатно. Час надсилання можна обирати, тож вісім годин тут — приклад налаштування. Для задуманого сценарію достатньо й двох повідомлень на добу: за рівномірного розкладу кожне має вміщувати дані за 12 годин.

Завдяки цьому в застосунку зберігається погодинна деталізація, хоча нові дані надходять лише кілька разів на добу. Це й був компроміс: рідше передавати дані, погодившись на затримку їх появи на телефоні.

Різні датчики та одне SMS

Набір датчиків можна було конфігурувати. Основу становили датчик ваги та два датчики температури: один для навколишнього середовища, другий — для вимірювання всередині вулика. Внутрішній датчик я передбачав розміщувати над клубом бджіл — їхнім щільним скупченням. Із мого досвіду бджільництва, зіставлення внутрішньої та зовнішньої температури було особливо інформативним для спостереження за станом і розвитком сім’ї в різні періоди року.

Опційно можна було додавати датчики вологості, тиску й руху, а також невеликий екран для перегляду показників безпосередньо біля пристрою.

Тому один погодинний запис містив кілька значень. Обсяг даних залежав і від набору датчиків, і від кількості годин між надсиланнями: що більше показників та довший інтервал, то більше потрібно передати за один раз. Окрім самих значень, у повідомленні мав бути щонайменше час першого вимірювання в пакеті.

Для всього цього я заклав обмеження: вмістити пакет в одне SMS із бюджетом у 160 символів. Потрібен був компактний спосіб записати змінний набір показників за кілька годин разом із часовою прив’язкою. З цієї вимоги й почалася розробка формату стислих повідомлень із даними.

Нижче — огляд стану за три тижні, з 30 серпня до 20 вересня, у сучасній версії застосунку: загальні показники та їхня історія на графіках.

Огляд стану за три тижні: значення показників і їхні зміни за вибраний період. Нижче також видно записи про сім’ю — частину щоденника, який розгляну в наступній статті.

Огляд вимірів за три тижні. На графіку ваги видно процес загодівлі — ступінчасте зростання після додавання корму. Підказки дозволяють переглянути дату, час і значення окремих вимірів.

Зв’язок на пасіці та енергоспоживання

Після розділення вимірювання й передавання робочий цикл виглядав досить просто. Раз на годину пристрою вистачало кількох секунд активності, щоб зібрати показники датчиків і зберегти їх. Окремо, у вибрані години, потрібно було ввімкнути GSM-модуль та надіслати накопичені дані. Саме цей етап вимагав більше часу й енергії.

У моїх спостереженнях для надсилання одного SMS вистачало приблизно 12–20 секунд. Підключення до мобільного інтернету через той самий модуль іноді тривало до хвилини. Для невеликого пакета показників я не бачив сенсу витрачати більше енергії на інтернет-з’єднання та додавати серверну частину.

Ці інтервали описують досвід із моїм пристроєм, а не гарантований час роботи GSM у будь-якій мережі. Для оцінки автономності важливо було перевірити, як поводиться вся система протягом тривалого використання.

Частота надсилання — частина налаштувань

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

Повідомлення можна було надсилати й на кілька номерів. Це давало змогу отримувати дані кільком користувачам без власного сервера, але кількість надсилань зростала. Розклад і кількість одержувачів потрібно було обирати з огляду на витрати живлення.

У цих умовах SMS став для мене простим і практичним каналом: короткий пакет надходив у застосунок без потреби встановлювати інтернет-з’єднання. За слабкого покриття я робив ставку саме на такий обмін. Затримки й невдалі спроби залишалися можливими, тому доступність мобільної мережі все одно була умовою роботи.

Передавання через Wi-Fi-мережу пасіки з доступом до інтернету з’явилося в подальших версіях. Його роль розгляну окремо; початковий віддалений обмін спирався на GSM і SMS.

Що довелося переробити в платі

За моїм досвідом, навіть для нескладного пристрою нерідко доводиться тричі переробляти плату, перш ніж отримати більш-менш нормально працюючий екземпляр. Цього разу вийшло так само. Зокрема, я неправильно узгодив рівні сигналів між SIM800 та ESP32, через що періодично втрачалося керування GSM-модулем.

Окремою проблемою було завелике споживання під час сну. Скоротити сеанси зв’язку виявилося недостатньо: потрібно було підібрати джерело живлення з дуже малим власним споживанням у стані очікування. Це був довгий, поступовий підбір. В описах готових модулів від постачальників я часто не знаходив саме цього показника.

Був і температурний сюрприз: за температур нижче приблизно —10 °C використаний стабілізатор живлення з малим падінням напруги (LDO) переставав запускатися. Зовні це виглядало дивно: пристрій передавав дані, потім завмирав, а з потеплінням приблизно до —10 °C знову виходив на зв’язок. Такі випадки показували, що перевіряти потрібно не лише витрати заряду, а й запуск та роботу пристрою в реальних умовах пасіки.

Що показала робота на пасіці

За моїми спостереженнями з використовуваних пристроїв, за відповідних налаштувань показник заряду знижувався приблизно на 0,3–0,5 відсоткового пункту на добу. Один із прикладів — графік роботи в реальних польових умовах за період із 22 червня до 20 вересня.

Показник заряду батареї в польових умовах із 22 червня до 20 вересня: зниження з 82% до 55%. На графіку застосунку наведено середній темп 0,30% на добу.

За ці приблизно три місяці показник знизився на 27 відсоткових пунктів. За 90 днів це в середньому 0,30 відсоткового пункту на добу, що узгоджується з підписом графіка. Йдеться саме про зміну показника заряду, який відображає застосунок.

Це один із кількох польових прикладів. Таке спрощене випробування дає мені підстави сподіватися, що й в інших умовах витрати живлення залишаться в межах, потрібних для бажаних трьох місяців автономної роботи. Водночас літній графік не гарантує такого самого результату за іншої температури чи гіршого мобільного покриття — ці умови також впливають на автономність.

Пристрій, застосунок і власник даних

Спочатку я задумував систему як пристрій та умовний «показометр» до нього на Android. Застосунок мав передусім зручно відображати отримані показники. За вимірювання й збереження повної історії відповідав сам пристрій.

Історія зберігається на вагах

Усі виміри записуються на microSD у файли CSV — звичайний табличний формат, який можна відкрити в електронній таблиці або обробити власним скриптом. Архів накопичується протягом усього строку користування пристроєм, зокрема роками. Його глибина обмежена місткістю картки, а дані залишаються доступними для роботи поза застосунком.

Це було важливо для пасіки з нестабільним зв’язком. Навіть якщо телефон довго не отримує повідомлень, ваги продовжують вимірювати й записувати результати. Пропуск у даних на телефоні можна заповнити з архіву пристрою.

Давніші дані залишаються на microSD, звідки їх можна прочитати безпосередньо. Докладніше про канали й доступну глибину історії — у документації BeeApiary.

Такий підхід допомагає й під час переходу на новий телефон: власник може знову завантажити історію з ваг. Архів вимірів залишається в його розпорядженні незалежно від заміни телефона, а CSV дозволяє надалі працювати з ним зручними для себе інструментами.

Кілька ваг і кілька користувачів

Кожен пристрій знає номери, на які має надсилати SMS. Тому система не прив’язана до пари «одні ваги — один телефон»: одному власникові можуть надходити дані від багатьох пристроїв. Додавання ще одних ваг не потребує розширення власної серверної інфраструктури.

Так само одні ваги можуть надсилати дані кільком користувачам. Кожен отримує повідомлення у свій застосунок, а джерелом вимірів і повного архіву залишається пристрій на пасіці. Кількість одержувачів потрібно враховувати в розкладі й витратах живлення, про які йшлося в попередньому розділі.

Перша робоча плата

Десь на початку 2024 року з’явилася перша робоча плата. До цього моменту вже склалася невелика система: пристрій збирав і зберігав виміри, передавав їх на телефон, а застосунок показував дані у зручному вигляді.

Перша робоча плата BeeApiary, початок 2024 року.

Тоді я вирішив викласти інформацію про проєкт і показати його іншим. Уже було чим поділитися: невеликою системою з власним пристроєм, історією вимірів і застосунком до нього.

Про небайдужих

Коли я показав проєкт іншим, це вже був робочий пристрій, хоча програмне забезпечення ще залишалося сирим. Згодом з’ясувалося, що доробок потребували й плати. Частину проблем допомагали знаходити користувачі на початкових етапах роботи пристроїв на пасіках — фактично це було спільне тестування в реальних польових умовах.

Іноді плати доводилося відкликати для доробки. У таких випадках я замінював плату користувача на нову, уже доопрацьовану й перевірену, а його плата залишалася в мене на доробку. Для цього довелося тримати запас плат із виправленими проблемами, які вже пройшли повторну перевірку. Підтримка пристроїв виявилася окремою частиною роботи над проєктом.

До проєкту почали долучатися люди, яким було цікаво те, що я роблю. Комусь подобалося, як працюють ваги, але хотілося додаткових можливостей. Хтось просто ділився порадами. Із цих побажань поступово виростали конкретні доробки: нові функції з’являлися і в Android-застосунку, і в програмному забезпеченні пристрою.

Я дуже вдячний усім, хто долучився. Люди витрачали свій час із власного інтересу, бо їм подобалося щось створювати й допомагати проєкту ставати кращим.

Спільний вигляд вебінтерфейсу та застосунку

Окремою несподіванкою стало знайомство з учасником, який запропонував переробити зовнішній вигляд вебінтерфейсу ваг та Android-застосунку. Він допоміг втілити ці зміни й привести інтерфейси до привабливого вигляду.

Після цієї роботи вебінтерфейс ваг набув такого вигляду:

Вебінтерфейс ваг після оновлення дизайну: налаштування та поточні показники.

Налаштування розкладу надсилання даних. На цьому прикладі вибрано шість надсилань на добу.

Перегляд показників і станів функцій пристрою в тому самому оформленні.

Зовнішній вигляд Android-застосунку також суттєво переробили. Узгодили кольорові схеми, кнопки та інші елементи керування, щоб вебінтерфейс і застосунок мали спільний, упізнаваний вигляд. При цьому зберігали наявні можливості й додавали нові.

Так проєкт, який почався як моє заняття у вільний час, розвивався вже за участі інших людей. Їхні поради, побажання й допомога впливали і на те, що система вміла, і на те, як із нею працював користувач.

До чого дійшли на цьому етапі

На практиці простий підхід із SMS добре підійшов для наших умов: слабкого зв’язку, обмеженого живлення та потреби заощаджувати кошти. Невеликі пакети вимірів можна було отримувати на телефон без мобільного інтернету, а всю історію зберігати на пристрої й працювати з нею без власного сервера.

Локальне зберігання та прямий доступ до даних виявилися корисними й тоді, коли кочова пасіка поверталася додому. Спостереження можна продовжувати, зокрема під час зимівлі: ваги накопичують виміри, а власник отримує їх безпосередньо. Якщо на пасіці є локальна мережа, пристрій може обмінюватися даними через неї. У такому сценарії немає потреби окремо оплачувати мобільний зв’язок для ваг.

Для мене це був шлях від задуму до реального проєкту, який поступово доводив до робочої моделі. У ньому поєдналися Android-застосунок без серверної частини та пристрій із локальними накопичувачами, конфігуратором, вебінтерфейсом і мережевим обміном файлами через FTP. Заодно вдалося випробувати інші технології зв’язку й побачити, як вони поводяться в практичному використанні.

Простий і недорогий спосіб обміну даними виявився придатним і за межами України. Пристрої вже працюють у Франції, Німеччині, Польщі, Норвегії та країнах Балтії. Кількість поки невелика, але для мене як автора pet-проєкту це вже вагома перевірка концепції: система виявилася корисною іншим людям і працює в різних умовах.

Документація та програмне забезпечення підтримують кілька мов, і перелік локалізацій поступово розширюється. Опис системи, способів отримання даних та інструкції з налаштування зібрані в документації BeeApiary

Згодом додалися інші сценарії обміну, зокрема фонове отримання даних через Bluetooth, а сам застосунок почав перетворюватися з «показометра» на щоденник бджоляра.

Якщо ця тема буде цікава спільноті DOU, продовжу розповідь у наступній статті — про розвиток застосунку, роботу через локальну мережу та Bluetooth, NFC ідентифікацю вуликів, створення подій та опис станів вуликів та плани на рух вперед.