Интелигентна разпределена IoT система за наблюдение на времето, използваща NodeMCU: 11 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:50

Всички може би сте запознати с традиционната метеорологична станция; но чудили ли сте се как всъщност работи? Тъй като традиционната метеорологична станция е скъпа и обемна, плътността на тези станции на единица площ е много по -малка, което допринася за неточността на данните. Ще ви обясня как: Да предположим, че станция е разположена в центъра на града и е единствената станция, която се намира в радиус „х“метър, тя може лесно да бъде предубедена, ако в близост има някакъв причинител на замърсяване на станцията, показваща цялата радиус на радиуса 'x' като замърсена, тъй като тази единична станция е отговорна за определяне на метеорологичните данни за цялата област.

За да се преодолее този проблем, плътността на модулите трябва да се увеличи, което е възможно само ако модулите са по -евтини и заемат по -малък отпечатък от съществуващия.

Това е причината моето предложено решение да е идеалното решение за този проблем, струва по -малко от 10 долара и също лежи лесно на дланта ми.

Как работи…

Има 3 основни части на този проект.

Страна на устройството:

Устройството е IoT модул, показан на снимката, който изпраща метеорологичните данни на сървъра на всеки интервал от време „x“. Данните включват действителните метеорологични данни, географското местоположение на модула; т.е. Неговите координати, неговият MAC адрес; за уникално идентифициране на устройството, версията на фърмуера, на която работи в момента. Страната на устройството включва N-модули, разпределени в цялата област, които активно допринасят данни към сървъра.

От страна на сървъра:

Както подсказва името, това е централизираният сървър, който обработва няколко операции като получаване на данните от модулите и съхраняването им в базата данни, актуализиране на модула с най -новия фърмуер, ако работи на по -стара версия, изпращане на метеорологичните данни до клиент при поискване.

Страна клиент/потребител:

Крайният потребител изисква данните за времето от сървъра. Клиентът изпраща текущото местоположение и въз основа на местоположението сървърът изчислява разстоянието между клиента и всички модули и изпраща метеорологичните данни на най -близкия модул до клиента, което се счита за точно.

Консумативи

• NodeMCU (ESP8266-12E)
• DHT11 (сензор за влажност и температура)
• BMP180 (сензор за налягане и температура)
• MQ-135 (сензор за индекс на качеството на въздуха)
• USB кабел (за качване на програмата)
• 5 -волтово захранване
• Кондензатори (по избор: да бъдат поставени успоредно на електропровода)
• Arduino IDE (За отстраняване на грешки и качване на програмата)
• Приложение POSTMAN (по избор: за отстраняване на грешки в API)
• Уебсайт (за хостване на PHP и MySQL сървъра)

Стъпка 1: Запояйте всички компоненти и качете програмата в NodeMCU

Запояйте всички компоненти към NodeMCU, както е показано на електрическата схема на перф платка. Също така запоявайте кондензатор успоредно на електропроводите, тъй като захранването се покачва по време на активно предаване и приемане на данни.

След като запояването приключи, качете кода, предоставен във файла „code.c“.

Забележка: Не забравяйте да замените идентификационните данни със собствените си. Също така поставете файла с име "html_file.h" в папката за скици на arduino. Всички заглавни файлове, използвани в този проект, могат да бъдат намерени тук

Характеристики на кода:

Точка за достъп: Тъй като е трудно да се програмира всеки модул с идентификационните данни в масово производство, модулът хоства уеб страница при първото си зареждане, за да приеме идентификационните данни на WiFi, към който модулите трябва да се свържат, и съхранява в EEPROM за по -късна употреба.

След като идентификационните данни са конфигурирани, NodeMCU проверява EEPROM за идентификационни данни и се свързва с идентификационните данни за WiFi, налични в EEPROM.

След успешно свързване към WiFi, NodeMCU започва да качва данните на сървъра на всеки „x“интервал от време, данните включват метеорологични данни, MAC адрес на модула, версия на фърмуера, географско местоположение на устройството.

OTA актуализация: Модулът също проверява за нова актуализация на фърмуера всеки ден в определено време, посочено в кода. Тази функция е полезна, тъй като не е възможно всеки производител да продължи и да промени програмата на отделен модул, в случай че има някакви промени, които трябва да бъдат направени.

