Зачем мне делать проект на Raspberry Pi к примеру, если проект делается конкретно под ESP32-S3/P4? Это примерно как если бы Вы пришли в авто салон за камри, а Вам советуют сходить в соседний за БМВ... И пользователю по барабану где и на чем проще/не проще, он смотрит на совокупную стоимость и голосует рублем...
Мы говорим вроде о текущих реалиях, а не о том, что где-то когда-то что-то было. И какие же ограничения накладывает ESP-IDF, что нужно использовать PlatformIO? Даже ESPHome в новых версиях с него слез.
Ну тогда, давайте по конкретике, и заодно как раз будет ответ и про стоимость разработки и про python и про С. Вот мой проект. Он в стадии тестирования. Времени на него было потрачено 8 месяцев, в рабочие часы если перевести, то год. Тут более 200.000 строк кода и это не финалка. Тут и С/С++, и скрипты-сборщики на Python и webserver на typescript/vue/html/css. Так вот, такое написать на micropython нереально, просто нет нужных библиотек, но даже если сильно постараться и самому что-то дописать/закостылить, это просто тупо не запустится))). Увы. То есть, аргумент, что надо писать на микропайтон, даже если нам сильно хочется, к сожалению не состоятелен. По поводу стоимости разработки... Сколько стоит разработка такого проекта? Ну миллиона 2 деревянных... Понравится, не понравится это уже другой вопрос, но факт есть факт. Окупится он? Нет, конечно. Но если бы я выпускал сам устройства с дисплеями, как Вы и сказали от 100 тысяч, то это бы вышло по 20р на устройство, что не о чем, да даже партия в 10 тысяч того бы стоила. Но разработка могла бы стоить и в 2 раза меньше, в виду того, что концепции и архитектура несколько раз менялись, и времени бы могло уйти меньше. Но мой проект уже ближе к полноценному коммерческому продукту, а в коммерции никто на микропайтоне писать не будет. Факт. Но я с вами полностью согласен, время - деньги, именно поэтому сейчас на той же винде пишут на Express.js вместо условного C#. Тормозит? Да! Ресурсы жрет? Да! Бесит? Да! Зато быстро за месяц слепил и в прод, вместо того чтобы полгода возиться с C#. Тут Ваша правда, только вот МК это про ресурсы, и там такие фокусы не пройдут, если Вам не нужно просто моргнуть светодиодом. Опять же таки, надо быстро - есть ESPHome, будет в разы быстрее микропайтона как по времени написания кода, так и по скорости работы. То есть, это я к чему? Мой основной язык как раз Python, вещь удобная, но MicroPython это прям не туда не сюда как по мне... Идея неплохая, но, как уже и сказал ранее, для погружения школьников в робототехнику и программирование - отлично, а так, я не вижу преимуществ по сравнению с тем же ESPHome никаких...
Ну раз Вы решили оценить мои профессиональные навыки и дать мне совет, то тогда вот Вам ответ: Вы рассуждаете как типичный веб-разработчик или программист систем верхнего уровня, который дорвался до железа и пытается натянуть паттерны из ООП и веб-разработки (динамические поля, обертки, строки) на микроконтроллеры. Как только Вы захотите запустить какой-нибудь специфический датчик типа HL-2140, редкий модуль связи или дисплей, то Вам придется самому писать библиотеку, выдрачивая даташит, работая с регистрами или протоколом... и о Боги, придется писать на С (в виде С-модуля для MicroPython) от чего Вы так бежали. Далее, зачем на микроконтроллере динамически плодить методы и объекты? Железо МК - статично, динамический хаос в памяти МК - это гарантированный способ поймать фрагментацию RAM и намертво зависнуть через 12 часов работы. Если устали от С, то есть Rust! А для большинства несложных задач типа моргнуть светодиодом, да даже настроить панель умного дома - есть ESPHome, вообще кодить не надо, даже обезьяна справится. Micropython, как и его аналог CircuitPython от Adafruit забавный инструмент для обучения школьников или для челиков, которым лень изучать низкоуровневый стек, но нужно быстро дернуть пин на ESP32. И говорю я это как человек, не с 20-ти летним стажем в IT, а как человек написавший крупный проект на микроконтроллере ESP32-S3/P4 на языке С, да и на ESPHome тоже. А также написавший драйвера для дисплеев, и о Боги, библиотеку для HL-2140 для micropython. Мораль сей басни такова - под конкретную задачу - свой язык, библиотеки и так далее. Но я почти уверен, что Вы как программист с 20-ти летнем стажем понимает, что micropython медленнее С раз в 10-100 по скорости, а для МК это критично в большинстве задач, особенно связанных с прерыванием и так далее, а если устали в работе с памятью, то посмотрите на Rust, будете приятно удивлены.
Зачем писать на micropython на микроконтроллерах? Наверно напрашивается только один ответ, потому что он более понятный, но если не писать самому, то тут только одни минусы: мало библиотек, скорость работы и так далее...
Кроме того этот проект опенсорс и ничто не мешает Вам его изменить под свои желания и требования.
Это называется не изменить, а сделать схему и трассировку платы заново. Но спасибо, у меня свои есть.
странный вопрос, ответ тоже странный будет - потому что именно так захотелось
Да, ответ действительно странный
потому что они там проложены для адресных ледов по периметру
А как это относится к сути вопроса?
может и имеет, но мы пока не пришли к такому выводу
Я и спросил, какая температура у AMS1117 в работе. С учетом того, что для датчиков критически важно максимально снизить влияние температуры и шума, то лучше поставить DC/DC. А линейный можно оставить. Но уже после DC/DC. Возможно даже сделать две ветки 3.3V (для BME280 и датчика освещенности отдельную) и между ними феррит. Да, и отсутствует TVS / ESD на USB.
данный проект позиционируется как DIY устройство для самостоятельной сборки с применением стандартных продаваемых модулей на Али. SCD4x расположен так что бы окно решетки на задней крышке корпуса приходилось непосредственно напротив. Температуру и влажность от SCD40 не использует прошивка только от BME280. Гайд замечательный но не актуален применительно к данному проекту , опять таки по причине не использования внутренней температуры и влажности, а так же использование модуля в сборе с Али а не сам сенсор отдельно, что исключает физический контакт основной платы и сенсора.
Поэтому я и сказал, что показания будут не референсными, так как у Вас тут много где есть компромисы. Нет EMI-фильтров.
Зачем некоторые дорожки проходят близко к монтажным отверстиям?
Какая температура у линейного преобразователя при работе? Может есть смысл заменить на DC/DC?
Странное расположение конденсаторов, например С6.
Странное расположение датчиков. Предполагаю, что они показывают среднюю температуру по больнице. У компании Sensirion есть, к примеру для SCD4x гайд, как должен располагаться датчик.
Статья была написана в стиле markdown, к сожалению, редактор на HABRe в markdown работает как-то кривовато и у меня не получилось разместить не ссылки на проект, не картинки. Вот финальный результат:
Финальный результат
P.S. Через редактор WYSIWYG все прекрасно работает, в MARKDOWN нет
Было бы неплохо, если бы наши лучшие инженеры воплотили бы это в жизнь, даже за дорогой ценник и довели бы до ума, но я лишь любитель в этой сфере… Хотя попытки были…
@wildegor вот проект который я делал год назад, с тех пор я улучшил схему и разводку платы (но никуда не выкладывал), и показания с датчиков стали намного лучше, SCD40 врет ровно на 4 градуса (при чем у многих так, кто с ним работал), но это решается поправочным коэффициентом, от остальных датчиков я все равно не добился нужного результата, хоть и приблизился. Вы можете посмотреть какие данные показывают датчики, особенно показания по eCO2 с BME680. Но я в принципе не об этом... Как туториал и DIY ваша статья хорошая (правда С++ менее подходит для обычных пользователей, чем тот же CircuitPython или тем более ESPHome), а вот как подарок для друзей - не очень)). Люди от умного дома, датчиков, УДЯ и так далее хотят четкой работы и меньше сложностей, а с учетом как работают все эти датчики качества воздуха, Вы их полгода каждую неделю покалибруете и Вам это в итоге надоест. То что у Вас плохой воздух Вы и так поймете, а строить на этих показаниях автоматизацию работы вентиляции это будет очень плохим решением. Если есть вентиляция - просто ставить на постоянку, а если нет, то все эти датчики CO2 просто понты для гостей...
Вы удивитесь, но мой bme680 не был откалиброван, а ставился на плату через NextPCB, а вот SCD4x на алике многие продают либо отбраковку либо паль, потому что ценник дешевле чем у NextPCB, JLCPCB…
показания eCO2 соотносятся с показаниями СО2 ровно никак. Поэтому было бы правильнее в статье везде исправить СO2 на еСО2. А лучше вообще не упоминать, этот датчик показывает, как уже было сказано выше TVOC.
Не поймите меня неправильно, я только за, когда люди мастерят, что-то своими руками.
Но такие платы с датчиками должны делать инженеры, по той простой причине, что реальные цифры (и то не факт) можно получить только по совокупности факторов, а именно: правильно спроектированная плата с отводом тепла, правильно спроектированный корпус (посмотрите ссылку которую я Вам дал, это не просто разнести датчики по корпусу), правильная и ПОСТОЯННАЯ калибровка.
А вообще, имхо, все эти датчики баловство для любителей, которые изучают как программировать микроконтроллеры, получать данные с шины I2C и так далее.
Не считая того, что эту гирлянду надо постоянно калибровать, очень важное значение имеет именно корпус. У производителей датчиков даже есть документация вплоть до миллиметров как они должны располагаться в корпусе.
Я пытался что-то подобное сделать, но на отдельной плате, а не по спайке проводов. И показания очень далеки от правды как и в этом проекте. А без реальных показаний все эти проекты бесполезны, кроме как хобби.
Зачем мне делать проект на Raspberry Pi к примеру, если проект делается конкретно под ESP32-S3/P4? Это примерно как если бы Вы пришли в авто салон за камри, а Вам советуют сходить в соседний за БМВ... И пользователю по барабану где и на чем проще/не проще, он смотрит на совокупную стоимость и голосует рублем...
Мы говорим вроде о текущих реалиях, а не о том, что где-то когда-то что-то было. И какие же ограничения накладывает ESP-IDF, что нужно использовать PlatformIO? Даже ESPHome в новых версиях с него слез.
Ну тогда, давайте по конкретике, и заодно как раз будет ответ и про стоимость разработки и про python и про С. Вот мой проект. Он в стадии тестирования. Времени на него было потрачено 8 месяцев, в рабочие часы если перевести, то год. Тут более 200.000 строк кода и это не финалка. Тут и С/С++, и скрипты-сборщики на Python и webserver на typescript/vue/html/css. Так вот, такое написать на micropython нереально, просто нет нужных библиотек, но даже если сильно постараться и самому что-то дописать/закостылить, это просто тупо не запустится))). Увы. То есть, аргумент, что надо писать на микропайтон, даже если нам сильно хочется, к сожалению не состоятелен. По поводу стоимости разработки... Сколько стоит разработка такого проекта? Ну миллиона 2 деревянных... Понравится, не понравится это уже другой вопрос, но факт есть факт. Окупится он? Нет, конечно. Но если бы я выпускал сам устройства с дисплеями, как Вы и сказали от 100 тысяч, то это бы вышло по 20р на устройство, что не о чем, да даже партия в 10 тысяч того бы стоила. Но разработка могла бы стоить и в 2 раза меньше, в виду того, что концепции и архитектура несколько раз менялись, и времени бы могло уйти меньше. Но мой проект уже ближе к полноценному коммерческому продукту, а в коммерции никто на микропайтоне писать не будет. Факт. Но я с вами полностью согласен, время - деньги, именно поэтому сейчас на той же винде пишут на Express.js вместо условного C#. Тормозит? Да! Ресурсы жрет? Да! Бесит? Да! Зато быстро за месяц слепил и в прод, вместо того чтобы полгода возиться с C#. Тут Ваша правда, только вот МК это про ресурсы, и там такие фокусы не пройдут, если Вам не нужно просто моргнуть светодиодом. Опять же таки, надо быстро - есть ESPHome, будет в разы быстрее микропайтона как по времени написания кода, так и по скорости работы. То есть, это я к чему? Мой основной язык как раз Python, вещь удобная, но MicroPython это прям не туда не сюда как по мне... Идея неплохая, но, как уже и сказал ранее, для погружения школьников в робототехнику и программирование - отлично, а так, я не вижу преимуществ по сравнению с тем же ESPHome никаких...
Ну раз Вы решили оценить мои профессиональные навыки и дать мне совет, то тогда вот Вам ответ:
Вы рассуждаете как типичный веб-разработчик или программист систем верхнего уровня, который дорвался до железа и пытается натянуть паттерны из ООП и веб-разработки (динамические поля, обертки, строки) на микроконтроллеры.
Как только Вы захотите запустить какой-нибудь специфический датчик типа HL-2140, редкий модуль связи или дисплей, то Вам придется самому писать библиотеку, выдрачивая даташит, работая с регистрами или протоколом... и о Боги, придется писать на С (в виде С-модуля для MicroPython) от чего Вы так бежали. Далее, зачем на микроконтроллере динамически плодить методы и объекты? Железо МК - статично, динамический хаос в памяти МК - это гарантированный способ поймать фрагментацию RAM и намертво зависнуть через 12 часов работы. Если устали от С, то есть Rust! А для большинства несложных задач типа моргнуть светодиодом, да даже настроить панель умного дома - есть ESPHome, вообще кодить не надо, даже обезьяна справится. Micropython, как и его аналог CircuitPython от Adafruit забавный инструмент для обучения школьников или для челиков, которым лень изучать низкоуровневый стек, но нужно быстро дернуть пин на ESP32. И говорю я это как человек, не с 20-ти летним стажем в IT, а как человек написавший крупный проект на микроконтроллере ESP32-S3/P4 на языке С, да и на ESPHome тоже. А также написавший драйвера для дисплеев, и о Боги, библиотеку для HL-2140 для micropython. Мораль сей басни такова - под конкретную задачу - свой язык, библиотеки и так далее. Но я почти уверен, что Вы как программист с 20-ти летнем стажем понимает, что micropython медленнее С раз в 10-100 по скорости, а для МК это критично в большинстве задач, особенно связанных с прерыванием и так далее, а если устали в работе с памятью, то посмотрите на Rust, будете приятно удивлены.
да такой задачи s3 не нужен, подойдет и ESP32 и ESP32-C6/H2
Зачем писать на micropython на микроконтроллерах? Наверно напрашивается только один ответ, потому что он более понятный, но если не писать самому, то тут только одни минусы: мало библиотек, скорость работы и так далее...
А какая проблема использовать VSCode с ESP-IDF? Зачем нужна PlatformIO?
Не совсем понял комментарий). Вернее, совсем не понял.)
Это называется не изменить, а сделать схему и трассировку платы заново. Но спасибо, у меня свои есть.
Да, ответ действительно странный
А как это относится к сути вопроса?
Я и спросил, какая температура у AMS1117 в работе. С учетом того, что для датчиков критически важно максимально снизить влияние температуры и шума, то лучше поставить DC/DC. А линейный можно оставить. Но уже после DC/DC. Возможно даже сделать две ветки 3.3V (для BME280 и датчика освещенности отдельную) и между ними феррит. Да, и отсутствует TVS / ESD на USB.
Поэтому я и сказал, что показания будут не референсными, так как у Вас тут много где есть компромисы. Нет EMI-фильтров.
Очень странная разводка платы:
Почему дорожки не под 45°?
Зачем некоторые дорожки проходят близко к монтажным отверстиям?
Какая температура у линейного преобразователя при работе? Может есть смысл заменить на DC/DC?
Странное расположение конденсаторов, например С6.
Странное расположение датчиков. Предполагаю, что они показывают среднюю температуру по больнице. У компании Sensirion есть, к примеру для SCD4x гайд, как должен располагаться датчик.
Ответил постом выше
Статья была написана в стиле markdown, к сожалению, редактор на HABRe в markdown работает как-то кривовато и у меня не получилось разместить не ссылки на проект, не картинки. Вот финальный результат:
P.S. Через редактор
WYSIWYGвсе прекрасно работает, вMARKDOWNнетБыло бы неплохо, если бы наши лучшие инженеры воплотили бы это в жизнь, даже за дорогой ценник и довели бы до ума, но я лишь любитель в этой сфере… Хотя попытки были…
@wildegor вот проект который я делал год назад, с тех пор я улучшил схему и разводку платы (но никуда не выкладывал), и показания с датчиков стали намного лучше, SCD40 врет ровно на 4 градуса (при чем у многих так, кто с ним работал), но это решается поправочным коэффициентом, от остальных датчиков я все равно не добился нужного результата, хоть и приблизился. Вы можете посмотреть какие данные показывают датчики, особенно показания по eCO2 с BME680. Но я в принципе не об этом... Как туториал и DIY ваша статья хорошая (правда С++ менее подходит для обычных пользователей, чем тот же CircuitPython или тем более ESPHome), а вот как подарок для друзей - не очень)). Люди от умного дома, датчиков, УДЯ и так далее хотят четкой работы и меньше сложностей, а с учетом как работают все эти датчики качества воздуха, Вы их полгода каждую неделю покалибруете и Вам это в итоге надоест. То что у Вас плохой воздух Вы и так поймете, а строить на этих показаниях автоматизацию работы вентиляции это будет очень плохим решением. Если есть вентиляция - просто ставить на постоянку, а если нет, то все эти датчики CO2 просто понты для гостей...
Это может быть понятно сведующим, а многие люди примут за чистую монету…
Вы удивитесь, но мой bme680 не был откалиброван, а ставился на плату через NextPCB, а вот SCD4x на алике многие продают либо отбраковку либо паль, потому что ценник дешевле чем у NextPCB, JLCPCB…
показания eCO2 соотносятся с показаниями СО2 ровно никак. Поэтому было бы правильнее в статье везде исправить СO2 на еСО2. А лучше вообще не упоминать, этот датчик показывает, как уже было сказано выше TVOC.
Не поймите меня неправильно, я только за, когда люди мастерят, что-то своими руками.
Но такие платы с датчиками должны делать инженеры, по той простой причине, что реальные цифры (и то не факт) можно получить только по совокупности факторов, а именно: правильно спроектированная плата с отводом тепла, правильно спроектированный корпус (посмотрите ссылку которую я Вам дал, это не просто разнести датчики по корпусу), правильная и ПОСТОЯННАЯ калибровка.
А вообще, имхо, все эти датчики баловство для любителей, которые изучают как программировать микроконтроллеры, получать данные с шины I2C и так далее.
Статью плюсанул.
В этом проекте нет датчика CO2
Не считая того, что эту гирлянду надо постоянно калибровать, очень важное значение имеет именно корпус. У производителей датчиков даже есть документация вплоть до миллиметров как они должны располагаться в корпусе.
Я пытался что-то подобное сделать, но на отдельной плате, а не по спайке проводов. И показания очень далеки от правды как и в этом проекте. А без реальных показаний все эти проекты бесполезны, кроме как хобби.
Update: вот, к примеру, как должен находиться реальный датчик CO2 SCD4x от Sensirion в корпусе: https://sensirion.com/media/documents/0D0C9129/623B1183/Sensirion_CO2_Sensors_SCD4x_design-in_guide.pdf
Если Вам только термостат и 220V, то посмотрите такой вариант, и прошивка к нему есть готовая
Полностью согласен