Kitsum

@wildray под младшим братом я подразумевал возраст С NRF поиграемся немного позже. Сейчас необходимо завершить другие идеи с счетчиками воды, MQTT сервером (mqtt.it4it.club) и исправить косяки в метеостанции. Также хочется попробовать ESP32, но это тоже будет позже. Возможно кто-то поделится своими наработками.

@wildray доброе время суток. Вопрос дизайна, пожалуй, один из самых острых. Над этим стоит подумать, ведь у всех свое представление о нем, а угодить каждому невозможно. Но реализовать Ваше пожелание совсем не сложно. Имеется структура sensor описывающая переменные в которых хранятся данные с датчиков, в том числе и логи. Объявите новые переменные для внутреннего датчика BME280. Далее заполняйте их в функции readSensors, аналогично тому, как это делается с внешним датчиком. Для передачи этих данных в web сервер посмотрите на функцию web_api_sensors. В ней необходимо добавить ваши данные в json объект sensor. Этого будет достаточно, но если потребуется ведение лога, то потребуется провести аналогичные операции с функциями sensorLogWrite и web_api_sensors_log. Скорее всего, в будущем, будет отдельный модуль подключаемый по I2C и позволяющий использовать различные автономные беспроводные датчики на базе NRF. Я думаю, что не стоит нагружать WiFi лишним трафиком т.к мы по прежнему имеем ограничение в количестве TCP соединений. Возможно стоит посмотреть в сторону младшего брата контроллера - ESP32. По большому счету все устройства которыми мы пользуемся для подключения к метеостанции уже имеют на борту часы. А наличие NTP клиента подразумевает постоянное подключение к сети в которой имеется NTP сервер или выход в интернет. Хочу заметить, что это маловероятно при использовании метеостанции в гараже. Но если Вы заметили, то суточный график с датчиков выстраивается с отметками даты и времени, и при этом на ESP8266 нет часов. Тут как раз берется за основу время на устройстве с которого Вы просматриваете этот график, это легко проверить, просто переведя часы на этом устройстве. Даже в самой удаленной точке планеты, при условии доступа к GSM связи, Вы уже получаете точное время. Фазу луны можно рассчитать основываясь на дате и времени, полученного от устройства с которого просматриваете страницу Web сервера микроконтроллера. А вот для расчета рассвета и заката необходимо знать не только дату и время, но и точные координаты расположения метеостанции на планете. В принципе это можно попробовать "спросить" у мобильного устройства, но в случае стационарного компьютера, получить координаты просто так не получится. В общем, везде есть нюансы, но сами по себе предложения интересны и их стоит рассмотреть.

В файле ESP.cpp можно подсмотреть какие события перезапуска может различать ESP8266 В принципе, основные причины различать можно. Надо проверить, какой код вернется в случае использования глубокого сна при отключенном пробуждении по таймеру и использовании RST. Я смотрю в сторону транзисторного управление портом CH_PD или VDDA с помощью КТ315 или S8050. После пробуждения ESP берет на себя обязанность по контролю этого порта. В свою очередь, контроллер счетчика, убедившись, что транспорт проснулся, снимает с себя обязанности по поддержанию его питания и начинает передачу показаний, а заодно спрашивает о статусе последней передачи данных на сервер. Теперь ESP принадлежит самому себе и после завершения поставленной перед ней задачи снимает питание с транзистора. Также надо подумать о возможности конфигурации всех этих ребят через Web - отдельный режим, вызываемый внешним раздражителем, скорее всего кнопкой. А вот если у ESP8266 уже имеется доступ к домашней сети, то можно производить конфигурацию через MQTT. Держать отдельный топик с логическим значением 0/1 и если появилась 1, то не записать данные счетчиков в соответствующие топики, а наоборот, прочитать их и вернуть логическое значение в 0, тем самым подтвердить чтение данных. Получается своего рода калибровка показаний. Может быть глупо, но это первое, что пришло мне в голову помимо Web интерфейса. На сколько это надежный вариант в плане безопасности передачи данных? У WiFi какое-никакое шифрование. Возможно этот вопрос не уместен, но все-же, вдруг соседские дети проявят интерес и попробуют подменить данные. В случае полной автоматизации, можно получить сюрприз в квитке об оплате. У меня есть несколько модулей с NRF, но до их применения я пока не добрался.

