#полоумныйдом Почему mqtt – это плохо ;)
Наглядно, почему MQTT, при всех своих плюсах, “плюшка” и бонусах с наивной простотой – в общем-то, не очень подходящий протокол для нормальной работы #полоумногодома. Обычно народ жизнерадостно обсуждает какие-то совершенно невменяемые “плюшки” аля “смотрикакяумею: хлоп – и чайник через интернет с работы дома включил” – но вот ни разу практичные вещи, много, скажем так, не договаривают (есть очень ценные исключения, с наворотами), и вот, собственно, по мере собственного хождения по граблям, появляются реальные наработки:
MQTT сервер был недоступен с 16:00 до 20:00 (планово отсутствовал свет, бесперебойник был выключен заранее). Батарейка “сбросила” где-то пол-месяца работы за менее чем 4 часа 😉
Мораль:
- для начала, надо поправить код подключения и к WiFi, и к MQTT-серверу (сейчас по умолчанию по пять попыток передподключения, плюс обработка бесчисленных исключительных ситуаций, совершенно бесполезных); надо внести отслеживание ситуации отсутствия MQTT-сервера (да и wifi и пропорционально увеличить продолжительность время нахождения в “глубоком” сне, скажем, до 30-40 минут при отсутствии подключения 2-3 раза) в целом, эта мера автоматом ухудшит и без того не очень-то надежную, но крайне накладную реализацию доставки данных до ПЛК;
- в финале – сносить MQTT к чертям, уходить на периодически “просыпающихся” датчиках с deepsleep на UDP-обмен; реализовать UDP-сервер + MODBUS TCP шлюз (который будет опрашиваться напрямую с контроллера); задублировать их (сделать парочку, 130 рублей не жалко 😉 ); на постоянно включенных (omg даже с исполнительными механизмами!!$#@!!) реализовывать MODBUS TCP/Slave и опрашивать напрямую с контроллера;
Параллельно, выясняютя очень любопытные “бонусы”, например, датчик BME280/BMP280 на глубоко спящих устройствах вообще малопригоден (привет, китайские поделки на AMS230x!), почему полезно применять аналоговые датчики (K-тип термопары, например). Короче, масса нюансов, которые все тщательно обходят стороной 😉
Может взлететь, посмотрим.