
В прошлой статье мы дали голос нашему ESP32 — научили его отправлять уведомления в Telegram и ntfy. Теперь, когда устройство умеет "говорить", пришло время научить его "думать" и работать самостоятельно, без постоянного контроля.
Если тогда мы тестировали отправку сообщений, то сейчас займемся созданием полноценной системы. Возьмем тот же инструмент MicroPython, но посмотрим на него с другой стороны: не как на средство для быстрых экспериментов, а как на платформу для реализации ваших идей.
В реальном проекте недостаточно просто уметь отправлять уведомления — нужно понимать:
Когда их отправлять (чтобы не спамить).
Что делать между уведомлениями.
Как не зависнуть через неделю работы.
Куда девать ограниченную память ESP32.
Разработка программы для микроконтроллера — это техническая реализация вашей идеи. Сама идея — это продуманная вами логика работы системы. Код — это просто инструкция для железа, как исполнять эту логику.
Пример:
«Следи за водой в колодце и сообщай, если что-то изменится» — это логика.
«Раз в 3 минуты проверяй датчик, сравнивай с предыдущим состоянием, и если оно изменилось — отправляй сообщение в Telegram» — это уже техническая реализация логики, которую необходимо перевести в код.
В микроконтроллерах, особенно с MicroPython, важно продумать не только что делать, но и как делать с учетом ограниченной памя��и и других ресурсов.
Я не собираюсь в этой статье «открывать Америку», а хочу показать на примере своего кода, который уже несколько месяцев работает в системе мониторинга, как можно создавать стабильные проекты.
При работе с ESP, я выработал для себя несколько правил:
Сначала полностью продумать логику на человеческом языке. Прежде чем писать код, опишите алгоритм словами.
Учитывать ограничения памяти — регулярно её чистить, до и после выполнения операции, MicroPython может «захлебнуться» в постоянном цикле.
Добавлять защиту от зависаний — сторожевой таймер, если система "задумалась" — автоматически перезагружаем.
Быть экономным с уведомлениями — сообщать только о важном, не спамить, а информировать о изменениях состояния.
Импортировать только необходимые и используемые инструменты из встроенных модулей, не тащить в память лишнее.
Предусматривать автоматическую принудительную перезагрузку (1 раз в неделю) для профилактики накопления ошибок.
Тестировать код (отдельные фрагменты)
Это не идеальное решение, но вполне рабочее. Надеюсь, мой опыт поможет вам в создании своих проектов. Помните: во всем этом процессе важнее всего Вы, ваша идея и ваша логика. Код, безусловно, важен, но он вторичен. Вы — творец, который превращает идеи в работающие устройства.
От логики к алгоритму: проектируем систему мониторинга воды в колодце
Давайте продумаем логику работы датчика воды. Напомню, наша цель — создать систему, которая сообщает только об изменениях уровня воды и работает стабильно месяцами.
Этапы работы системы:
1. Инициализация (выполняется один раз при запуске или перезагрузке)
Подключение к Wi-Fi.
Запуск WebREPL для удаленного доступа (на ваш выбор, можно и не использовать)
Отправка уведомления в Телеграмм бот о запуске.
2. Основной цикл (интервал можно настроить под ваши задачи - для стабильных систем выбирайте интервал от 20 сек до 3 минут)
Очистка памяти . Освобождаем RAM для предстоящей работы.
Сброс сторожевого таймера . "Сигналим" watchdog, что система работает стабильно.
Проверка датчика воды. Считываем текущее состояние геркона.
Интеллектуальная системы уведомлений. Если это первоначальная проверка, после инициализации, то отправляем уведомление в Телеграмм бот текущего состояния, далее отправляем только при любом изменении состояния датчика.
Сохранение текущего состояния. Запоминаем состояние для сравнения в следующем цикле.
Очистка памяти после работы. "Убираем рабочее место" после завершения задач.
Пауза до следующего цикла. Ожидание перед повторной проверкой.
3. Периодическая перезагрузка (раз в неделю)
Мягкая перезагрузка системы для профилактики.
Структура проекта и порядок запуска модулей (файлов)
Теперь, когда есть продуманная логика, давайте посмотрим, как она превращается в реальные файлы на ESP. Важно понимать, что MicroPython имеет строгие правила автоматического вы��олнения файлов.
При ЛЮБОЙ загрузке ESP (питание, reset, перезагрузка):
1. boot.py → выполняется АВТОМАТИЧЕСКИ и ПЕРВЫМ
2. main.py → выполняется АВТОМАТИЧЕСКИ и ВТОРЫМ
Структура проекта:
├── boot.py # Автозапуск WiFi и WebREPL
├── config.py # Все настройки в одном месте
└── main.py # Основная логика мониторинга
boot.py — подключение к Wi-Fi и запуск WebREPL. Тот файл, который должен подготовить нам инфраструктуру, срабатывает первым, после передает управление в main.py.
Аналогия: подготавливает площадку (системная инициализация), проводит коммуникации (сетевое подключение Wi-Fi), устанавливает связь с офисом (WebREPL), передает объект рабочим (main.py)
config.py — Хранение всех настроек. НЕ выполняется автоматически - это модуль настроек для других файлов: пароли WiFi и WebREPL, токены Telegram бота, настройки датчиков и таймеров, константы сообщений. Преимущество: можем произвести изменения настроек в одном месте.
main.py — основная логика работы. Выполняется ВТОРЫМ после boot.py: прове��яет датчик, отправляет уведомления при изменениях, следит за памятью и стабильностью, работает в бесконечном цикле.
Начнем с файла config.py. Внизу код с подробными комментариями, можете после ознакомления удалить комментарии и оставить только настройки.
"""
Этот файл содержит ВСЕ настройки проекта. Здесь нет логики - только данные.
Изменив значения здесь, вы настроите всю систему под свои нужды
"""
# НАСТРОЙКИ WI-FI ПОДКЛЮЧЕНИЯ
WIFI_SSID = "my_wifi_network" # Имя вашей Wi-Fi сети
WIFI_PASSWORD = "my_password" # Пароль от Wi-Fi
"""
СОВЕТ: Если пароль состоит только из цифр, используйте бинарный формат:
WIFI_PASSWORD = b"12345678"
Это поможет избежать проблем с кодировкой.
"""
# НАСТРОЙКИ TELEGRAM БОТА
TELEGRAM_TOKEN = "1234567890:ABCdefGHIjklMNOpqrsTUVwxyz" # Токен вашего бота
TELEGRAM_CHAT_ID = "123456789" # Ваш Chat ID
"""
ВАЖНО: Никогда не публикуйте токен в открытом доступе!
Это как пароль от вашего бота - храните его в секрете.
"""
# НАСТРОЙКИ WEBREPL (УДАЛЕННОЕ УПРАВЛЕНИЕ)
WEBREPL_PASSWORD = "" # Пароль для входа в консоль WebREPL, не путать с паролем точки доступа ESP, которую я показывал в статье https://habr.com/ru/articles/961308/
"""
РЕЖИМЫ РАБОТЫ:
- Пустая строка "" = WebREPL ЗАПУЩЕН, но подключение к консоли БЕЗ запроса пароля
- Любой пароль = WebREPL ЗАПУЩЕН, при подключении к консоли запросит указанный пароль
Пример для включения: WEBREPL_PASSWORD = "1234"
"""
WEBREPL_SSID = "ESP32-WebREPL" # Имя точки доступа (можно изменить)
WEBREPL_WIFI_PASSWORD = "12345678" # Пароль Wi-Fi сети (можно изменить)
"""
Ели не используете WEBREPL, тогда не назначаем настройки и не пишем в boot.py - это экономит ~20 КБ RAM
"""
#ЗАМЕНИТЕ значения в кавычках на свои данные, Сохраните файл
Создаем файл boot.py, в котором будут находиться функции отвечающие за подключение к интернету и созданию WEBREPL. Предположим, нам нужен WiFi-инженер (connect_wifi), который отвечает за подключение к WiFi, используя настройки из нашего файла config.py, в его обязанности входит создать подключение и не забывать убрать свое рабочее место, для этого мы его наделяем правом делать это n-количество раз (для надежности) и быть готовым сообщить нам о результатах подключения (True-есть соединение, False- нет соединения).
Сотрудник №2: WebREPL-администратор (start_webrepl), который отвечает за открытие удаленного офиса техподдержки с отдельной точкой доступа, с обязанностями запуска WebREPL и ожиданием подключений, использует пароли из файла config.py.
Как это выглядит в коде:
#Берем только самое необходимое
from network import WLAN, STA_IF # Wi-Fi модуль + режим клиента (подключение к роутеру)
from time import sleep # Отслеживаем время
from gc import collect # Уборка памяти
from config import WIFI_SSID, WIFI_PASSWORD, WEBREPL_PASSWORD, WEBREPL_SSID, WEBREPL_WIFI_PASSWORD # Необходимые настройки
def connect_wifi():
"""WiFi-инженер - подключает к интернету"""
collect()# Уборка памяти
wlan = WLAN(STA_IF) # Создаем соединение в режиме клиента
wlan.active(True) # Активируем/включаем соединение
# Если не подключено, то передаем пароль и пробуем законектиться (даем 15 попыток), при каждой попытке – чистим память, если в одной из попыток – сработало, сохраняем результат True, если неудачно, то фиксируем результат False
if not wlan.isconnected():
wlan.connect(WIFI_SSID, WIFI_PASSWORD)
for i in range(15):
if wlan.isconnected():
collect() # Финальная очистка перед возвратом
return True
sleep(1)
collect()
return wlan.isconnected()
def start_webrepl():
"""WebREPL-администратор - настраивает точку доступа и запускает сервер"""
if WEBREPL_PASSWORD:
collect()# Уборка памяти
# Создаем и настраиваем точку доступа
from network import WLAN, AP_IF
ap = WLAN(AP_IF)
ap.active(True)
# Создаем настройки
ap.config(
essid=WEBREPL_SSID,
password=WEBREPL_WIFI_PASSWORD,
security=3, # WPA2-PSK (рекомендуется), если без пароля, то значение 0
channel=6, # Wi-Fi канал, более стабильный
hidden=False # Видимая сеть
)
collect()# Уборка памяти
# Запускаем WebREPL
import webrepl
webrepl.start(password=WEBREPL_PASSWORD)
collect()
return True # Успешный запуск
else:
return False # WebREPL отключен
connect_wifi()
start_webrepl()
print("Boot.py: WiFi и WebREPL запущены")
Создаем main.py — основная логика работы, наша рабочая площадка.
Здесь будут трудиться наши верные "рабочие лошадки" — специалисты, отвечающие за ключевые процессы системы. Каждый из них знает свои обязанности и инструменты, которые мы им предоставили.
Курьер-отправитель(send_telegram_message) - наш диспетчер сообщений, который отвечает за доставку уведомлений. Его обязанности — брать готовые тексты, аккуратно упаковывать их и отправлять по назначению через Telegram API. Он использует токен и chat ID из config.py, следит за тем, чтобы каждое сообщение дошло до адресата, и всегда очищает за собой рабочее место в памяти после отправки.
Дежурный оператор (read_water_sensor) - постоянно отслеживает текущее состояние датчика. Его работа —считывать показания геркона, преобразовывать электрические сигналы в логические состояния и при запросе сообщать текущее состояние датчика. Он знает: разомкнут геркон (воды нет) или замкнут (вода есть), фиксирует изменения и сообщает Курьеру.
Координатор-бригадир(main) - непосредственный руководитель, который управляет всем процессом. Он задаёт ритм работы, контролирует паузы между проверками, следит за сторожевой собакой системы и обеспечивает безупречную работу всего цикла. Его главная задача — поддерживать баланс между оперативностью реакции и экономным расходованием ресурсов.
Давайте рассмотрим файл main.py, который выполняется ВТОРЫМ после boot.py, отвечает за мониторинг датчика воды и отправку уведомлений.
from machine import Pin, WDT, reset # Для настройки пина, сторожевого пса и перезагрузки
from time import sleep# Для фиксации времени
from gc import collect# Для очистки памяти
from urequests import get# Для создания оповещения в Телеграмм
from config import TELEGRAM_TOKEN, TELEGRAM_CHAT_ID# Необходимые настройки из config
# НАСТРОЙКИ ОБОРУДОВАНИЯ
SENSOR_PIN = 4 # GPIO для подключения геркона, так же подойдут 16, 17, 18
CHECK_INTERVAL = 10 # Интервал проверки (10 сек для тестов, 20 сек и выше -рабочий)
WD_TIME = 35000 # Таймаут сторожевого пса (35 сек)
REBOOT_INTERVAL = 604800 # Интервал перезагрузки (7 дней)
# ТЕКСТЫ СООБЩЕНИЙ (константы в main.py)
MSG_WATER_ALARM = "? ВНИМАНИЕ: Вода в колодце! Включите насос!"
MSG_WATER_OK = "? Воды нет. Система мониторинга работает"
# ПОДКЛЮЧЕНИЕ ОБОРУДОВАНИЯ
water_sensor = Pin(SENSOR_PIN, Pin.IN, Pin.PULL_UP) # Инициализация геркона на указанном пине
# ФУНКЦИИ РАБОТЫ С ДАТЧИКОМ
def read_water_sensor():
"""
Оптимизированное чтение датчика воды: 3 измерения для защиты от дребезга
"""
count = 0 # Считаем количество обнаружений воды
# 3 измерения - оптимальный баланс скорость/надежность
for _ in range(3):
if water_sensor.value() == 0: # Геркон замкнут = вода есть
count += 1
sleep(0.01) # 10ms пауза между измерениями
# Если 2 из 3 измерений = "вода есть" → возвращаем True
return count >= 2
# ФУНКЦИЯ ОТПРАВКИ УВЕДОМЛЕНИЙ
def send_telegram_message(message):
"""
Отправка сообщения в Telegram, возвращает: True (успех) / False (ошибка)
"""
collect() # Чистим память перед отправкой
try:
url = f"https://api.telegram.org/bot{TELEGRAM_TOKEN}/sendMessage"
url += f"?chat_id={TELEGRAM_CHAT_ID}&text={message}"
response = get(url)
success = response.status_code == 200
response.close()
collect() # Чистим память после отправки
if success:
sleep(2)
return success
except Exception as e:
collect()
return False
# ОСНОВНОЙ ЦИКЛ РАБОТЫ
def main():
"""
Главный цикл мониторинга системы
"""
# Инициализация сторожевого пса
wdt = WDT(timeout= WD_TIME)
send_telegram_message("Система мониторинга воды запущена!")
sleep(3)
# Переменная для хранения предыдущего состояния
previous_water_state = None
# Счётчик времени работы системы
system_uptime = 0
# Бесконечный цикл мониторинга
while True:
# Сбрасываем(кормим) сторожевого пса
wdt.feed()
# Читаем текущее состояние датчика
current_water_state = read_water_sensor()
# Логика отправки сообщени��
if previous_water_state is None or current_water_state != previous_water_state:
if current_water_state:
send_telegram_message(MSG_WATER_ALARM)
else:
send_telegram_message(MSG_WATER_OK)
# Сохраняем текущее состояние для следующего цикла
previous_water_state = current_water_state
# Учет времени для плановой перезагрузки
system_uptime += CHECK_INTERVAL
if system_uptime >= REBOOT_INTERVAL:
send_telegram_message("Плановая перезагрузка системы для профилактики")
sleep(2) # Даём время на отправку сообщения
reset() # Выполняем перезагрузку
# Пауза перед следующей проверкой
sleep(CHECK_INTERVAL)
collect()
# ЗАПУСК(ТЕСТИРОВАНИЕ) СИСТЕМЫ
print("Для выхода из цикла нажмите CTRL+C") # Временная версия для тестирования
main()
Ниже я подробно опишу, что означает код.
Производим оптимизированные (необходимые) импорты инструментов. Создаем необходимые константы (настройки).
Создаем water_sensor (датчик воды), который будет работать с ногой (пином) номер 4. Эта нога будет настроена как ВХОД (IN), и мы подключим к ней внутренний "подтягивающий" резистор (PULL_UP), чтобы она вела себя предсказуемо. То есть 4 пин настроен как вход для чтения данных, на него будет подаваться слабое напряжение(PULL_UP).
Когда НЕТ контакта с землей (сухо): подтягивающий резистор держит пин в состоянии НАПРЯЖЕНИЯ (3.3V), микроконтроллер читает значение 1 (HIGH), water_sensor.value() возвращает 1
Когда ЕСТЬ контакт с землей (вода обнаружена): датчик замыкает цепь на GND (землю), напряжение "утекает" в землю, микроконтроллер читает значение 0 (LOW), water_sensor.value() возвращает 0. Используйте GPIO4 или GPIO2 - они работают на всех популярных модулях ESP и не конфликтуют с системными функциями
Наш Дежурный оператор (read_water_sensor) работает по принципу "тройной проверки" для обеспечения надежности показаний. Функция трижды с небольшими промежутками (по 10 миллисекунд) проверяет состояние датчика. Каждый раз, когда датчик показывает наличие воды, увеличивается счетчик совпадений. Для принятия окончательного решения используется логика "два из трех". Это означает: если вода обнаружена в двух или трех проверках из трех - функция сообщает "вода есть" (возвращает True), если вода обнаружена только в одной проверке или ни разу - функция сообщает "воды нет" (возвращает False). Такой подход защищает систему от ложных срабатываний, которые могут возникнуть из-за случайных помех, вибраций или кратковременных колебаний сигнала (так называемого "дребезга" контактов). Благодаря проверке система получает стабильные данные о наличии воды.
Курьер-отправитель(send_telegram_message) отвечает за доставку вам сообщений через TelegramBot. Перед началом отправки функция освобождает оперативную память устройства для обеспечения стабильной работы. Затем она формирует специальный интернет-адрес, который содержит все необходимые данные: уникальный идентификатор бота, номер чата для получения сообщений и сам текст уведомления. Функция пытается отправить запрос к серверам Telegram и проверяет ответ. Если отправка прошла успешно (сервер подтвердил получение), функция возвращает положительный результат. Если же в процессе возникли какие-либо проблемы - ошибки сети, недоступность сервера или другие сбои - функция перехватывает исключение и возвращает отрицательный результат, который, при необходимости и для включения дополнительных действий или проверок, можно использовать. После завершения отправки (независимо от результата) функция снова освобождает оперативную память, чтобы устройство продолжало работать эффективно.
Координатор-бригадир (main) следит и организует работу рабочего непрерывного цикла. При запуске он активирует "сторожевого пса" - специальный таймер, который непрерывно следит за работоспособностью устройства. Если система по какой-либо причине зависнет и перестанет выполнять циклы проверки, "сторожевой пес" автоматически перезагрузит устройство через установленное время, обеспечивая восстановление работоспособности без вмешательства.
Сразу после запуска отправляется сообщение "Система мониторинга воды запущена!", которое информирует о начале работы устройства. Это сообщение позволяет отслеживать все перезапуски системы - как плановые, так и аварийные, вызванные срабатыванием "сторожевого пса" или перебоями питания.
Координатор-бригадир постоянно отслеживает состояние датчика воды, но отправляет сообщения только в ключевые моменты: при первом запуске сообщается текущий статус (есть вода или нет), при каждом изменении состояния датчика отправляется соответствующее уведомление, если состояние не меняется - система работает молча - вы получаете уведомления только тогда, когда действительно происходит что-то важное.
Для организации плановой профилактической перезагрузки Координатор-бригадир ведет учет общего времени своей работы. После достижения установленного лимита (7 дней) выполняется перезагрузка. Эта мера на случай потенциального накопления ошибок и утечек памяти, которые могут возникать при длительной непрерывной работе. Перед перезагрузкой происходит информирование - "Плановая перезагрузка системы для профилактики".
Давайте попробуем запустить.
Мой «подопытный» - ESP32 38pins. Для проверки срабатываний я использовал провод-перемычку DuPont, для тестирования измените значения CHECK_INTERVAL поставьте 10. Используйте GPIO4 или GPIO2 - они работают на всех популярных модулях ESP и не конфликтуют с системными функциями.
Для тестирования "сторожевого пса" измените значение WD_TIME на 10000.