@Alex_DIY думаю, что мы говорим об одном и том же, но немного по-разному. В программе мы может узнать причину пробуждения, если память не изменяет, то поведать об этом нам могут ESP.getResetReason(); ESP.getResetInfo(); Но, к сожалению, в случае внешнего прерывания это не поможет. Счетчики придется заводить также на RST, но не напрямую, а через обвязку в виде конденсатора или иным способом. Это нужно, чтобы порт подтягивался к земле кратковременно, в противном случае контроллер не запустится. Но этого по-прежнему будет не достаточно т.к нам требуется отличать какой из счетчиков нас побеспокоил. Видимо придется подтягивать RST дважды, при замыкании и размыкании сигнальной цепи счетчика. Тогда получится выделить по дополнительному порту, продублировать каждый из сигналов на них и таким образом ориентироваться в том, что происходит. Ну и сразу минусы: Много обвязки Просыпаться нужно в два раза чаще Велика вероятность допустить ошибку в расчетах Не нужные сложности Но из-за спортивного интереса продолжим. Требуется передача показаний между пробуждениями. Для этого у нас есть доступ к области памяти, в которой можно хранить данные между циклами перезапуска ESP. ESP.rtcUserMemoryWrite(offset, &data, sizeof(data)) ESP.rtcUserMemoryRead(offset, &data, sizeof(data)) Так мы может держать текущие показания под контролем, а в случае, если память пуста, диагностировать потерю питания и поднять тревогу, требуя пользователя произвести сверку значений. Также переносить эти значения в EEPROM при передачи данных на сервер умного дома, это каждые 10-100 литров по расходу. Я думаю, что это вполне можно реализовать и даже будет работать. На сколько эффективно, пока под вопросом. Но еще проще взять дополнительный контроллер и распределить задачи между ними - один считает, другой передает. Тем более, что цена повышается на стоимость чашки кофе. Батарею какой емкости Вы используете? Какова частота замены аккумулятора? Рассматривали ли Вы варианты зарядки аккумулятора от солнечной батареи или другого источника?

@LogOFF доброе время суток. Исходник: ESP8266_WS_iT4iT.CLUB_LogOFF.7z

@Alex_DIY Работа от собственного источника питания, это независимость системы, естественно при условии разумного аппетита. Внешнее питание может пропасть и могут появиться расхождения показаний между контроллером и счетчиком. Но я не вижу трудностей для поддержки работы как от аккумулятора, так и от внешнего источника. С глубоким сном и прерываниями для ESP8266 отдельная история. Программа однозначно будет крутиться в пределах функции Setup и передавать данные между пробуждениями придется через RTC. Также есть нюансы с потреблением при пробуждении. Вычитал, что от версии SDK зависит аппетит, а связано это с конфигурацией WiFi еще на самом старте микроконтроллера и до начала выполнения пользовательской программы. В общем тонкостей очень много, все нужно учесть. Я пока экспериментирую на Atmega328p. Пока в виде Arduino UNO но, когда будет до конца продумал алгоритм и готова сама программа, будет использован голый микроконтроллер с частотой 8мГц и тактированием от внутреннего кварца. Два порта настроены на вход, используют внутреннюю подтяжку к питанию и завязаны на внешнее прерывание, режим FALLING. Внешне порты подтянуты к земле через конденсаторы 0.1 мкф. Счетчики, естественно, коммутируют землю. Таким образом получается бороться с дребезгом. Возможно стоит коммутировать счетчики через дополнительный резистор на 1-2 кОм. По идеи суть работы довольно проста. Считаем импульсы, инкрементируем показания и засыпаем. При расходе каждых 10-и или 100-а литров воды, производим измерение заряда аккумулятора и будем транспортный контроллер - ESP8266 через CH_PD. Возможно стоит с начало будить, а потом измерять заряд. Передаем данные нашему транспорту и можно засыпать, но в таком случае, ESP должен самостоятельно позаботиться о контроле за CH_PD. Ну и последующая передача данных на сервер и отключение. Если во время связи появились проблемы, то запоминаем это и сообщим о них первому контроллеру в момент очередного пробуждения. Возможно ему будет полезно об этом знать... К программе для ESP тоже имеется ряд ограничений, но до этого еще далеко. Полностью согласен, но это очень хороший бонус к устройству и с этим связаны отдельные мысли и идеи.