Watchdog Timer: Atlast трябва да има начин да се възстанови без никаква човешка намеса, ако заседне или се срине. Това може да се постигне с помощта на таймера за наблюдение. Начинът, по който това работи, е: Има подпрограма за прекъсване, която се изпълнява всяка секунда. ISR увеличава брояча всеки път, когато се изпълнява, и проверява дали броячът е достигнал максималния брой. След като броячът достигне максималната стойност, модулът се нулира, приемайки, че е катастрофирал. При нормална работа броячът винаги се нулира, преди да достигне максималния брой.

Стъпка 2: Конфигуриране на SQL Server

Настройката на SQL Server също е много проста. Просто създайте база данни в SQL сървър и импортирайте настройката, като импортирате файла с име "database_structure.txt". Можете да намерите файла в тази стъпка. Тъй като инструкцията не позволява качване на ".sql" файлове, преименувах файла на ".txt".

Забележка: Преименувайте файла от ".txt" на ".sql".

Стъпка 3: Конфигуриране на файловия сървър

Конфигурирането на сървъра е наистина лесно, ако притежавате уебсайт и той се хоства онлайн. Няма да премина през цялата процедура по създаване на уебсайт и хостването му, тъй като това е извън обхвата на този урок. Но можете да го хоствате на вашия собствен компютър като localhost, за да опитате работата на файловете.

Тъй като Instructable не позволява качване на PHP файлове, преименувах файловете на „.txt“.

Забележка: Моля, преименувайте разширението на файловете на ".php". Също така не забравяйте да промените идентификационните данни на файла "config.php".

Просто качете файловете на сървъра и сте готови.

Ще ви дам кратка информация за PHP файловете.

db_config.php:

В този файл се съхраняват всички идентификационни данни, необходими за свързване към SQL сървъра.

db_connect:

В този файл присъства класът, необходим за връзка с база данни.

insert.php:

NodeMCU извиква този PHP файл за качване на данните на сървъра, използвайки метода GET. Този файл също е отговорен за съхраняването на същите данни в SQL сървъра.

retrieve.php:

Потребителят/Клиентът извиква този PHP, използвайки метода GET. Сървърът изчислява разстоянието между потребителя и всички модули. След това данните на най -близкия модул се изпращат като отговор на клиента в JSON/XML формат според предпочитанията на клиента.

update.php:

Този PHP файл се извиква от модула всеки ден в определено време, за да провери дали модулът работи с най -новата версия на фърмуера. Просто поставете най -новия ".bin" файл във файловия сървър и посочете директорията на файла в променливата на файла.

Ако на пръв поглед тези много файлове изглеждат обезсърчаващи, включих потребителската документация в следващата стъпка.

Стъпка 4: Документация на потребителя

Въведение:

API за времето осигурява прост интерфейс за заявяване на метеорологичните данни за местоположения на повърхността на земята. Искате информация за времето за конкретна двойка географска ширина/дължина с посочен изходен формат. API връща индекса на температурата, влажността, налягането и качеството на въздуха, последно записан от най -близкия модул от исканото място.

Преди да започнеш:

Този документ е предназначен за разработчици на уебсайтове и мобилни устройства, които искат да включат информация за времето в разработено приложение. Той представя използването с помощта на API и справочен материал за наличните параметри.

Искания за метеорологични данни:

Исканията за API на времето са конструирани като URL низ. API връща метеорологични данни за точка на земята, посочена от двойка географска ширина/дължина. Имайте предвид, че точността на метеорологичните данни е правопропорционална на плътността на модулите, поставени в дадена област.

Заявка за API за времето има следната форма:

example.com/retrieve.php?lat=25.96446&lon=53.9443&format=json

Когато изходният формат (формат) може да бъде една от следните стойности:

• JSON (препоръчително), показва изход в JavaScript Object Notation (JSON); или
• XML, показва изход в XML, обвит в възела.

Параметри на заявката:

Както е стандартно във всички URL адреси, параметрите се разделят с помощта на знака амперсанд (&). Списъкът с параметри и техните възможни стойности са означени по -долу.

Задължителни параметри:

