В прошлой статье  мы дали голос нашему ESP32 — научили его отправлять уведомления в Telegram и ntfy. Теперь, когда устройство умеет "говорить", пришло время научить его "думать" и работать самостоятельно, без постоянного контроля.

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

В реальном проекте недостаточно просто уметь отправлять уведомления — нужно понимать:

  • Когда их отправлять (чтобы не спамить).

  • Что делать между уведомлениями.

  • Как не зависнуть через неделю работы.

  • Куда девать ограниченную память ESP32.

 Разработка программы для микроконтроллера — это техническая реализация вашей идеи. Сама идея — это продуманная вами логика работы системы. Код — это просто инструкция для железа, как исполнять эту логику.

Пример:

  • «Следи за водой в колодце и сообщай, если что-то изменится» — это логика.

  • «Раз в 3 минуты проверяй датчик, сравнивай с предыдущим состоянием, и если оно изменилось — отправляй сообщение в Telegram» — это уже техническая реализация логики, которую необходимо перевести в код.

В микроконтроллерах, особенно с MicroPython, важно продумать не только что делать, но и как делать с учетом ограниченной памя��и и других ресурсов.

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

 При работе с ESP, я выработал для себя несколько правил:

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

  2. Учитывать ограничения памяти — регулярно её чистить, до и после выполнения операции, MicroPython может «захлебнуться» в постоянном цикле.

  3. Добавлять защиту от зависаний — сторожевой таймер, если система "задумалась" — автоматически перезагружаем.

  4. Быть экономным с уведомлениями — сообщать только о важном, не спамить, а информировать о изменениях состояния.

  5. Импортировать только необходимые и используемые инструменты из встроенных модулей, не тащить в память лишнее.

  6. Предусматривать автоматическую принудительную перезагрузку (1 раз в неделю) для профилактики накопления ошибок.

  7. Тестировать код (отдельные фрагменты)

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

От логики к алгоритму: проектируем систему мониторинга воды в колодце

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

Этапы работы системы:

 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 38pins
Распиновка ESP32 38pins

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

Результат
Результат

В процессе сборки кода для системы мониторинга воды на 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 — там можно тестировать код без риска для реального железа. И не стесняйтесь искать готовые решения: «гуглите», «яндексите», «джипичатите» - стоящие идеи часто лежат на поверхности.

 В следующей статье я покажу сборку датчика уровня воды «от и до»:

- Выбор компонентов и их стоимость

- Монтаж и защита от влаги 

- Установка в колодце

- Тестирование в реальных условиях

- Подводные камни, которые мне встретились

 Творите, экспериментируйте и помните: самый главный ресурс — это ваша идея и логика, а код — всего лишь инструмент для ее реализации.

Удачи в проектах!

Комментарии (3)


  1. juramehanik
    08.11.2025 15:01

    Поясните пожалуйста в чем в данном случае плюс микропитона над плюсами? Просто по коду и на уровне плюсов можно так же писать на том же уровне абстракции не сильно делая кучу дополнительной работы. Либы для esp и приемов работы на плюсах очень много. Библиотеки для работы с вайфаем удобнее или ещё что? Или молодое поколение к программированию МК без питона тяжелее привлечь?


    1. wmns
      08.11.2025 15:01

      Тоже непонятно, но видимо чтобы не писать на сях несмотря на наличие esp-idf? Кстати, зачем плюсы, если все есть для нормального Си?


    1. Alex_Polo_123 Автор
      08.11.2025 15:01

      Вы правы - на C++ с библиотеками вроде Arduino действительно позволяет работать на высоком уровне абстракции. Акцентирую ваше внимание, я ни в коем случае не агитирую против C++ и не утверждаю, что MicroPython — это «лучше», просто делюсь своим опытом. Так как я погружен в Python, то для решения бытовых задач (считать датчик, отправить данные)  мне ближе MicroPython, так как оказался удобным способом погрузиться в мир МК, и мне не надо переключаться на совершенно новую парадигму, а использовать уже знакомые модели и через REPL в реальном времени "пощупать" железо без цикла компиляции-прошивки для начальных стадий прототипирования.