@Alex_DIY Вот, что мне понравилось по теме дозиметра. 1. На таймере и умножителе. Таймер заменяем микроконтроллером, накачка по прерыванию с обратной связью, все остальное время ведем лог и работаем с I2C. 2. Дозиметр ArDOs. В принципе, все готово, остается только выбросить все лишнее (подготовить к стационарной работе), а оставшееся подправить под себя. Что касаемо контроля расхода воды. Мои познания в микроконтроллерах, это чистой воды хобби, которое появилось совсем недавно. Опыта разработки коммерческих проектов не имею, поэтому отталкиваюсь от мысли - "что получится, то получится". А хочется, чтобы получилось следующее: Учет расхода холодной и горячей воды Возможность работать длительное время в автономном режиме от аккумулятора Передача показаний по WiFi (MQTT, GET) или 433мГц (скорее всего отомрет) Проработать варианты автоматической передачи показаний (средствами умного дома) в МУП РАЦ (расчетно-аналитический центр) или другую, актуальную на тот момент, организацию. Уже получается, довольно точно, вести учет показаний с двух счетчиков. Пока идет работа над автономным режимом. Хочется максимально уменьшить аппетит микроконтроллера и заставить его работать длительный срок от аккумулятора 18650.

@Alex_DIY доброе время суток. Идея не покинула, но пока есть только набросок на бумаге и небольшой навесной монтаж. Все очень жидко, но первоначальная идея воспользоваться диодным умножителем и поднять напряжение с 5V до 400V. Хочется использовать микроконтроллер для генерации импульсов и накачки. Склоняюсь к Atmega328p или ATtiny85 т.к они есть у меня в наличие. Второй вариант предпочтительнее т.к более компактный. Думаю, что до конца этого года проект, по большей части, останется на бумаге т.к в данный момент идет проработка проекта контроля показаний счетчиков воды оборудованных импульсным выходом с последующей передачей показаний на центральный сервер.

@Alex_DIY Возможно стоит попробовать другую библиотеку, например, https://github.com/adafruit/Adafruit_Si7021 Может быть это глупое предложение, но все же интересно, ведь реализация математики в библиотеках различна. В LowPowerLab используется побитовый сдвиг, а в Adafruit деление. К сожалению, рабочего датчика SI7021 у меня нет, и посмотреть, что прилетает от него я не могу. LowPowerLab return ((125 * humraw) >> 16) - 6; Adafruit humidity *= 125; humidity /= 65536; humidity -= 6; return humidity; По поводу измерения напряжения питания микроконтроллера. Почитав англоязычные форумы и вооружившись мультиметром, позаимствованным у коллег на работе, провел эксперимент основанный на информации опубликованной ранее. Порт ADC микроконтроллера оставил переведенным в режиме VDD3P3. Связь с делителем не разрывал, но кинул перемычку с A0 (ADC) на EN (CH_PD или Chip Enabled), в принципе можно на вход питания микроконтроллера VDD 3.3V. Программа без корректирующего коэффициента. Подключение Стоит подумать над этим с делать окончательные выводы по поводу ADC.

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

@wildray последовательность Ваших действий для получения работоспособной метеостанции должна быть следующей: ... перенесено в первый пост темы