• lat: Представлява географска ширина на местоположение за търсене. (напр. lat = 19,56875)
• lon: Представлява дължина на местоположение за търсене. (напр. lon = 72.97568)

Допълнителни параметри:

формат: Определя изходния формат на отговора на метеорологичните данни. Това може да бъде JSON или XML. По подразбиране е JSON. (напр. format = json или format = xml)

Отговори на времето:

За всяка валидна заявка услугата за часовата зона ще върне отговор във формата, посочен в URL адреса на заявката. Всеки отговор ще съдържа следните елементи:

• успех: стойност, показваща състоянието на отговора.

  • 0: Отрицателно; показва, че заявката е неправилно оформена.
  • 1: Потвърдително; показва, че заявката е успешна.
• съобщение: низ, показващ причината за нередността на заявката. Налично само когато състоянието е отрицателно.

• данни: масив с множество метеорологични параметри.

  • temp: данните за температурата.
  • hum: данни за присъствието на влажност.
  • pres: данните за абсолютното налягане.
  • aqi: настоящият индекс на качеството на въздуха.

Примерите за отговор на двата формата могат да се видят в изображенията.

Стъпка 5: Настройка на модула

Създава се точка за достъп и уеб страница се хоства на IP адрес (по подразбиране: 192.168.4.1), за да получи идентификационните данни от мениджъра/потребителя на устройството при първото зареждане или ако модулът не намери вече съхранените идентификационни данни в EEPROM.

Потребителят трябва да въведе SSID и парола, към които потребителят иска да се свърже модулът. Географската ширина и дължина се запълват автоматично, ако разрешите на браузъра достъп до местоположението.

След като всички данни бъдат въведени, щракнете върху бутона „ИЗПРАТИ“, след което всички идентификационни данни се записват в EEPROM на модула.

Тази стъпка е много важна, тъй като докато се произвежда масово модулите, не е възможно да се програмират всички модули с техните точни данни за местоположението и идентификационни данни за WiFi. Също така не е препоръчително да кодирате твърдо идентификационните данни в програмата, тъй като ако изобщо трябва да преместим модула на друго място или искаме да сменим идентификационните данни за WiFi, ще трябва да препрограмираме модула. За да се избегнат тези проблеми, се изпълнява функцията за първоначална настройка.

Стъпка 6: Сега е време да допринесете данни в облака

След като всички предишни стъпки са изпълнени, сега е време да позволите на модула да качи данните на сървъра. Той автоматично започва да се качва, след като запазите идентификационните данни.

Той извиква „insert.php“като API извикване с предаване на всички параметри за изпращане в GET метод.

Кодът по -долу показва как се обработват параметрите.

