Jump to content
iT4iT.CLUB
Kitsum

Конфигурация микроконтроллера через uart и хранение настроек в eeprom на примере mqtt логгера

Recommended Posts

Привет друзья.

В данной теме пойдет речь о конфигурации микроконтроллера через UART (Universal Asynchronous Receiver-Transmitter) интерфейс. А рассмотрим мы это на примере MQTT логгера. В данном случае, это будет логгер температуры. Мне это устройство потребовалось на работе, даже не мне, а моим коллегам, и оно действительно работает и приносит огромную пользу т.к контроль температуры производится совместно с отличной, на мой взгляд, системой мониторинга Zabbix с оперативными оповещениями, построением графиков, блэк-джеком и... Подробнее о дружбе Arduino и Zabbix можно почитать тут

Но как всегда, есть нюансы. А заключаются они в том, что в будущем, обслуживать армию мелких контроллеров придется людям, которые заняты своими задачами и им попросту некогда изучать Arduino, не говоря уже о серьезных альтернативах, разбираться в том, как прописать нужные значения переменных в программу и загрузить её в микроконтроллер. Все настройки необходимо производить быстро, с явным указанием изменяемого параметра и его значения. Ровно также, как это делается с любым промышленным оборудованием.

И тут на помощь приходит UART

Микросхема UART to USB имеется в большинстве плат семейства Arduino, а там, где её нет, обычно выведены соответствующие "пины". И все это очень облегчает жизнь т.к позволяет общаться с контроллером, просто подключив его к компьютеру напрямую или через переходник, благо их везде навалом, да и стоят они как пачка семечек. Остается только запустить любой терминал, который умеет доставлять в конец строки символ "перевод строки", что известен в народе как "\n", а в ASCII таблице имеет номер 0A.

Кстати, в Serial мониторе Arduino IDE выставить символ конца строки можно так

uart-to-usb-nl.png

Ну а дальше только, что и остается, как общаться с устройством на той стороне. И тут мы переходим к основному алгоритму программы. Но перед этим хочу отметить, и это ВАЖНО, что за любое упрощение жизни, всякие красивости и прочее, приходиться платить, и цена довольно высока! В данном случае, это ОЗУ микроконтроллера. Поэтому не раскатываем губы, а если очень хочется, то берем следующий по характеристикам микроконтроллер. А начинать мы будем с ATmega328P, что известен в народе как Arduino UNO, Arduino Nano, IBoard v1.1 и т.д по списку. Заканчивать Вы можете чем угодно, хоть ATmega2560, ESP8266 или ESP32. В противном случае, производим оптимизацию кода, отказываемся от громоздких библиотек, или вообще, от Arduino IDE.

Что мы хотим получить

  1. Вся конфигурация микроконтроллера должна храниться в энергонезависимой памяти (ПЗУ) известной нам как EEPROMM.
  2. Если в ПЗУ конфигурация отсутствует, необходимо иметь резервный план. И им станет сброс конфигурации на настройки по умолчанию. Это поведение знакомо всем, особенно по домашним дешевым маршрутизаторам, а значит, интуитивно понятно.
  3. Выводить справку при начале общения пользователя и устройства, на мой взгляд, как манеры высшего общества. Контроллер должен представляться и сообщать всю необходимую информацию о себе и о том, как с ним вести диалог.
  4. Все команды должны быть просты и иметь не двусмысленное значение.
  5. И конечно, мы должны иметь возможность просмотра текущего состояния датчиков или процессов, которыми занимается устройство в свободное от общения с нами время.

Как сохранять конфигурацию в EEPROM

Пожалуй, стоит начать с того, как сохранить конфигурацию микроконтроллера в энергонезависимую память. Для этих целей, в стандартный набор инструментов Arduino IDE входит библиотека для работы с EEPROM.

#include <EEPROM.h>

На данный момент нас интересуют две функции, это чтение и запись

EEPROM.get(address, variable);
EEPROM.put(address, variable);

Обе принимают два параметра:

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

Особенность работы этих функция заключается в том, что в зависимости от типа переданной им переменной во втором параметре, будет произведено чтение или запись ровно того количества данных которое соответствует размеру типа этой самой переменной. На простом языке это означает, что если переменная variable будет иметь типа byte, то и работать мы будем с объемом памяти в 1 байт. И тоже самое произойдет с абсолютно любым типом данных пока мы не упремся в размеры самого EEPROM или ОЗУ микроконтролера. Из этого всего следует, что мы можем создать свой собственный тип данных, разместить в нем необходимую нам информацию и всего лишь двумя функциями помещать его в память и извлекать обратно.

И в этом нам поможет пользовательский составной тип - структура (struct). Данный тип позволяет объединить в себе различные типы данных, упорядочить их и присвоить им понятные имена.

Скрытый текст

// Описываем структуру
struct user {
  char name[40];
  byte age;
};
// Объявляем новую переменную с нашим типом и помещаем в неё нужные нам значения
user anna;
anna.name = "Smirnova Anna";
anna.age  = 15;
// Записываем данные в EEPROM
EEPROM.put(0, anna);
// Объявляем еще одну переменную с нашим типом
user human;
// Читаем данные из EEPROM
EEPROM.get(0, human);
// Выводим содержимое
Serial.println(human.name); // Smirnova Anna 
Serial.println(human.age);  // 15

 

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