Они различаются т.к скомпилированы под разные датчики. Тот, что я скинул Вам, предназначен именно для BH1750 и BME280, а тот, что на первой странице для датчиков из описания, это BH1750, SI7021 и BMP180. Маловероятно т.к датчики работают со строго оговоренными командами. В контексте темы метеостанции, в большинстве случаев, это телеграмма в виде двух байт, первый из которых команда чтение/запись, а второй, это номер регистра, с которым мы работаем. То есть, мы или читаем данные или настраиваем датчик, и выйти за рамки логики установленной разработчиком мы не можем, сенсор попросту нас не поймет. Есть много вариантов программ для прошивки микроконтроллера, но по сути, они все делают одно и тоже. Использование среды Arduino подразумевает заливку программы через Arduino IDE. Прикрепленный к проекту .bin файл обычно нужен для прошивки через web, но в статье, по разным причинам, встречаются пробелы. Данное упущение я исправлю в ближайшее время. Используйте Arduino IDE для компиляции и загрузки программы, а также для загрузки содержимого каталога data на Flash. Использование Arduino IDE выгодно тем, что она проверяет обновления библиотек в автоматическом режиме и уведомляет Вас о доступности новой версии. @Alex_DIY @EndWar @wildray Друзья, что касаемо напряжения, позволю себе немного пофилософствовать. Думаю, что стоит копать в сторону порта ADC/TOUT. К нему подключен делитель напряжения (отдельный блок ADC на схеме) на двух резисторах - 100k и 220k. Изначально АЦП микроконтроллера настроен на чтение из TOUT (порт A0), а мы перенастраиваем его ADC_MODE(ADC_VCC); И получаем возможность пользоваться функцией ESP.getVcc() Теперь смотрим, что имеется в последнем техническом описании от разработчика на странице 5 и 17 ADC может работать в одном из двух режимов VDD3P3 и TOUT, но они не совместимы между собой. А также, если я правильно понимаю запись в разделе 4.9 для VDD3P3 - "TOUT must be floating", требует от нас отсоединить порт ADC от делителя напряжения используемого в плате NodeMCU и ей подобных, скорее всего оставить его в воздухе. НЕ СПЕШИТЕ: Также интересно, что если посадить порт ADC на VCC (ESP8266) и попробовать снимать данные напрямую. Но предварительно надо все обдумать дабы не нанести вред контроллеру. Можно использовать поправочные коэффициенты в программе, но это уникальное значение для каждого отдельного микроконтроллера.

Сразу даже и не задумался об этом, но получается, что равный. Именно первичный ключ и остался после исправления, unique был выкинут за ненадобностью. Безусловно SELECT будет выполняться быстрее всего. INSERT медленнее, но со временем таблица будут наполнена, а новые записи хоть и будут появляться, но довольно редко. А вот с UPDATE все сложнее, каким именно образом СУБД решит производить обновление сказать сложно, это очень тонкая грань и требует хороших знаний. Я предполагаю, что отметка об удалении и последующее добавлении записи происходить не будет, произойдет фактическое обновление т.к мы не затрагиваем индексируемые поля. А также поиск обновляемой записи будет происходить с использованием индекс. Но я не компетентен в таких тонкостях и строить дальнейших догадок не буду, но вопрос очень интересный и стимулирующий. Если отказаться от индексов, то при поиске записи (SELECT/UPDATE) будет происходит сверка со всеми записями в таблице. Мне кажется, что это плохая идея. Соглашусь с данным высказыванием. Пожалуй, стоит уделить больше энергии и времени самому демону.

@wildray Давайте разбираться. Я провел эксперимент со следующими датчиками. Сборка 3 в 1 в лице BH1750, HTU21D и BMP180 Датчик 3 в 1 BME280 Выглядит это следующим образом Из всего этого супового набора задействованы BH1750 + BME280. Чтобы задействовать именно эту сборку, необходимо только раскомментировать соответствующие им библиотеки, а все остальное закомментировать. Больше никаких изменений вносить не нужно. Вот, что имеем в итоге на web сервере микроконтроллера и, что показывает сканер I2C шины Прикрепляю скомпилированный файл (4mb Flash / 3mb SPIFFS) для Вашего тестирования: ESP8266_WS_iT4iT.CLUB.ino.nodemcu.zip Ищите функцию web_api_system_info, Вас интересует следующая строка answer += "\"vcc\":\"" + String(ESP.getVcc() * 0.001) + " V\","; PS: все внимательно проверяйте.

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