if (isset ($ _ GET ['temp']) && isset ($ _ GET ['hum']) && isset ($ _ GET ['pres']) && isset ($ _ GET ['aqi']) && isset ($ _ GET ['mac']) && isset ($ _ GET ['lat']) && isset ($ _ GET ['lon'])) 2. {3. // основна програма 4.}

Така всички модули започват да качват данните.

Забележка: Намалете честотата на качване в кода, ако смятате, че сървърът се претоварва.

Стъпка 7: Актуализация по въздуха (OTA)

След като модулът е настроен и започне да качва данните, той проверява за актуализации на фърмуера всеки ден в определено време, посочено в програмата. Ако открие такъв, той изтегля и мига двоичния файл в него. И ако това не стане, нормалната операция по качване на данни продължава.

За да провери за нова актуализация, модулът извиква „update.php“, като изпраща MAC адреса в заглавката на заявката си. След това сървърът проверява дали този конкретен MAC адрес има нова актуализация, ако да, той изпраща в отговор двоичния файл на най -новия фърмуер.

Той също така проверява за всички необходими заглавки, необходими за основно удостоверяване на модула.

Стъпка 8: Как потребителят/клиентът може да получи достъп до данните …

Достъпът до данните от сървъра е доста лесен. Само като извикаме „retrieve.php“, ще получим метеорологичните данни в отговор във формат JSON. След това е само въпрос на анализиране на JSON данните за достъп до отделните елементи. Подобно е с XML отговора. Потребителят винаги може да посочи предпочитания формат на отговор, в който потребителят да е удобен за работа. Ако потребителят не посочи формата, форматът по подразбиране е JSON.

Примерна заявка се прави с помощта на POSTMAN инструмент за проверка на работата на API.

Пример за анализ на JSON отговор в javascript е показан в кодовия фрагмент по -долу.

var url = "https://example.com/retrieve.php?lat=19.044848&lon=72.8464373";функция httpGet (theUrl) {var xmlHttp = нов XMLHttpRequest (); xmlHttp.open ("GET", theUrl, false); // false за синхронна заявка xmlHttp.send (null); връщане xmlHttp.responseText; } var myVar = httpGet (url); var obj = JSON.parse (myVar); document.getElementById ("aqi"). innerHTML = obj.data [0].aqi; document.getElementById ("температура"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("temp"). innerHTML = Math.round (obj.data [0].temp) + "° C"; document.getElementById ("влажност"). innerHTML = Math.round (obj.data [0].hum) + "%"; document.getElementById ("налягане"). innerHTML = Math.round (obj.data [0].pres) + "mb";

Изходният код на примерната HTML страница, която анализира JSON отговора, е достъпен в края на тази стъпка.

Забележка: Променете разширението на файла на „.html“.

Стъпка 9: Ограничения на този проект

• Проектът използва GET за изпращане на данните; въпреки че не се занимава с чувствителни данни, данните могат лесно да бъдат манипулирани, тъй като нямат никакъв механизъм за проверка на автентичността на източника, освен проверка на заглавките, които могат лесно да бъдат модифицирани и дори нормално устройство може да бъде излъгано да изглежда като модул за времето.
• Тъй като модулът разчита единствено и зависи от друга точка за достъп (WIFI) за изпращане на данни, които в повечето случаи биха били от други организации. Ако точката за достъп изобщо не работи по някаква причина, модулът няма да може да изпраща данни.
• Въпреки че проектът е изграден с цел повишаване на точността на съществуващата система, наличният на пазара сензор е по -малко точен от очакваното, което в резултат води до провал на основното му предназначение.
• Докато планирах проекта, планирах да включа режим, в който сървърът осреднява стойността на данните въз основа на местоположението за коригиране на грешки. Но при прилагането на тази функция разбрах, че се нуждае от API на трети страни, за да преведе координатите в географски региони.

Стъпка 10: Допълнителни подобрения, които могат да бъдат направени в този проект

• Точността на модула може да бъде допълнително подобрена чрез специално пригождане на сензорите за конкретната цел, вместо да се използва общия модул, който се предлага на пазара.
• Модулът може да бъде модифициран, за да работи още по-независимо, като се използва специален чип, който безжично комуникира с клетъчните кули, за да изпраща данните, като по този начин подобрява отказоустойчивостта.
• Слънчевият панел и акумулаторната система могат да се използват заедно с режима на дълбоко заспиване на ESP, като по този начин подобряват енергийната ефективност и я правят по-независима от външно захранване.
• POST може да се използва за изпращане на данни с някакъв механизъм за удостоверяване, като например използване на циклични кодове за всяко предаване на данни.
• Вместо NodeMCU, който е прототипна платка, можем да използваме персонализиран микроконтролер в масовото производство, който не само намалява разходите, но и използва най-добре системните ресурси.
• Във връзка с API за геолокация на Google и свързване към всеки наличен отворен WIFI, модулът може да работи, без дори да го конфигурира; готов за предаване на данни от фабриката без никаква необходима настройка.

Стъпка 11: Няколко думи за публиката

Хей, момчета, осъзнавам, че това изобщо не е лек за начинаещи, тъй като не споменах всеки един детайл, който трябва да бъде разгледан. Освен това този проект е наистина обширен, за да бъде обхванат в Instructable. Все пак се постарах да покрия всеки важен аспект на проекта. Знам също, че видеоклип, демонстриращ работата на проекта, би бил наистина страхотен, но тъй като това е първата ми инструкция и честно казано, това е първата ми публикация на нещо подобно, бях доста нервен да бъда пред камера.

Ако имате нужда от помощ при създаването на този проект или нещо подобно на това, просто се свържете с мен на [email protected] или можете да оставите коментар както винаги. Ще се опитам да ви помогна, доколкото мога.

Благодаря ти!!