Наша структура будет немного сложнее, но суть остается той же самой.

// Дополнительная структура описывающая IPv4 адреса
struct addres {
  byte a;
  byte b;
  byte c;
  byte d;
};

// Структура объекта конфига для хранения в EEPROM
struct configObj {
  addres ip;
  addres subnet;
  addres gateway;
  addres dns;
  byte mac[6];
  byte hex;
  char server[40];
  char topic[40];
} config;

Данная структура хранит сетевые настройки для работы с Ethernet модулем (w5100 и выше) Arduino, базовые настройки для связи с MQTT брокером. Сразу при описании структуры мы объявили новую переменную с именем config с типом нашей структуры.

ВАЖНО: кроме наших данных в структуре имеется дополнительная переменная с именем hex. Её задача, это контроль наличия наших данных в EEPROM. Она всегда должна содержать одно и тоже значение. Представьте ситуацию, что вы взяли контроллер в EEPROM которого находится какая-либо информация (может там чисто, но мы этого не знаем наверняка) и мы прочитаем данные и поместим их в нашу переменную. В итоге мы получим данные которым нельзя доверять, а что еще хуже, это если эти самые данные нарушат работу внешнего оборудования.

Более правильным, на мой взгляд, будет проверка значений по конкретно определенным адресам. Например, мы знаем, что в 16 байте должно быть значение 0xAA и если оно действительно там, то мы убеждаемся, что это наша информация. Естественно, что контрольных точек может быть несколько и разумеется с разными значениями, это увеличит гарантию того, что данные являются нашими, но 100% гарантии не даст. Для более серьезных проектов есть более серьезные методы, например, подсчет контрольной суммы всего набора данных.

Также структура может иметь вложенные структуры, у нас ими являются: ip, subnet, gateway, dns. Вы можете отказаться от такого варианта и записывать данные просто в массив байт, как это было сделано с MAC адресом. Естественно, что обращаться к этим полям нужно по-разному.

Запись данных в поле subnet

config.subnet = {255, 255, 255, 0};

Запись данных в поле mac

byte mac[] = {0x00, 0xAA, 0xBB, 0xCC, 0xDE, 0x02};
memcpy(config.mac, mac, 6);

С записью данных в поле server все еще проще

config.server = "mqtt.it4it.club";

Функция, которая возвращает нашу структуру данных с полностью заполненными полями.

// Начальный конфиг
configObj defaultConfig() {
  configObj config = {
    {192, 168, 0, 200},
    {255, 255, 255, 0},
    {192, 168, 0, 1},
    {192, 168, 0, 1},
    {0x00, 0xAA, 0xBB, 0xCC, 0xDE, 0x02},
    0xAA, // Не трогать! Используется для проверки конфигурации в EEPROM
    F("mqtt.it4it.club"),
    F("arduino/serial/config")
  };
  return config;
}

К примеру, два последних значения записывать не обязательно, тогда эти поля останутся пусты если использовать данную функцию для возврата к "заводским" настройкам.

Вот пример того, как используя описанную нами структуру, мы проверяем целостность настроек в EEPROM и в случае не совпадения hex значений, загружаем настройки по умолчанию.

const byte startingAddress = 9;
bool configured = false;

void loadConfig() {
  EEPROM.get(startingAddress, config);
  if (config.hex == 170) configured = true;
  else config = defaultConfig();
  configEthernet(); // Функция производящая настройку сети
}

Как контроллеру начать понимать, что от него хотят

В Arduino имеется функция, вызываемая каждый раз, когда в передаваемый буфер данных попадает знакомый нам символ перевода строки.

void serialEvent() {
    // Вызывается каждый раз, когда что-то прилетает по UART
    // Данные передаются посимвольно. Если в строке 100 символов, то функция будет вызвана 100 раз
}

И в контексте обсуждаемой нами программы, мы можем представить ее в следующем виде

void serialEvent() {
  serialEventTime = millis();
  if (console.available()) {
    char c = (char)console.read();
    if (inputCommands.length() < inputCommandsLength) {
      if (c != '\n') inputCommands += c;
      else if (inputCommands.length()) inputCommandsComplete = true;
    }
  }
}

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

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

Останется только избавиться от них, и самым удобным моментом будет, когда этот поток шлака прекратиться. Чтобы об этом узнать мы будем запоминать время, когда пришел каждый из символов переданной строки перезаписывая соответствующую временную переменную данными о следующем символе и т.д пока поток не иссякнет. И как только расхождение текущего времени CPU и времени, когда поступил последний символ превысит некоторое значение, пусть это будет 1 секунда, мы очистим нашу память. Этот простой механизм напоминающий амнезию позволит избавить нас от лишних проблем.

Переменная отвечающая за размер принимаемого буфера

const byte inputCommandsLength = 60;

Теперь можно переходить к напарнице предыдущей героини и, по совместительству, основной рабочей лошадки - функции обрабатывающей адекватно полученные данные.

void serialEventHandler() {
    // вызывается в loop и проверяет взведена ли переменная inputCommandsComplete
    // в полученных данных пытается распознать команды
}

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

Разбор serialEventHandler

Полученные данные будут переданы нам в переменной inputCommands с типом String

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

inputCommands.trim();

Далее стоит отсеять команды, не несущие никакой динамической информации, например, help, restart, reset и т.п это предписывающие команды которые заставляют контроллер выполнять строго описанные функции без вмешательства в их работу.

if (inputCommands == F("help")) {
    consoleHelp();
} else if (inputCommands == F("restart")) {
    resetFunc();
} else {
    // Все сложные команды обрабатываются в этом блоке
}

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

  • ip 37.140.198.90
  • ip 192.168.0.244
  • ip 10.10.10.88

В данном случае, нам стоит понять, относится ли данная команда именно к ip адресу. Для этого в наборе String имеется отличный метод, позволяющий производить сравнение переданного ему параметра с началом строки.

if (inputCommands.startsWith(F("ip"))) {
    // Строка inputCommands начинается с пары символов "ip"
}

Если все идет так, как мы задумали, то нам стоит отделить динамическую часть - наш параметр, от заголовка и получить полезную нагрузку. В этом нам поможет, опять же из набора String, метод substring позволяющий получать часть строки с указанием начального и конечного символа подстроки. Последний параметр указывать не обязательно и в таком случае мы получим всю строку начиная с указанного символа.

inputCommands.substring(4)

В данном случае начиная с 4-его и заканчивая последним. И как Вы успели заметить, отсчет мы начинаем не с третьего символа, что соответствует нашей строке без вступительного "ip", а на один больше т.к между заголовком и параметром имеется разделяющий символ в виде пробела.

Далее, полученную строку мы передадим в функцию, занимающуюся разбором на компоненты и принимающую следующие параметры:

  1. Указатель на переменную с типом char, для этого нам потребуется преобразовать наш тип String
  2. Символ разделителя, что для IPv4 является точка "."
  3. Указатель на массив типа byte, которому будет присвоен результат разбора
  4. Количество искомых элементов в строке
  5. И система счисления, подразумеваемая в качестве исходной для записи элементов подстроки
/*
    Парсинг
    https://stackoverflow.com/questions/35227449/convert-ip-or-mac-address-from-string-to-byte-array-arduino-or-c
*/
void parseBytes(const char* str, char sep, byte* bytes, int maxBytes, int base) {
    for (int i = 0; i < maxBytes; i++) {
        bytes[i] = strtoul(str, NULL, base);
        str = strchr(str, sep);
        if (str == NULL || *str == '\0') break;
        str++;
    }
}

В нашем случае выглядеть это будет следующим образом

byte ip[4];
parseBytes(inputCommands.substring(4).c_str(), '.', ip, 4, 10);

А дале все становится еще проще, попросту проверить попадает ли наш ip адрес, в список правильных адресов. И самой простой проверкой послужит проверка первого байта адреса на несоответствие не угодным нам сетям (0, 127, 255)

if (ip[0] != 127 and ip[0] != 255 and ip[0] != 0) {
    // Производим необходимые нам действия с ip адресом, например, запись в конфиг
    config.ip = {ip[0], ip[1], ip[2], ip[3]};
}

Вы в праве реализовать собственные проверки, какие только душе угодны.

Также хотелось бы отметить, что обрабатывать некоторые параметры проще и быстрее через их короткие записи. К таким можно отнести маску подсети устройства. Например, привычный дня нас адрес 192.168.0.1 с маской подсети 255.255.255.0 можно записать в виде 192.168.0.1/24, где цифра 24 указывает нашу подсеть в краткой форме. А, следовательно, мы можем записать несколько кратких форм масок подсети в следующем виде:

  1. subnet 255.255.255.0 или subnet 24
  2. subnet 255.255.0.0 или subnet 16
  3. subnet 255.0.0.0 или subnet 8

Это основные маски, и я не описывал все существующие т.к в этом нет нужды, но если Вам интересно, то почитать про них можно в wikipedia.

if (inputCommands.startsWith(F("subnet"))) {
    String input = inputCommands.substring(8);
    if (input == F("24"))      config.subnet = {255, 255, 255,   0};
    else if (input == F("16")) config.subnet = {255, 255,   0,   0};
    else if (input == F("8"))  config.subnet = {255,   0,   0,   0};
    else {
        // Все остальные маски попадают в этот блок
        byte subnet[4];
        parseBytes(input.c_str(), '.', subnet, 4, 10);
        config.subnet = {subnet[0], subnet[1], subnet[2], subnet[3]};
    }
}

MAC адрес хранится у нас в виде массива байт. Его перезапись другим массивом производится с помощью функции memcpy

if (inputCommands.startsWith(F("mac"))) {
    byte mac[6];
    parseBytes(inputCommands.substring(4).c_str(), ':', mac, 6, 16);
    memcpy(config.mac, mac, 6);
}

Изменение адреса MQTT сервера

if (inputCommands.startsWith(F("server"))) {
    String server = inputCommands.substring(8);
    server.trim();
    if (server.length() < 40) server.toCharArray(config.server, 40);
}

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