@Alex_DIY Все же это не дает мне покоя В данный момент у меня нет доступа к домашнему серверу, но доступна другая машина с Linux Ubuntu 16.04 на борту и оснащенная: Процессор Intel Core i3-3220 3300MHz/3Mb Оперативная память DDR3 4x2Gb 1600MHz Сам алгоритм безусловно один, иначе и быть не может, но то, как он реализован, это совсем другое. Допустим, мы имеем две функции перед которыми поставлена одинаковая задача, но реализация будет разная, при этом они будут возвращать идентичный результат. Пусть они будут написаны на Python, но это уже не имеет особого значения, если только они не будут оптимизированы третьей стороной перед исполнением. def test1(a): b = a c = b + 1 return c def test2(a): return a + 1 Логично, что для их исполнения нужно разное количество операций. Конечно, чтобы увидеть результат и разницу по времени, придется вызвать их N-ное количество раз. Я вызвал их в порядке их описания по 10 000 000 раз каждую и получил следующее время. 0:00:01.461331 0:00:01.145653 Тест повторил несколько раз и получил аналогичные результаты. Я понимаю, что возможно все это глупости, и я ловлю не тех "блох", но я отталкиваюсь от той мысли, что мой код далек от совершенства и дабы оптимизировать его, и тем самым ускорить исполнение, я пытаюсь переложить нагрузку на код написанный Программистами совсем другого уровня, чья цель максимально быстро выполнить необходимые вычисления и перейти к следующей операции. Ведь скорость вычисления в СУБД, это один из критических факторов. Поэтому прошу проникнуться моей идеей и рассмотреть следующий тест. Проведем по десять тестов с вычислением 1 000 000 MD5 хешей из одной фиксированной строки - "$SYS/broker/version". mysql> select benchmark(1000000, md5('$SYS/broker/version')); MySQL выполнил 10 тестов по 1 000 000 вычислений за следующее время 1 row in set (0,20 sec) 1 row in set (0,22 sec) 1 row in set (0,23 sec) 1 row in set (0,23 sec) 1 row in set (0,23 sec) 1 row in set (0,22 sec) 1 row in set (0,23 sec) 1 row in set (0,21 sec) 1 row in set (0,21 sec) 1 row in set (0,22 sec) Лишний мусор я вырезал оставив только результат по затраченному времени. Для Python я набросал следующий скрипт. Постарался упростить тест и до его начала произвел преобразование строки в UTF-8. #!/usr/bin/env python # coding=utf-8 import hashlib import datetime def speedTest(message): start = datetime.datetime.now() for i in range(0, 1000000): hashlib.md5(message).hexdigest() finish = datetime.datetime.now() print(finish - start) message = "$SYS/broker/version".encode('utf-8') for i in range(0, 10): speedTest(message) Те же 10 тестов по 1 000 000 вычислений дают следующий результат. root@asupmonitor:/media# ./speed.py 0:00:00.832224 0:00:00.833014 0:00:00.782348 0:00:00.788166 0:00:00.782401 0:00:00.785473 0:00:00.784118 0:00:00.782414 0:00:00.789315 0:00:00.788393 Получается, что MySQL производит вычисления MD5 хеша, примерно, в 3 раза быстрее. Теперь вернемся к самому демону. Я упоминал о вызове функции on_mseeage при поступлении сообщения от MQTT брокера. Насколько я понял, все сообщения обрабатываются библиотекой paho по очереди и никакой многопоточности нет. Чем дольше работаем с сообщением, тем позже перейдем к следующему, а последнее сообщение в очереди будет уныло скучать. Назвать все сообщение равноценными я не могу т.к, температура на улице не имеет такую важность как тревога о протечке воды в квартире или превышение уровня газа в помещении с нагревательным котлом. И с ростом переправляемого трафика увеличится время на его обработку. Я старался оставить в on_message только самое важное. Возможно я не прав, но позже я планирую уделить больше времени MQTT. Если у Вас есть идеи по оптимизации демона, обязательно пишите и мы вместе улучшим его работу. Еще раз спасибо, что уделили время.

