Как стать автором
Обновить

Простой способ управления IoT-устройствами через телеграм-бот, используя esp32

Уровень сложностиСредний
Время на прочтение10 мин
Количество просмотров9.4K
Всего голосов 33: ↑33 и ↓0+51
Комментарии20

Комментарии 20

то сервер временно заблокирует бота и будет возникать ошибка 429.

Telegram уже давно ввел параметр "timeout" в методе getUpdates. С ним и задержки не будет, и нагрузку на сервер (и предпосылок для бана) не создадите.
В используемой библиотеке вроде как нет такой возможности, но ничто не мешает дописать )

Это называется long-polling-ом или долгими опросами. Так называемая золотая середина между частыми опросами и дуплекскым соединением(он же websocket)

Поясните, данный способ используете для управления IoT-устройствами внутри дома (примерно 100 м) или удаленно от дома( например 10 км)?

Я понимаю к чему вы клоните - LORA, а раньше gprs-модем:-)
Когда то давно юзал gprs-модем - была такая плата arduino gprs с симкой. В том числе для неограниченно удалённых устройств (коммерческий проект).

В данный момент для себя решил, что если буду нечто подобное делать в наше время - старый смартфон в качестве wifi-точки доступа + подключенная к ней esp32 - это если прям совсем автономно надо (подключенные к стационарному питанию естественно).

Если не совсем автономно (например, дома)- роутер+esp32 подключенные по wi-fi рулят.

Из своего опыта могу заметить.

Если делать на расстоянии до 100 метров, например, в квартире, то очень удобно использовать соединение точка-точка , для ESP это протокол ESP-NOW или BLE. В этом случае запаздывание команд управления будет не более 10 ms. При этом нет надобности использовать mqt

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

При работе по Wi-Fi наибольшее быстродействие можно получить используя UDP вместо TCP.

Тоже хороший вариант:-) Да, вариантов много. Я тут скорее акцентировался на доме с довольно развитой информационной инфраструктурой (типичный современный случай). Так как мало кому реально нужно рулить чем то на отшибе цивилизации - чаще всего бывает достаточно управлять чем то в зоне действия сети роутера...:-)

P.S. забыл добавить - а сам в этот момент на работе (например).

Повторю ранее добавленное. При Wi-Fi надо использовать UDP вместо TCP. задержка тоже в пределах 10 ms и в пределах 100 ms, если ESP будет спать +плюс задержка интернет. Рулить можно откуда угодно.

да, согласен

Проверил на ESP32-C3, сразу заработало, быстрый отклик. Спасибо!

Дополню - в примерах библиотеки для телеграм есть отправка изображения с ESP32 Cam. Можно сделать дверной звонок, который отправит фото посетителя в чат. Из этого же чата выполнить команду на открытие замка (электромагнита или электромеханического). Главное, что не нужен доп. сервер.

Я сделал для холодильника, чтобы в семейную группу слал фотки открывшего дверцу после 22.00 :)

На базе этого кода?:-))) То есть, можно поздравить первого применившего в реальном деле?:-)))

Нет, я успел несколько раньше публикации)

А чем longPolling не угодил? Там запросы хоть раз в минуту можно делать и реакция мгновенная.

Посмотрите мой проект, может что интересное для себя найдете

https://github.com/SergeyF11/TelegramOpener

Наверное, единственный минус - опросы. Ну и тот прискорбный факт, что Телеграм местами тоже отваливается или вообще не работает (эти "санкции" называются Роскомнадзор).

Можно конечно сделать на вебхуках - но тогда нужен реальный IP, а уже тогда проще повесить на него mqtt-брокер, скрестив его с ботом...
И добавить llm-ку, чтобы писать что-то типа "включи прожектор и поверни камеру левее" - а уже оно отправляло бы нужные команды устройствам )

В своё время, когда я только начал применять удалённое управление своим устройством, тоже использовал ТГ-бот, только с библиотекой FastBot от Gyver'а. Работает классно, если это действительно нужно. При отладке бывало, что сообщения отправлялись непрерывно, но сервер справлялся и в бан не отправили. Ну то я сам накосячил в коде )
Пробовал Whatsapp-бот -- работает нестабильно, иногда сообщения доходят с неприемлемой задержкой.
Потом написал свою веб-морду и перешёл на асинхронный выеб-сервер )

Идея прикольная, но если смотреть с позиции более серьёзных задач polling через Tg API не очень надёжный путь. Задержки, лимиты, отсутствие нормального QoS всё это начинает мешать, как только ты выходишь за рамки “поиграться вечером”.

Для чего-то более стабильного я бы всё же смотрел в сторону MQTT, где есть и real-time, и надёжность, и меньше головняка на больших объемах. Но как концепт — кайф, простота подкупает. Можно даже в учёбе использовать, чтобы втянуться в тему IoT.

запоминание Chat ID — необходимая процедура в целях безопасности: если этого не сделать, то любой пользователь сможет управлять вашим ботом, если узнает имя бота

Как-то запоминание chat id звучит ненадежно.


Сценарий:

  • злоумышленник узнаёт имя бота

  • начинает регулярно слать ему сообщения (который бот пока что игнорирует из-за несоответствия chat id)

  • в доме моргнул свет, устройство перезагрузилось, чат-айди сбросился

  • следом прилетает очередное сообщение от злоумышленника (который все это время продолжал слать сообщения в цикле)

  • для бота после ребута это сообщение - первое, бот запоминает его чат айди и начинает слушаться нового хозяина (до очередной перезагрузки)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий