На що варто звернути увагу

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

1. Коли ми працюємо з мовою програмування Lua, треба враховувати, що маємо справу з асинхронним середовищем виконання скриптів. На практиці це означає, що кожна окрема команда чи “частина коду” (див. документацію Lua, chunk), запускається у своєму власному процесі паралельно до інших частин коду і в реальності виконується за принципом ASAP (as soon as possible), якщо не вдаватися у деталі. 

Наприклад, якщо зробити запит по шині I2C (див. документацію на модуль i2c за посиланням I²C Module ) до сенсора температури, а наступною ж командою спробувати віддати значення температури на відправку у інтернет (див. документацію на модулі http: HTTP Module ; net: net Module ), то з високою ймовірністю такий підхід не буде працювати. І все лише через те, що повільна шина I2C не дозволить скрипту встигнути отримати значення сенсора і помістити його у відведену для цього змінну. Таким чином, процедурно – скрипт виконається, але у інтернет потрапить не бажане значення температури, а попереднє значення змінної, яку контролер не встиг оновити до пуску команди відправки через інтернет.

2. Сучасні контролери, як-от ESP8266 з прошивкою NodeMCU орієнтовано на середовище виконання коду, що керується подіями (Event-driven Environment). Цей підхід дозволяє ефективно заощаджувати обчислювальні ресурси центрального процесора та оперативну пам’ять і знизити вимоги до елементів живлення у рази. 

Приклади: 

1. Для чого нам постійно тиркати сенсор температури запитами, якщо ми можемо отримати від нього подію тоді і лише тоді, коли значення його температури зміниться суттєво? Так само і з перевіркою наявності зв’язку – можемо перевіряти це щосекунди, а можемо лише тоді, коли виникне подія (помилка, таймер, кнопка, нове вимірювання тощо).

2. Можуть бути ситуації, коли нам немає сенсу зберігати у пам’яті поточні значення всіх сенсорів, бо ми вже відправили їх на сервер у хмарі. А наступні значення, ми отримаємо лише коли виникне відповідна подія. Тобто ми можемо сміливо вивільнити оперативну пам’ять для інших процесів, що паралельно виконує наш контролер.

3. Якщо ми знаємо, що користувача нашого розумного пристрою цікавить значення температури не частіше ніж 1 раз на 5 хвилин і то лише тоді, коли покази суттєво змінилися, то який сенс розряджати дорогоцінний акумулятор і оновлювати дані кожні 4 мілісекунди? Краще перевести сенсор(и) у режим подій з пониженим споживанням енергії і продовжити час автономної роботи нашого пристрою з однієї години до трьох діб?

А тепер по суті – коли і як контролювати наявність зв’язку?

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

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

• передача даних до віддаленого сервера у мережі Інтернет;
• отримання даних з віддаленого сервера у мережі Інтернет.

Наведемо приклади таких задач: 

• надсилання значень сенсорів або команд від локального користувача, 
• синхронізація часу та дати з NTP серверів з метою оновлення даних у бортовому енергонезалежному годиннику реального часу RTC, 
• завантаження та встановлення оновлень програмного забезпечення, 
• отримання/відправка параметрів конфігурації, 
• отримання команд від сервера на виконання контролером, 
• надсилання поточних географічних координат,
• надсилання сповіщень користувачеві через різноманітні шлюзи коротких повідомлень.

Гетерогенне середовище служб і сервісів мережі Інтернет вимагає від розробника неабиякої гнучкості і винахідливості: якщо ми перевірили і у нас є з’єднання з локальною Wi-Fi (ESP8266 має лише вбудований Wi-Fi на борту) точкою доступу, це зовсім не означає, що ми гарантовано можемо передавати чи отримувати дані між нашим локальним маршрутизатором і віддаленими майданчиками у інтернет. В наведеній обстановці нам може завадити одна чи одразу декілька проблем: чи вірно DHCP сервер точки доступу призначив мережну IP-адресу для контролера, чи надає провайдер доступ до інтернет далі по ланцюжку, вже за межами інтерфейсів вашої точки доступу Wi-Fi, чи працює DNS сервер у провайдера, чи встановлюється захищене з’єднання з віддаленим сервером, чи сприймає віддалений сервер вашу спробу передати дані і так далі. 