Обновление от 28.11.2017 Доброе время суток друзья. Последнее время начал образовываться зоопарк из датчиков используемых в проекте. Это привело к появлению нескольких копий метеостанции поддерживать которые попросту утомительно и, как показала практика, описания по переходу на альтернативные сенсоры не пользуются популярностью и могут устаревать. Конечно хочется угодить всем, но для перехода на тот или иной датчик людям приходится вносить изменения, как минимум, в трех разных частях кода проекта. Соответственно появляются вопросы, которых можно было бы избежать. Теперь в проект добавлена поддержка как основных, так и альтернативных датчиков, но т.к вероятность замены сенсоров не высока, то нет смысла нагружать микроконтроллер одновременной поддержкой всего парка. И делать смену модели датчика в web интерфейсе. Для решения этой задачи были добавлены директивы условной компиляции. Это позволяет нам с Вами указывать используемые датчики только в одном месте кода, а именно, при подключении необходимых библиотек. Далее, при компиляции проекта, компилятор, опираясь на Ваш выбор, произведен необходимые изменения в коде. Но, чтобы это работало мы должны условиться использовать определенные библиотеки. Список поддерживаемых датчиков и соответствующих библиотек был обновлен и находится в первом посте темы. Рассмотрим как это работает на примере выбора датчика влажности. На момент публикации этого сообщения имеется поддержка датчиков HDC1080, SI7021 и HTU21D. Все необходимые библиотеки уже указаны в коде проекта. Если Вы хотите использовать SI7021, то просто раскомментируйте строки отвечающие за подключение соответствующей библиотеки и объявления переменной для датчика в начале кода программы. Учтите, что если Вы раскомментируйте несколько библиотек, использующих датчики на одном адресе I2C шины, то ни к чему хорошему это не приведет. Один адрес = один датчик = одна библиотека. Допустимо использование однотипных датчиков, но только с разными адресами и Вам придется самостоятельно добавить необходимую логику для второго датчика т.к это выходит за приделы общей логики проекта. Такие варианты по-прежнему будут рассматриваться отдельно. Теперь, когда компилятор дойдет до функции Setup и инициализации датчиков, отталкиваясь от нашей библиотеке, будет произведен выбор между нужными вариантами кода, а все остальное будет выкинуто из программы. Аналогичный выбор будет сделан при компиляции функции отвечающую за чтение данных с датчиков Для выбора между частями кода используются те или иные константы, объявленные авторами библиотек. Добавлена поддержка нового датчика BME280. Сам датчик предоставляет показания температуры, влажности и атмосферного давления. По умолчанию используется адрес на I2C шине 0x76. Также в код добавлена функция расчета абсолютной влажности, но она не задействована по умолчанию. Используйте её если это потребуется в Вашем проекте. Также были внесены мелкие доработки, не влияющие на общий функционал проекта.

