Arduino Mega. Контроллер теплицы. Хроники - 4.0

РЕКЛАМА НА ФОРУМХАУС

Ежи у нас грамотные, а вот люди попадаются дремучие

 

Нашёл, есть метод RSSI, пошёл допиливать прошивку для ESP - пока откатаю на NodeMCU, потом - перешью модуль уже. Дальше - будем думать, как отобразить всё.

 

Этот метод я применял в XBee. Есть там такой сигнал, но он типа импульсов ШИМ. Нужно было ставить резистор с конденсатором, и только потом отправлять на аналоговый порт.
Может в ESP по другому.

 

Пока гуру разбираются с прошивкой, созрел на корпус модуля датчиков, если кому надо могу дать PCB и STL

 

Обновил на гитхабе: поменялась также прошивка для ESP - там добавлена поддержка команды AT+CSQ (которой, к слову - нет в штатной прошивке от Espressif). Смысл этой команды только в том, что она возвращает уровень сигнала, когда подконнекчены к роутеру.

Дабы не мудрствовать, сделал просто: тупо каждые 20 секунд с ESP запрашивается уровень сигнала, и переводится из dBm во внутреннее представление, 0-4, где 0 - нет сигнала, 4 - 4 палочки.

Опять же, чтобы долго не морщить лоб, на TFT-экране сделал такие же иконки, как и для SIM800, только вместо GPRS - написано WIFI: иконка незакрашена - нет соединения с роутером, закрашена - есть соединение с роутером. Справа от иконки - уровень сигнала Wi-Fi. Иконки разнесены от иконок GSM довольно существенным пробелом, чтобы визуально не сливалось.

С точки зрения юзабилити - всё читаемо, слева-направо: есть иконка с надписью WIFI, справа от неё - уровень сигнала Wi-Fi, всё логично и понятно. То же самое касается GSM, собственно.

Так что считаю, что не стоит гоняться за цветами и разукрашивать всё это добро, как попугая - задача хорошего дизайнера (это не ко мне, я просто рядом проходил) сделать так, чтобы было понятно на уровне простейших пиктограмм, а если где нужны дополнительные цвета - это, пмсм, уже косяк юзабилити. Короче, я старался.

@promavto - Саш, пробуй. ESP, естественно - надо перепрошить новой прошивкой, что в папке ESP_AT

 

Я - только за, если ты не против - могу вообще выложить на гитхаб PCB, пущай разбираются Хотя - тут дело такое, хозяйское, что называется

 

Да не вопрос, выкладывай

 

Ок, в следующей обнове выложу

Правка: выложил Теперь мона туда перенаправлять желающих самостоятельно сделать такую плату - всё валяется в подпапке PCB внутри папки UniversalSensorsModule.

З. Ы. Столько добра уже поднакопили - аж жуть

 

Давно хотел сказать "Спасибо" тому кто разработал первую схему контроллера. Так сказать основоположнику этой разработки.

 

Вопрос: датчики CO2 прикручивать будем? Если да - то какие? Есть в наличии китайские MQ-какие-то, но они, ессно, реагируют на CO (на заборе "хрен" написано, а за ним - дрова, собственно), да и измеряют - в попугаях.

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

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

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

Короче, вопрос: датчики CO2 прикручивать будем? Второй вопрос "как?" - буду уже решать: уж больно большой зоопарк, куда всё это дело передаётся, как обрабатывается и т. д. и т. п.

Правка: сейчас глянул - я использую один байт как тип датчика, но - для быстрой проверки, есть ли в модуле такой тип датчика - использую битовую маску, отсюда все ограничения. Если отказаться от битовой маски, то ограничений на типы датчиков - до 255 В любом случае - введение нового типа датчика потребует вдумчивого пересмотра всего.

Правка 2: это жесть Куча мест, просто куча - у нас и универсальные модули и чёрта лысого. И EEPROM цепляется, и конфигуратор - да всё цепляется с введением нового типа показаний. Даже не знаю, стоит ли вообще заморачиваться с введением новых типов датчиков - это секас.

По беглому взгляду - я в ужасе, сколько всего наколбашено. И, как обычно - приплыли в тонкое место, mea culpa, что заранее не предусмотрел, что типов показаний может быть овердохрена. Надо думать, сильно думать.

 

По хорошему, неплохо было бы. Но в типах датчиков есть различие. Есть серия MQ 2 - MQ 9, MQ135.
Они обнаруживают дым, бытовые газы, алкоголь (проверял на ватке со спиртом, не дышал). Для вывода датчика в рабочий режим, его нужно разогреть кажется до 100 градусов (ток 150 ма 5 вольт).
Как защита от пожара и утечки газа он подойдет, но нужно располагать его как можно ближе к контролируемой территории. Выходной сигнал аналоговый, но есть настраиваемый компаратор (0/1).
Производитель гарантирует долговечность работы датчика, но что то мне подсказывает что при постоянном нагреве не такой уж долговечный он. Вариант когда периодически включать/отключать нагрев - может следующий раз и не включиться, так как будет в полете вместе со стенами.
Следующее, ставить контроллер теплицы возле газовой плиты немного расточительно, а тянуть провода от датчика в теплицу точно не будут. Я рассматривал вариант радиодатчика с автономным питанием (все таки 150 ма). Но клиент обанкротился, за то я имею десяток датчиков в наличии.