Спершу здається, що найкращий і єдиний метод перевірки можливості прийому/передачі даних, це спробувати передати (і отримати адекватну відповідь) тестові дані тим самим способом і маршрутом, що і значущі дані вимірювань, конфігурацій чи керування в межах нашого власного прикладного протоколу. – Лише отримавши результати перевірки у декілька послідовних кроків і піддавши їх логічному аналізу, можливо дійти висновку про наявність чи відсутність можливості у контролера передавати дані через мережу Інтернет. Втім, цей спосіб перевірки не завжди підходить. 

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

Можливі стратегії

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

• Стратегія “періодичне опитування” – потребує активного звернення до відповідних служб мережі, мережного інтерфейсу контролера та віддаленого сервера;

Прошивка NodeMCU має декілька спеціальних інструментів, які доступні для застосування у коді на рівні Lua у вигляді C-модулів, які користувач може включити (див. Інструкцію з прошивки Як швидко почати працювати з контролером NodeMCU/ESP8266 ) до своєї прошивки NodeMCU. Зокрема слід навести такі стандартні модулі: wifi.sta. WiFi Module – налаштування інтерфейсу Wi-Fi у режимі клієнта з підключенням до точки локальної доступу; net.dns. net Module – взаємодія з зовнішнім DNS-сервером; http. – передача даних засобами протоколу HTTP/HTTPS на рівні REST-методів HTTP POST/GET і подібних. 

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

• Стратегія “безпосередня перевірка” – підмножиною стратегії періодичного опитування може бути стратегія перевірки наявності зв’язку лише безпосередньо перед черговим сеансом зв’язку. Такий спосіб організації логіки має очевидну перевагу: завдяки мінімальному навантаженню на систему, мережу і акумулятор. Проте має невеликий недолік, який за певних обставин може бути суттєвим – контролер, а потім і користувач, побачить що немає зв’язку лише тоді, коли вже потрібно здійснювати прийом/відправку даних і вже немає часу на виконання превентивних дій з відновлення зв’язку (наприклад, розірвати і знову встановити підключення на рівні WiFi, або взагалі переключитися на резервну точку доступу). 

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

• Стратегія “обробка події” – йдеться про пасивне очікування системної події чи подій з подальшою їх обробкою.

Прошивка NodeMCU серед інших інструментів, надає модуль контролю стану приєднання до точки доступу Wi-Fi орієнтований на події wifi.eventmon (Див. документацію NodeMCU). Але цей модуль вирішує лише частину задачі – контроль і стан приєднання до Wi-Fi. У wifi.eventmon взагалі немає мети розв’язання задачі контролю наявності спроможності передачі корисних даних через Інтернет.

• Стратегія “обробка помилок” – йдеться про класичний механізм, особливо притаманний асинхронним системам – запускаємо необхідний нам процес на виконання, а якщо щось пішло не так, то тоді і обробляємо помилки, що виникли. Якщо мети не вдалося досягнути при поточному запуску процесу, нічого страшного, вийде при наступному запуску процесу, попри помилки і відсутність результату. Стратегія обробки помилок схожа на стратегію обробки подій, але тим не менш, є ризикованою. Адже завжди є вірогідність, що замість конкретної системної помилки ми отримаємо некероване зависання і перезапуск контролера без будь-яких пояснень,бо маємо справу з вбудованими мініатюрними обчислювальними комплексами з дуже обмеженими ресурсами.

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

Ми з вами розглянули декілька різних стратегій і тепер можемо скласти певну логічну карту їх застосування

Кейс	Стратегія
Якщо потрібно передавати чи отримувати дані у суворо зафіксовані проміжки часу	Періодичне опитування
Якщо потрібно керувати відповідальним обладнанням через інтернет	Періодичне опитування з Обробкою подій та взаємне підтвердження всіх операцій обміну
Якщо потрібно заощаджувати ресурс акумулятора	Обробка подій
Якщо потрібно мінімізувати навантаження на обчислювальні ресурси контролера та пам’ять	Обробка помилок
Якщо потрібно мінімізувати кількість мережних запитів через інтернет	Обробка подій
Якщо потрібно швидко, прозоро і стисло написати код	Безпосередня перевірка

Бажаємо успіхів!

Продукти за темою:

Фоновий процес покрокової перевірки наявності доступу до Інтернет