@Alex_DIY Я внес исправления в пост и SQL файл. Так и должно быть т.к это имя индекса для выбранного поля. Вы можете дать ему другое имя или вообще не задавать его. https://dev.mysql.com/doc/refman/5.7/en/alter-table.html https://dev.mysql.com/doc/refman/5.7/en/mysql-indexes.html https://dev.mysql.com/doc/refman/5.7/en/create-index.html https://dev.mysql.com/doc/refman/5.7/en/partitioning-limitations-partitioning-keys-unique-keys.html Нет, это не так. Вас скорее всего запутало имя индекса, если бы оно выглядело иначе, например, "abc_UNIQUE", то все было бы яснее. В любом случае стоит пояснить, что происходит на самом деле. Нам необходимо производить быстрый поиск по таблице и сделать это без индекса невозможно. Самым логичным решением было бы использовать в качестве первичного ключа имя топика, но оно имеет тип text, а индексация по этому типу невозможна. Поле должно иметь тип с явно определенной длинной, но тогда мы рискуем обрезать имена топиков и потерять уникальность поля, что приведет к проблемам. Если я ошибаюсь, прошу меня поправить. Для решения этой проблемы было введено поле с MD5 хешем вычисленным из имени топика. Теперь у нас есть уникальное поле с типом VARCHAR и фиксированной длинной в 32 байта. Оно позволяет четко идентифицировать запись и соответствует конкретному топику. Это поле можно использовать для индексации записей. mysql> use `mqtt` Database changed mysql> EXPLAIN SELECT * FROM topics WHERE md5 = md5('$SYS/broker/version'); +----+-------------+--------+------------+-------+--------------------+---------+---------+-------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+--------+------------+-------+--------------------+---------+---------+-------+------+----------+-------+ | 1 | SIMPLE | topics | NULL | const | PRIMARY,md5_UNIQUE | PRIMARY | 98 | const | 1 | 100.00 | NULL | +----+-------------+--------+------------+-------+--------------------+---------+---------+-------+------+----------+-------+ 1 row in set, 1 warning (0,00 sec) А вот так бы происходил поиск записи без использования индекса mysql> EXPLAIN SELECT * FROM topics WHERE topic = '$SYS/broker/version'; +----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+ | 1 | SIMPLE | topics | NULL | ALL | NULL | NULL | NULL | NULL | 48 | 10.00 | Using where | +----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+ 1 row in set, 1 warning (0,00 sec) Никаких вычислений MD5 из MD5 не происходит. Я не буду утверждать, но мне кажется, что расчет MD5 хеша на уровне MySQL сервера будет выполнен с большей эффективностью чем на стороне Python. Особенно учитывая, что вычисленный хеш индексируется только один раз при добавлении записи. А значит можно провести простой тест. mysql> select benchmark(1000000, md5('$SYS/broker/version')); +------------------------------------------------+ | benchmark(1000000, md5('$SYS/broker/version')) | +------------------------------------------------+ | 0 | +------------------------------------------------+ 1 row in set (0,65 sec) Данные расчеты произведены на Foxconn NanoPC nT-i1250 c процессором Intel Dual Core Atom D2550 1.86GHz и памятью DDR3 объемом 2Gb. Расчеты для Python не производил т.к для этого необходимо написать программу, но если Вам будет интересно, то я сделаю это позже. Но думаю, что полученные результаты для MySQL должны быть вполне убедительны. Также вынос MD5 расчета был обусловлен разделением обязанностей. Мне показалось более красивым и правильным передавать на MySQL сервер имя топика, а сервер уже самостоятельно принимает решение что и как с ним делать. Также это разделение мне нравится из-за возможности вносить изменения в работу программы не останавливая демона. Это также позволяет расширять функционал, например, добавить необходимое Вам логирование конкретных топиков при этом сам демон не увидит никакой разницы при работе с базой. Ну и до кучи, это логика INSERT/UPDATE без штрафа на передачу данных между демоном и базой, но это уже не имеет никакого отношения к заданному Вами вопросу. Разница будет в реализации алгоритмов, и для одной и той же задачи процессору понадобится разное количество тактов на выполнение. Совсем глубоко я не копал, но это интересный вопрос и, как мне кажется, работа базы более оптимизирована. Также меня волновал момент с реализацией вызова функции on_message в библиотеки paho и я бы хотел перейти максимально быстро к разбору следующего в очереди сообщения. Также я прекрасно отдаю себе отчет, что мой код очень далек от идеала и я трачу много времени на лишние операции и имею большие паузы между ними и это довольно весомый фактор, по крайней мере для меня. Я буду рад любым предложениям по оптимизации. И еще раз спасибо за интересные и правильные вопросы.

Именно так. Чтобы реализовать выборку за определенный промежуток времени, необходимо переработать саму таблицу. Это попытка переложить часть работы на базу, в нагрузку к реализации логики выбора типа запроса. В Вашем случае придется ввести иной ключ и подумать об оптимизации выборки. Создает уникальный ключ с именем md5_UNIQUE для поля md5. Как Вы и заметили, присутствие данной записи избыточно из-за наличия PRIMARY KEY для этого поля. Относится он к первому варианту таблицы которая была переработана, а признак уникального поля был оставлен по ошибке. Это будет исправлено.

@EndWar формат json имеет строгий синтаксис. Отталкиваясь от этого, Ваша строка должна иметь следующий вид {"hostname":"192.169.0.103","dhtt1":61,"dhth1":30,"dsw1":-3}

@mag21 сообщение было перемешено