Теперь о датчике CO2. Его ставят при выращивании грибов в замкнутом пространстве и других специфических растений. Как правило я отказываюсь от таких заявок или клиент отваливается, когда
узнает стоимость датчика.
Есть еще такая информация, что при плохом освещении растения выделяют не кислород, а CO2.
Но в интернете разной информации много, пишут что из головы лезет. Всему верить не стоит.
А вот цена такого датчика дешевле 900 руб. не видел. В основном от 1500 руб и более (серия MQ копеечная). Короче говоря, применение таких датчиков на специфического клиента. В широкое распространение он не пойдет. Возможно такой клиент уже есть, Следующая неделя покажет.

 

Саш, тут проблема не в том, что нельзя прикрутить, а в том, что очень много специфики уже, которую надо учитывать. Вот я бегло глянул код - и охерел, честно скажу: у нас в настройках для того же информационного SMS можно указывать модуль и тип датчика, чтобы в SMS это пришло. Следовательно, простое, на первый взгляд, введение нового типа датчика - это и допилинг конфигуратора, и вебморды, и кучи модулей. Я посмотрел - навскидку около десятка исходных файлов, не меньше.

Плюс - надо, нет, НАДО сохранять обратную совместимость с тем, что уже работает. Скажем, я просто так теперь не могу взять - и сменить формат команды, например CTGET=0|STAT: как она выдавала в первом ОДНОМ байте битовую маску - какие датчики есть в модуле: так она и должна продолжать это выдавать, чтобы не сломать уже работающее. Следовательно - натыкаемся на то, что в одном байте - 8 бит, из них юзаются уже 6, свободный - только один бит, под новый тип датчика.

Плюс, не забывай - отображение на экранах, сохранение в БД, на gardenboss. ru, ThingSpeak - всё это в куче мест, тут с наскоку не заскочишь в поезд, что называется.

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

Я сейчас думаю, как отказаться от битовой маски, сохранив обратную совместимость. В этом случае (многие модули хранят в себе тип датчика - как один байт) - мы получим во многих местах работу с показаниями новых типов датчиков "из коробки", а там, где это будет нужно (например, будет запрос "Хочу вот этот тип датчика через конфигуратор настроить так, чтобы его показания отправлялись на MQTT") - можно будет дописывать куски кода: собственно, сейчас в некоторых местах работу с тем же датчиком pH просто не увидишь - нет востребованности, и некоторые модули просто не обучены что-то там показывать/выводить.

В общем - надо делать ревизию кода, обрисовывать тонкие места. Согласен в том плане, что это имеет смысл делать только по наличию востребованности: есть запрос - будем думать, нет запроса - нунафик, что называется.

Но, подчеркну ещё раз: пока, без отказа от битовой маски - есть один свободный слот, туда можно прописать тип показаний CO2, и размерность в ppm (емнип, там именно такие единицы измерения). Для показаний - места хватит, отведено 4 байта под показания одного вида, за глаза.

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

Скажу больше: хрен с ней, с битовой маской даже, дело не в этом. Интерфейс - вот в чём дело: когда человек хочет видеть показания нового типа датчика - естественно, это надо дописать во всех местах, включая конфигуратор и т. п.

Тут, к слову, вспоминается заброшенное до поры до времени ArduinoCore: там с развёртыванием сети устройств и типом датчиков - нет проблем вообще, ибо проектировалось всё это дело - с учётом накопленного опыта. Вот под ним развернуть проект новый - было бы ништяк, хотя там тестирования ещё надо делать - мама не горюй. Но костяк работы с датчиками - уже есть, заготовки под логику проекта - предоставлены, припиливай, что хочешь. Настройки датчиков меняются без перезакачивания прошивки - ляпота. Только логику пиши нужную, и всё. Может, стоит подумать в этом направлении, чем издеваться над контроллером ТЕПЛИЦЫ?

 

"Вот иманно, вот иманно"!
На поникс. ру был перец с раздутым самомнением, который и сотой части возможностей, уже реализованных ТОБОЙ (снимаю панаму) не осилил.
Мега вот-вот и лопнет ужо (Имхо).
А вот в новый проект стоит ввести датчики MQ. Причем новый проект будет вообще шедевром, т. к. на этом откатано много чего было.
Сохрани силы на новый проект. Имхо.

 

Согласен, и под новый проект разработать контроллер на STM32. Контроллер должен иметь универсальную, настраиваемую архитектуру. В этом плане проект Ардуино является классическим примером. Есть много разных микроконтроллеров, есть разные среды программирования от гигантов микроэлектроники, но такого распространения они не получили. И дело не только в заоблачной стоимости этих IDE. Контора, производитель STM32 пытается продвигать свои STM32Cube, CoIDE и. т. д. Они даже бесплатные, но все равно даже близко не приблизились к популярности Ардуино.
Простота программирования привлекла много начинающих. Здесь конечно есть и минус, нет глубокого изучения языка С+. У нас профессиональные программисты с высокомерием смотрели на Ардуино, а сейчас смотрю втихаря уже трое приобрели модули Ардуино и приходят за консультацией на эту тему.

Немного отвлекся от основной темы. Считаю, что с контроллером теплицы все функции выполнены.
Возможно нужно добавить опцию программирования автоматического запуска сценариев с SD. Может это и организовано, последняя информация у меня была - ручной запуск сценариев. Считаю что это намного увеличит функциональность контроллера.

А с датчиками СО2 можно пока повременить.

Лучше направить на силы на разработку новой концепции более универсального модуля.
Разбить тему на насколько направлений типа - периферия, индикация, связь с внешним миром, разветвленная сеть датчиков и. т. д

 

Уже всё есть, Саш: из правил можно сценарии запускать - чем тебе не автоматический запуск сценариев?