Как это выглядит на практике

Заливаем программу в микроконтроллер и подключаемся к Arduino по usb или через переходник. Открываем терминал и нас приветствуют краткой справкой с описанием доступных команд.

- ---------------------------------------------------------------------------------------
# Sensor with data sending to mqtt server (c) it4it.club
# Use the "config" command to view the current configuration
# To change the configuration, specify the parameter name and its new value with a space,
# for example "ip 192.168.0.200", "subnet 255.255.255.0" or "mac AA:BB:CC:DD:EE:FF"
# You can also specify a subnet using the mask 24, 16 or 8
# Additional commands:
# sensors - view current data from sensors
# config - view current configuration
# save - saves the current configuration
# reset - resets all settings
# restart - restarts the device
# eeprom clear - removes all contents of eeprom
# help - view this help
- ---------------------------------------------------------------------------------------

Т.к. в EEPROM микроконтроллера не была обнаружена конфигурация (волшебный hex байт нам подсказал), то были задействованы стандартные настройки. Просмотреть текущую конфигурацию можно командой config

config
# ip: 192.168.0.200
# subnet: 255.255.255.0
# gateway: 192.168.0.1
# dns: 192.168.0.1
# mac: 00:AA:BB:CC:DE:02
# server: mqtt.it4it.club
# topic: arduino/serial/config

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

ip 10.10.10.99
# ok
gateway 10.10.10.1
# ok
dns 10.10.10.1
# ok

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

save
# ok
restart
# ok
# restarting device...

Если параметр был успешно принят, то контроллер ответит нам "ok", а в противном случае ругнется.

ip 127.0.0.1
# bad ip

Также мы получим негативный ответ если команда не была распознана.

qwerqwer1243
# bad command

С остальными командами Вы разберетесь самостоятельно.

arduino-zabbix-mqtt2.JPGarduino-zabbix-mqtt1.JPG

arduino-zabbix-mqtt3.png

Исходник: MQTT_CLIENT_328_SERIAL_CONFIG.zip