@Alex_DIY на данный момент - это тестовый вариант демона т.к это мой второй в жизни опыт написания программ на Python. Но я очень рад, что он может быть Вам полезен. Изначально логика работы подразумевает передачу данных только в одном направлении - от MQTT брокера в базу данный MySQL. Мы получаем полный дубликат данных всех топиков на которые подписаны. Я старался, чтобы данные передавались в реальном времени, но не тестировал демона при большой нагрузке, например, несколько сотен сообщений в секунду. Если Вам понадобится обратная связь, то это вполне можно реализовать, но Вы должны понимать, что передача в обратную сторону будет с задержкой т.к нет явного события, происходящего в момент обновления данных. То есть, при обновлении данных на MQTT брокере, мы получим оповещение, но при обновлении данных в базе MySQL такого события не будет (его можно создать искусственно, но процесс будет сложен для обывателя, не безопасен и не верен с точки зрения задач, возложенных на базу данных), придется периодически опрашивать базу, выявлять изменения и обновлять данные на брокере. PS: В любом случае, буду рад Вам помочь в изменениях программы, если они понадобятся. Но не представляю, как на маршрутизаторе будет работать MySQL. Я у себя дома завел маленький nettop на Intell Atom. Маленькое энергопотребление и небольшие ресурсы, но их более чем достаточно. Сам компьютер находится за приделами спальных комнат, а питание подается по Passive POE.

@Alex_DIY Я опирался на описание eCO2 То, что датчик более подходит для помещений, я полностью согласен, тем более, что об этом есть упоминание в технической спецификации. Но это только упоминание, а не предписание. Рабочие температурные ограничения меня радуют, но огорчают приделы влажности, но скорее всего, сенсор просто нельзя использовать в открытом виде. Возможно нужна какая-то система вокруг него, пока не знаю, это только мысли... В любом случае, попробовать хочется. Что касаемо измерения метеостанцией содержания CO2, то для меня это аналитический интерес т.к мой дом располагается вдоль дороги с интенсивным движением. Скорее всего будут явные пики на графике. Возможно, это также будет интересно держателям теплиц, или иных объектов, в которых могут использовать метеостанцию. В общем, на счет дополнительных датчиков есть очень много мыслей, порой и противоречив. И раз уж затронули, то одна из зудящих идей, это счетчик Гейгера на Attiny85, или другом мелком микроконтроллере, в паре с одной иди двумя трубками СБМ20. Самостоятельно работающее устройство с I2C интерфейсом и возможностью подключения к метеостанции на ESP8266 в качестве одного из внешних датчиков. Готов к куче летящий камней в мой адрес, но это личная "хатенка" и, со временем, она получит жизнь, возможно и без описания на форуме. @mag21 На сколько я понимаю, MH-Z19 выдает готовые данные по UART или аналоговый сигнал. Максимальная сложность может быть только при синтаксическом анализе (парсинге) данных и некоторые накладные расходы по времени при их передаче. Возможно, в данном случае, выгоднее использовать порт Vo и АЦП микроконтроллера, думаю, что это будет быстрее. Это беглый взгляд, нужно читать документацию по данному сенсору. На данный момент, я не готов приобрести такой датчик, но буду рад помочь советом, если он вообще понадобится, при интеграции MH-Z19 в проект.

@mag21 доброе время суток. В планах попробовать датчик CCS811. Питание от 1.8 до 3.6V Средний потребляемый ток 30 mA Пиковый потребляемый ток 54 mA Рабочая температура от -40 до 85 °С Относительная влажность (без конденсации) от 10 до 95% Приделы измерения CO2 от 400 до 8194 ppm Приделы измерения TVOC от 0 до 1187 ppb Он не из дешевых, но как по мне, лучше чем датчики из серии MQ.

@EndWar @Alex_DIY друзья, прошу Вас не спорить. Мы все люди, где-то ошибаемся, а где-то, думая, что совершили ошибку, на самом деле, сделали верный выбор. В любом случае, отталкиваясь от тематики этого раздела, мы пытаемся получить тот результат, который в итоге устроил бы лично нас. И очень хорошо, что мы готовы делиться нашими наработками и самое главное - опытом. И даже не важно, положительный он или нет, ведь то, что было провалом для одного, станет отправной точной для другого. Я очень благодарен Вам, за вклад в развитие проекта и за столь продолжительный интерес к нему. И я уверен, что с увеличением популярности домашней автоматизации, стандартом будут становится именно открытые платформы, разработанные сообществом людей.