Должно получиться примерно так

В процессе сборки кода для системы мониторинга воды на ESP32/ESP8266 могли возникнуть различные ошибки. Ниже раздел, который поможет их избежать или исправить.
Возможные ошибки и способы их устранения
Скрытый текст
1. Синтаксические ошибки
Ошибка: SyntaxError: invalid syntax
Причина: Часто из-за пропущенных запятых, скобок, неверных отступов или опечаток.
Пример: В вызове ap.config() забыли запятую между параметрами.
Решение: Внимательно проверьте запятые, скобки и кавычки. Используйте редактор с подсветкой синтаксиса.
Ошибка: IndentationError
Причина: Неправильные отступы. В Python отступы важны для определения блоков кода.
Решение: Убедитесь, что используете одинаковые отступы (рекомендуется 4 пробела).
2. Ошибки подключения к WiFi
Ошибка: Не подключается к WiFi
Причина 1: Неверный SSID или пароль.
Решение: Проверьте WIFI_SSID и WIFI_PASSWORD в config.py. Убедитесь, что пароль в кавычках.
Причина 2: Слабый сигнал или неправильный режим работы.
Решение: Убедитесь, что WiFi-модуль активирован в режиме станции: wlan = WLAN(STA_IF).
Ошибка: OSError: [Errno 2] ENOENT
Причина: Не удалось найти сеть. Возможно, SSID содержит спецсимволы или неверно записан.
Решение: Проверьте, видит ли ваш телефон эту сеть. Попробуйте переименовать сеть, убрав спецсимволы.
3. Ошибки отправки сообщений в Telegram
Ошибка: Сообщения не отправляются
Причина 1: Неверный TELEGRAM_TOKEN или TELEGRAM_CHAT_ID.
Решение: Проверьте токен и chat ID. Убедитесь, что бот создан и вы подписаны на него.
Причина 2: Нет интернет-соединения.
Решение: Убедитесь, что WiFi подключен. Добавьте проверку перед отправкой: if wlan.isconnected():
Причина 3: Слишком частые запросы.
Решение: Telegram может блокировать при частых запросах. Добавьте задержки между сообщениями.
4. Ошибки работы с датчиком
Ошибка: Датчик всегда показывает одно значение
Причина 1: Неправильное подключение.
Решение: Проверьте схему подключения. Геркон должен замыкаться на GND при наличии воды.
Причина 2: Неверный пин.
Решение: Убедитесь, что используете правильный GPIO. Проверьте распиновку вашей платы. SENSOR_PIN = 4 # универсальный для всех ESP
Ошибка: Ложные срабатывания
Причина: Дребезг контактов или помехи.
Решение: Используйте программную защиту (как в read_water_sensor(): несколько измерений с задержкой).
5. Ошибки памяти
Ошибка: MemoryError
Причина: Нехватка оперативной памяти.
Решение:
Регулярно вызывайте gc.collect().
Убедитесь, что импортируются только необходимые модули.
Избегайте создания больших строк или списков.
6. Ошибки при запуске WebREPL
Ошибка: WebREPL не запускается
Причина 1: Неверный пароль или пароль не установлен.
Решение: Убедитесь, что WEBREPL_PASSWORD установлен в config.py.
Причина 2: Конфликт портов или уже запущенный WebREPL.
Решение: Перезагрузите устройство.
7. Ошибки сторожевого таймера (Watchdog)
Ошибка: Случайные перезагрузки
Причина: Сторожевой таймер срабатывает, потому что не сбрасывается вовремя.
Решение: Убедитесь, что wdt.feed() вызывается в основном цикле чаще, чем timeout.
8. Общие советы
Проверьте синтаксис - нет ли пропущенных запятых, скобок
Убедитесь в правильности пина - используйте GPIO4 для тестов
Проверьте пароли - без лишних пробелов, в правильном формате
Добавьте диагностику - print() для отслеживания этапов
Протестируйте модули по отдельности - сначала WiFi, потом датчик, потом Telegram
Проверяйте питание: Нестабильное питание может вызывать случайные перезагрузки.
Если вы столкнулись с ошибкой, не описанной здесь, попробуйте поискать в документации MicroPython или на форумах, посвященных ESP32/ESP8266.
Ваша логика — главный ресурс
В этой статье попробовал показать путь от идеи до работающего кода, создав систему мониторинга воды на ESP32. Но самое важное — не код, а ваше логическое мышление, которое позволяет превращать идеи в работающие устройства.
Помните, что любой проект начинается с тщательного планирования и понимания, что вы хотите получить в результате.
Микроконтроллеры, такие как ESP32 и ESP8266, — это мощные инструменты, но их ресурсы ограничены. Ваша задача — уместить свою логику в эти рамки, используя эффективные подходы, такие как очистка памяти, сторожевой таймер и экономичные уведомления.
Для отладки и экспериментов используйте онлайн-песочницы и симуляторы MicroPython — там можно тестировать код без риска для реального железа. И не стесняйтесь искать готовые решения: «гуглите», «яндексите», «джипичатите» - стоящие идеи часто лежат на поверхности.
В следующей статье я покажу сборку датчика уровня воды «от и до»:
- Выбор компонентов и их стоимость
- Монтаж и защита от влаги
- Установка в колодце
- Тестирование в реальных условиях
- Подводные камни, которые мне встретились
Творите, экспериментируйте и помните: самый главный ресурс — это ваша идея и логика, а код — всего лишь инструмент для ее реализации.
Удачи в проектах!
juramehanik
Поясните пожалуйста в чем в данном случае плюс микропитона над плюсами? Просто по коду и на уровне плюсов можно так же писать на том же уровне абстракции не сильно делая кучу дополнительной работы. Либы для esp и приемов работы на плюсах очень много. Библиотеки для работы с вайфаем удобнее или ещё что? Или молодое поколение к программированию МК без питона тяжелее привлечь?
wmns
Тоже непонятно, но видимо чтобы не писать на сях несмотря на наличие esp-idf? Кстати, зачем плюсы, если все есть для нормального Си?
Alex_Polo_123 Автор
Вы правы - на C++ с библиотеками вроде Arduino действительно позволяет работать на высоком уровне абстракции. Акцентирую ваше внимание, я ни в коем случае не агитирую против C++ и не утверждаю, что MicroPython — это «лучше», просто делюсь своим опытом. Так как я погружен в Python, то для решения бытовых задач (считать датчик, отправить данные) мне ближе MicroPython, так как оказался удобным способом погрузиться в мир МК, и мне не надо переключаться на совершенно новую парадигму, а использовать уже знакомые модели и через REPL в реальном времени "пощупать" железо без цикла компиляции-прошивки для начальных стадий прототипирования.