PS: в общем то это статья родилась только для того, чтобы в соседнем форуме с системой мониторинга Zabbix появилась ссылка на устройство, но я надеюсь, что она также станет полезна любителям домашней автоматизации и не только.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By Kitsum
      Всем привет, в этой статье поговорим об уже надоевшей всем теме - "Метеостанция". Каждый пытается сделать что-то свое, вот и я не стал исключением и попытался материализовать свои эротические фантазии на контроллере ESP8266. Тема задумывалась уже давно как некое обновление для предыдущего проекта этой тематики, но из-за своей неспешности переросла в нечто самостоятельное.


       
       
      При всей привлекательности микроконтроллера ESP8266 с его большим объемом памяти, железной поддержкой Wi-Fi и массой разных плюшек, он не лишен недостатков. Самый основной - ограниченное количество поддерживаемых одновременных TCP соединений равное 5. Если превысить этот лимит, то контроллер потеряет связь с окружающим миром, при этом watchdog будет думать, что все в порядке, а следовательно, даже не попытается нам помочь. Будем стараться это помнить!
      Стоит начать с концепции
      Доступ к данным метеостанции нужно получать без установки внешних приложений и под любой операционной системой. Для этих целей подойдет практически любой современный браузер. Меня всем устраивает Chrome. Раз уж за основу взят HTTP протокол, стоит озаботиться экономией трафика и ограничением числа TCP соединений. Хорошим тоном будет передача всего необходимого для формирования страницы контента только при первом обращении, а все последующие операции, такие как отображение показаний с датчиков или настройку контроллера, производить через API. В этом нам поможет JQuery. А вот, чтобы ослабить болевые ощущения от передачи файлов с SPI Flash в браузер, стоит предусмотреть систему кэширования, например, Etag. Это позволит отдавать тяжелый контент единожды, а при последующих загрузках страницы просто подтверждать его актуальность на уровне Web сервера микроконтроллера и кэш браузера вступит в игру, неимоверно уменьшив время загрузки страницы! "Вы были правы в одном, Мастер: переговоры были недолгими." © Звездные войны. Эпизод 1 Из-за того, что метеостанция с датчиками и контроллером должна располагаться на улице, жизненно необходимо предусмотреть возможность обновлять прошивку ESP через Web интерфейс. Аналогичным образом должны обновляться файлы Web сервера расположенные на SPI Flash. Этот и предыдущий пункт вкупе позволят обновлять функционал микроконтроллера из домашней сети или из интернета, если конечно в этом возникнет острая необходимость. Чтобы никто посторонний не могу вмешаться в работу устройства или изменить файлы Web сервера, последний должен хотя бы как-то себя защищать. Пускать в панель управления только после авторизации, блокировать доступ при попытках брутфорса пароля. В конце концов, контроллер обязан самостоятельно генерировать ключи (salt) для авторизации, дабы сделать алгоритм непредсказуемым и исключить потенциальный взлом, в случае если злодей завладеет исходниками проекта. Понятно, что кому она там нужна, эта метеостанция, если её не завязывать с умным домом, если только из-за спортивного интереса, но как говориться “Береженого Бог бережет”. Датчики стоит расположить по уму - в метеобудке, а вот контроллер в сухом и закрытом боксе. Объединить их между собой, как мне кажется, удобнее по I2C шине - минимум проводов, максимум удобства. Практически на всех вариантах плат ESP-xx имеется штатный светодиод, можно воспользоваться им как для индикации режимов и состояния микроконтроллера, так и для вывода какой-либо промежуточной информации. Что касаемо режимов работы ESP8266, как ни странно, но он должен находить домашнюю Wi-Fi сеть и подключаться к ней. Если вдруг звезды не были к нам благосклонны, и домашняя беспроводная сеть приказала долго жить, контроллер обязан перейти в режим точки доступа (AP) дабы к нему можно было подключиться с какого-либо устройства и перенастроить его на другую сеть. А вот пока последнее не произошло, ESP должен периодически сканировать эфир в поисках долгожданной домашней точки доступа и, если боги были к нам милосердны, и домашняя сеть появилась в эфире, незамедлительно переключиться в режим клиента (STA) и в пылу страсти воссоединиться с ней. Ну и естественно, как же без отправки данных на внешние ресурсы, сейчас без этого не обходится ни одна уважающая себя кофеварка, не говоря уже о метеостанции. Думаю, что основным блюдом станет протокол MQTT, это уже облегчает возможность интеграции с умным домом, стулом или той же кофеваркой. Ну а на закуску добавим поддержку "ThingSpeak" и "Народного мониторинга". При желании можно нарастить функционал, благо памяти у микроконтроллера еще много. Как я себе это представляю
      Учтите, что на видео, данные с датчиков, эмитируются самим микроконтроллером, это нужно для наглядности. В жизни метеорологическая обстановка намного спокойнее слава Богу.
      Перейдем к физической сборки устройства
      Как по мне, так самый оптимальный вариант, это воспользоваться отладочной платой NodeMCU V3 и базой для неё. Таким образом, мы получим отличный комплект с разведенной на его борту всей необходимой обвязкой и возможностью питать устройство от 5 до 24 Вольт.

      Отладочная плата на базе, и смотрится хорошо, и удобства хоть отбавляй.

      Заливаем прошивку, образ SPI Flash и подключаем четырьмя проводами датчики. Справится даже ребенок.
      Ссылки:
      Базовая плата для NodeMCU V3 с преобразователем питания 5-24V в 5V Отладочная плата ESP8266 от NodeMCU Естественно никто не запрещает Вам развести свою плату. Если Вы это сделаете, скиньте нам свое творение, возможно мы перейдем на него. В идеале, все должно размещаться в метеобудке.
      Датчики взятые за основу
      Датчик уровня освещенности BH1750
      Интерфейс шины I2C Диапазон измерений от 1 до 65535 Lx Фильтр световых шумов 50/60 Hz Возможность смены адреса на шине Не требует калибровки Рабочая температура от -40 до 85 градусов C Питание от 2.4 до 3.6 V Датчик атмосферного давления BMP085/180
      Интерфейс шины I2C Диапазон измерения от 300 до 1100 hPa Встроенный датчик температуры Не требует калибровки Питание от 1.8 до 3.6 V Датчик влажности SI7021-A20
      Интерфейс шины I2C Диапазон измерений от 0 до 100% RH Погрешность измерения 3% RH в диапазоне от 0 до 80% RH Рабочая температура от -40 до 125 градусов C Встроенный датчик температуры с диапазоном измерения от -40 до 85 градусов C Не требует калибровки Питание от 1.9 до 3.6 V Альтернативные датчики
      Датчик влажности HDC1080
      Интерфейс шины I2C Диапазон измерений от 0 до 100% RH Погрешность измерения 2%, устаревание (износ) 0.25% в год. На последнее значение могут влиять внешние факторы. Рабочая температура от -20 до 70 градусов C Встроенный датчик температуры с диапазоном измерения от -40 до 125 градусов C Не требует калибровки Питание от 2.7 до 5.5V Датчик влажности HTU21D
      Интерфейс шины I2C Диапазон измерений от 0 до 100% RH Погрешность измерения 2%, устаревание (износ) 0.5% в год. На последнее значение могут влиять внешние факторы. Рабочая температура от -40 до 125 градусов C Встроенный датчик температуры с диапазоном измерения от -40 до 125 градусов C Не требует калибровки Питание 3V, максимум 3.6V Сборка 3 в 1 из датчиков BH1750, HTU21D и BMP180
      Все используемые датчики описаны выше Очень компактные размеры Комплексный датчик BME280 для измерения температуры, влажности и атмосферного давления
      Интерфейс шины I2C Рабочая температура от -40 до 85 градусов C Диапазон измерение влажности от 0 до 100% RH с точностью 3% в диапазоне от 20 до 80% RH. Устаревание (износ) 0.5% в год. Диапазон измерения давления от 300 до 1100hPa Диапазон измерения температуры от -40 до 85 градусов C Напряжение питания от 1.7 до 3.6V Все датчики очень компактные, способны выдержать большие перепады температуры, довольно точны, имеют одинаковое напряжение питания и опорное напряжение I2C равное напряжению питания. На мой взгляд, они идеально подходят для эксплуатации в уличных условиях, на большей части территории нашей родины.
      Теперь настал момент озаботиться, где описанные выше ребята будут жить. В прошлый раз мы использовали для этих целей, найденную в подножном корме, электрическую распределительную коробку. Кроме дешевизны в этом решении нет ничего положительного.
      В этот раз мы воспользуемся более серьезным вариантом – "Метеорологическая будка Стивенсона". Она способна защитить датчики от прямых воздействий окружающей среды, но при этом имеет открытую структуру со стенками в виде жалюзи. Удобно, красиво и самое главное – правильно!
      Будка печатается на 3D принтере по эскизам опубликованным на Thingiverse неким kowomike, спасибо добрый человек! Архив с эскизами можно будет скачать в конце поста.

      Фото готовой будки

      Шпилька М8 крепится через зажимной хомут к мачте уличной антенны.
      Примерка. Шпилька практически не укорачивалась, чтобы не закрывать будку параболической Wi-Fi антенной.
      Хотя в моем случае все это сделано не правильно т.к это солнечная сторона дома. Доступа на теневую сторону дома у меня нет, поэтому приходиться довольствоваться тем, что имеем. По прошлой метеостанции мне говорили "на солнечной стороне все эти измерения - сферический конь в вакууме, слепи %описание-многА-букАв% и закрепи на теневой стороне дома".
      Я пока живу в панельном многоквартирном доме, как и не малая часть нашей страны. Доступ к теневой стороне дома (а для меня, по факту, это окна в подъезде) - прямой вызов всем гопникам района трущимся рядом, любопытным соседям с бегающими глазками и всей элите человечества скрашивающей фоном мою унылую и слишком простую, по их мнению, жизнь. Думаю, что мысль я донес.

      Датчики располагаются на разных уровнях. В основании находится датчик освещенности BH1750 и смотрит ровно вниз. Мне кажется, так он будет меньше пачкаться и покрываться пылью и при этом смотреть наружу сквозь минимальное количество препятствий для солнечного света. Вообще размещение этого датчика, это целая головная боль. Как не крути, все будет не то. Оставил так, ведь по сути важны не сами показания, а тенденция изменения. Хотя кого я пытаюсь обмануть, точность важна всегда! Предлагайте свои варианты.
      Намного проще обстоят дела с датчиком атмосферного давления BMP180 и влажности SI7021, кстати, с последнего мы также будем забирать данные о температуре. Их размещаем в оставшемся свободном пространстве будки, благо его там с избытком, но не в конусе т.к пространство в нем менее проветриваемое.

      Все хозяйство подключается между собой следующим образом
      NodeMCU | ESP 07/12 | Датчики ----------------------------- D2 | GPIO 4 | SDA D1 | GPIO 5 | SCL 3.3V | 3.3V | 3.3V GND | GND | GND ВАЖНО: при финальном монтаже устройства на его место службы, обязательно установите перемычку между пинами GPIO 0 (D3) и питанием 3.3 Вольта. Причины её установки описаны в закрепленном сообщении с описание обновления от 12.08.2017.
      Сам микроконтроллер будет спрятан в уже знаменитую распределительную коробку, закрепленную на шпильке, чуть ниже будки Стивенсона. У меня все находится на стадии неторопливой сборки с попутным поиском более удачных идей.
      Плата расширения, на которой будет установлена плата NodeMCU, закреплена через ножки для крепления компьютерных материнских плат в корпусах.

      Разъемы для подключения внешних датчиков и питающей линии установил на местах где была пара штатных заглушек. Закрепил все через переходную пластину, выпиленную из куска фольгированного текстолита. Естественно, предварительно пластина была протравлена, а вся медь искоренена, ибо в этом случае она нам не друг.
      Также была предусмотрена проставка из полиэтиленового поролона (используется в качестве упаковочного материала при транспортировке грузов) между текстолитом и корпусом, общей толщиной 5мм, а после затяжки крепежных винтов, его толщина не превышает 1мм. Это было сделано из-за опыта эксплуатации предыдущего (временного) бокса для этой метеостанции. Без проставки влага быстро найдет путь вовнутрь, и срок службы устройства снизится.
      Производим примерку.
      При окончательном монтаже обязательно необходимо удалить все не плотно прилегающие части полиэтиленового поролона, то есть те части, которые располагаются снаружи и не сдавлены крепежной текстолитовой пластиной. Это необходимо сделать для препятствования накоплению влаги в доступных для неё полостях. Также пришлось увеличить число крепежных болтов для более надежного прилегания текстолита, в противном случае он может выгибаться.
      Все самое сложное позади, остается только вывести на один разъем шину i2c с питание 3.3 Вольта, а на другой подвести пины питания платы расширения. Но т.к у меня валялся "хвост" отрезанный когда-то от не рабочего блока питания маршрутизатора, и я не побрезговал им воспользоваться по прямому назначению.

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

      Общий вид получился таким
      А вот как все выглядит в боевых условиях. Кстати, могу предложить идею с помещением в бокс мешочка содержащий впитывающий влагу гель, они часто встречаются в коробках с обувью. Если все герметично, то он впитает остатки влаги, а если нет, то лишним уж точно не будет.


      Требования (!!!Читать обязательно!!!)
      Arduino IDE с поддержкой контроллера ESP8266, версия 2.5.2 (на версиях выше работоспособность не проверялась) Установленный модуль в Arduino IDE для загрузки файлов во Flash память микроконтроллера. Как установить описано тут. Любой модуль на базе ESP8266 c Flash 4MB (3MB выделяем под SPIFFS) В параметрах выставляем lwIP версии 2 и максимальную производительность (lwIP v2 Higher Bandwidth) Сам архив с последней версией проекта. Скачать можно в конце статьи или по этой ссылке.   
      Обязательные библиотеки (!!!Читать обязательно!!!)
      ArduinoJson (v5.13.5) PubSubClient Ссылки на библиотеки сенсоров указаны в комментариях к коду. Сами библиотеки, как и обслуживаемые ими сенсоры, не являются обязательными. Вы вольны использовать любые датчики, как физические, так и программные.
      Порядок установки (!!!Читать обязательно!!!)
      Изучите файлы проекта с примерами использования тех или иных сенсоров. Все файлы с примерами начинаются с префикса users_, это users_auto.h, users_bme280_x2.h и т.д. Загрузите необходимые Вам библиотеки или используйте эти файлы как пример для добавления иных датчиков. Выставите необходимые настройки для контроллера в среде разработки Arduino IDE. Пример настроек указан на скриншоте выше. Обязательно убедитесь, что выбрано правильное распределение места для внутренней файловой системы, это значит, что 3MB должно быть выделено под файловую систему. Также проверяем, чтобы использовался lwIP v2 в режиме максимальной производительности (lwIP v2 Higher Bandwidth). Произведите загрузку программы с помощью среды разработки (Ctrl + U). Произведите загрузку содержимого каталога data в файловую систему. Меню/Инструменты/ESP8266 Sketch Data Upload Перед тем как устанавливать метеостанцию на постоянное место жительства, подтянуть GPIO-0 (пин D3 на плате NodeMCU) к питанию 3.3V. Во время данной процедуры, питание на контроллере должно отсутствовать. Первый запуск (!!!Читать обязательно!!!)
      Помните, что вся конфигурация микроконтроллера производится исключительно через web интерфейс. Никаких изменений значений тех или иных параметров в коде не требуется, а подобную практику будем считать плохим тоном.
      И так, после запуска микроконтроллера он сразу перейдет в аварийный режим и поднимет собственную точку доступа с именем WeatherStation. Это нормальное поведение т.к подразумевается использование метеостанции в домашней беспроводной сети, ну а раз о ней пока ничего не известно, то и подключаться не к чему.
      Подключитесь к данной сети с любого удобного устройства и перейдите в панель управления (для этого имеется соответствующая иконка, запутаться невозможно), контроллер будет доступен по адресу http://espws.local или http://192.168.4.1 При попытке входа в панель управления будет запрошено имя пользователя и пароль, по умолчанию admin/admin. После входа в панель управления перейдите в раздел "Основные настройки WiFi" и укажите имя и пароль Вашей домашней сети, а также, при необходимости, укажите пароль для подключения к точке доступа поднимаемой контроллером в аварийном режиме. Если все сделано правильно, то контроллер подключится к домашней сети в течении 5-и минут.
      Если Ваша домашняя сеть скрыта, то после первоначальной настройки необходимо перезагрузить контроллер. Это необходимо из-за частичной поддержки работы со скрытыми сетями. После перезагрузки контроллер увидит Вашу сеть и запомнит её MAC адрес. Помните об этом если захотите сменить домашний маршрутизатор.
      Хотите помочь проекту или спонсировать новый?
      Yandex.Money PayPal.me Файлы
       
    • By Kitsum
      Описанный ниже велосипед является продолжением одной из моих статей на другом, интересном мне, ресурсе. Продолжение и все последующие обновления будут происходить только на it4it.club
      Для начала, хочу процитировать самого себя и тем самым дать пояснения: почему, зачем и для кого это нужно.
      Данная тема получила большую популярность у коллег и не раз выручила Вашего покорного слугу, не дав разгореться стулу на котором он сидит.
      Но имеющегося функционала стало не хватать, требовалось не только слышать и иногда видеть, а еще получать удаленный доступ к оборудованию и лицезреть всю картину в целом.
      Задача поставлена, идем исполнять, но с начало забегу немного вперед и продемонстрирую текущий функционал.
      Общее окно программы переработано и теперь отображает список всех групп из Zabbix с их хостами. Список активных триггеров переехал в нижнюю часть окна и отображает дополнительную информацию об узлах с которыми не все гладко. Сам список можно увеличивать, если все совсем плохо, или уменьшать если выражение "Хьюстон у нас проблемы" Вы слышите только в фильмах. Также появились цветные маркеры важности триггера. По двойному клику по активному триггеру мы перемещаемся в соответствующую группу где находится проблемный узел.
      Не забыли и про то, ради чего вся начальная песня и писалась - трей с всплывающими оповещениями и звуковым сигналом. Основное окно сворачивается именно туда, чтобы не залеживаться на панели где ценится каждый свободный пиксель.
      Хосты в группах стали кликабельны, правда пока только ПКМ, и имеют всплывающее меню позволяющее выполнять банальные действия:
      Подключение к узлу:
      Telnet SSH RDP VNC Проверка соединения:
      Ping Traceroute Естественно его можно расширить, добавив всяких вкусностей по мере возрастания аппетита IT отдела.
      Программа по прежнему имеет серверную и клиентскую часть, что позволило организовать кэширование запросов и осуществлять оповещения в момент определения проблемы сервером, а не по таймеру обновления, как это организовано в dashboard zabbix. Раньше узнали о проблеме, раньше приступили к устранению. Естественно и устаревшие триггеры убираются также оперативно.
      Также это позволило избавить программу от информации о доступе к серверу, что мне кажется не приемлемым для оповещалки. Чем меньше дырок, тем крепче сон.
      Приступим к реализации.
      Ну и естественно, Ваш покорный слуга еще не научился писать на C++ ничего более сложного чем "Hello World", поэтому клиент и сервер будет написан на PHP. За исключением того момента, что клиентская часть (при помощи магии Гарри Поттера) станет бинарным файлом. Бог с ним, серверная часть не доступна обывателю, а это самое важное!!!
      Для начала, нужно придумать безопасный и понятный алгоритм не нагружающий сервер т.к клиентов может быть 100и или 1000и, всякое бывает. Все не безопасные команды обязаны выполняться на сервере без участия клиента. Дальнейшая работа клиента: обработка данных, выполнение действий с триггерами и т.п должно выполняться только у клиента, не затрагивая сервер.
      При обращении клиента к серверу по http происходит проверка его ip на наличие в списках разрешенных. В противном случае показываем фигу. Проверяем, наличие актуального кеша, и отдаём его. Если кеша нет, генерируем новый. Если запрос прилетел от zabbix: принудительно считаем кеш устаревшим, генерируем новый и после этого рассылаем всем клиентам оповещения по UDP протоколу. Это позволит свести расход ресурсов базы данных к нулю т.к все клиенты ринутся забирать новые данные, а все уже в кеше. Супер, все дешево и сердито.
      Серверная часть представляет из себя файл index.php где-то на Вашем web сервере. Актуально для Zabbix 2.4 (скорее всего будет актуальна и для последующих версий, будем проверять по мере возрастания аппетита).
      Для дополнительной безопасности рекомендую создать отдельную учетную запись в базе данных с правами только на чтение и только к базе zabbix. Это актуально в наши дни.
      Переходи в zabbix
      Первым делом переходим в Настройка -> Действия -> Источники события: Триггеры и создать новое действие. Назовем случайным образом, например Report problems to ZabbixTrigger.
      В условиях выставляем
      Значение триггера = ПРОБЛЕМА Значение триггера = OK Это все необходимо, чтобы проблемы в GUI появлялись и исчезали точно именно тогда, когда это происходит в Zabbix (не путать с dashboard).
      Вкладка "Операции" должна выглядеть следующим образом. Естественно что путь до php скрипта должен быть вашим.
      Вуаля! Если Вы все сделали правильно (без кардинальных изменений), то я рад приветствовать нового ездока моего велосипеда. Поедем тандемом!
      Сам клиент прикреплен в конце поста.
      Для тех, кто читает титры в кинотеатре
      При запуске будет создан файл config.ini в корне программы. При необходимости, измените его настройки, благо их не много.
      [server] url="http://zabbix/zabbix-gui" update="60" [client] showalarm="20" Параметр url отвечает за http путь до скрипта на сервере, update за интервал (в секундах) обновления данных с сервера, а showalarm вроде как должен влиять на время отображения всплывающей подсказки в трее.
      Теперь немного структуры.
      В каталоге sounds находится звук оповещения о новом триггере, формат ogg Каталог icons содержит маркеры триггеров. trigger00 - для нормального состояния, а все последующие соответствуют начальным настройкам zabbix во вкладке Администрирование -> Общие раздел Важность триггеров. Можете изменить на свои цвета, программа все подхватит при перезагрузки. Ну и на закуску каталог ext, это как говорится для меломанов, содержит фри программы для обработки внешних действий клиента. Вы можете заменить их на свои при условии, что стандартные имена параметров запуска и их последовательность совпадают. PS: На этом все, спасибо тем кого это заинтересовало. Предлагайте свои идеи или способы доработки велосипеда. А если найдется программист на C++ так милости просим. В любом случае, функционал будет в дальнейшем расширяться.
      zabbixTrigger.zip
    • By Kitsum
      Модуль предназначен для системы мониторинга Zabbix. Работает в качестве отдельного демона и осуществляет транзит сообщений от брокера до хостов в системе мониторинга. Подробное описание модуля можно посмотреть в следующей теме.
       
    • By Kitsum
      Демон осуществляет транзит данных с MQTT брокера в СУБД MySQL. Можно переправлять как все сообщения, так и конкретные топики. Подробное описание можно посмотреть в следующей теме.
       
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...