Arduino Mega. Контроллер теплицы. Хроники - 3.0

РЕКЛАМА НА ФОРУМХАУС

Щас пойду попробую порыть, в чём дело с MQTT-топиками разными - возможно - дороюсь таки.

 

Вот - пруф бага в MQTT. fx, отправил два топика (payload в обоих одинаковый - ON):

Код:

          z  z  z  /  S  E  T  /  L  I  G  H  T  O  N
30 11 00 7A 7A 7A 2F 53 45 54 2F 4C 49 47 48 54 4F 4E 0D
             z  z  z  /  S  E  T  /  L  I  G  H  T  /  O  N
30 12 00 0E 7A 7A 7A 2F 53 45 54 2F 4C 49 47 48 54 2F 4F 4E

Видно, что первый топик zzz/SET/LIGHT, второй - ZZZ/SET/LIGHT/ - отличаются только слешем в конце. При этом длина топика (0D, т. е. 13 байт) в первом MQTT-пакете - в конце (?), хотя ОБЯЗАНА быть, начиная с третьего байта (!).

Во втором пакете видно, что длина данных - 14 байт (00 0E), а в первом после 00 - 0D ускакало в конец. Первый топик должен быть вот такой:

Код:

             z  z  z  /  S  E  T  /  L  I  G  H  T  O  N
30 11 00 0D 7A 7A 7A 2F 53 45 54 2F 4C 49 47 48 54 4F 4E

Вывод - MQTT. fx косячит, ибо первый топик не соответствует стандарту. Щас попробую проверить на MQTT. dash на андроиде.

Правка: с MQTT. dash тоже не проходит топик zzz/SET/LIGHT - значит, и я олень буду рыть

Правка 2: ничего не понимаю - MQTT. dash тоже пихает в конец payload байты длины, причём для zzz/SET/LIGHT с сообщением ON - там в конце 0D, т. е. 13 (верно), а вот для топика zzz/SET/LIGHT с сообщением OFF - последний непонятный байт - 0x33, т. е. аж 55. В документации к протоколу ничего такого не нашёл, пойду читать ещё раз: ну не может быть, чтобы вот на ровном месте из-за одного слеша такая хренотень

Правка 3: прежде чем гнать на клиентов, надо убедиться, что они отправляют ИМЕННО то, что принимает ESP. Т. к. у меня смутные сомнения - по описанию протокола приходящий в одном случае пакет - тупо невалидный.

 

IP в конфигуратор отображались 7 0.0.0 и 77.110.0.111 или что то похожее.
С MQTT все заработало как вы писали. А изменение статуса я смотрел в конфигураторе

 

В общем, похоже на трудноуловимую зависимость с MQTT - там в пакете могут приходить байты \r и \n, т. к. протокол не текстовый - по-видимому, где-то что-то у меня ломается, когда в данных топика такое попадает.

Щас пробую фиксить.

 

Нашёл проблему, она идеологическая: оперативки мало, поэтому принимаю от ESP команды построчно. В команде +IPD ESP сообщает, что пришло N байт данных. Вычитывать все байты сразу - не алё, там может придти куча данных в ответ на HTTP-запрос, например. Следовательно - бьём по признаку новой строки \n, символ перевода каретки \r - игнорируем в потоке.

И вот тут засада: MQTT-протокол - бинарный, там в пакете могут быть и \n, и \r. Поэтому на некоторых топиках из-за отбрасывания \r ничего не получалось.

Короче, косяк чисто мой, клиенты MQTT. fx и MQTT. dash тут не при чём. Сейчас буду думать, как это дело максимально безболезненно обойти, чтобы, не дай бог, не поломать другой логики.

 

Дмитрий, подскажите как правильно обновлять прошивку контроллера?
Я вот сейчас закомментировал все ненужные мне плюшки, выйдет обновление и нужно будет заново все комментировать? Предполагаю что можно сохранить Configuration_MEGA.h и после обновления заменять. Но в этот файл вы ведь также можете вносить изменения...

 

Именно для этого и есть гит - вы в любом гит-клиенте можете посмотреть, что и где поменялось, и обновить только то, что не затрагивает ваши изменения Если просто каждый раз перекачивать - да, будете каждый раз вынуждены перенастраивать. Но гит - штука мощная, ознакомьтесь

 

Короче, упёрся в ограничение архитектуры: сейчас надо вот как-то суметь понять, что приходящие от ESP данные - это пакет MQTT, а это уже сильно смахивает на костыль В Arduino Core я чуть по другому реализовал архитектуру - там всё норм с этим, а вот из-за постоянных доработок контроллера теплицы сейчас столкнулись с проблемой неоднозначности: я не могу игнорировать ни байта, если приходит MQTT-пакет, при этом все остальные данные я легко могу бить на строки, игнорируя \r - для HTTP это вообще ни разу не важно.

В общем, морщу лоб, хотел сегодня лечь спать пораньше, но, видимо, не судьба Иначе у нас так и будет проблема, когда в каком-то топике выплывет гадость его неотработки чисто из-за того, что где-то внутри пакета попались байты 0x0D или 0x0A. Непорядок - жуткий, надо фиксить.

 

Обновил прошивку, изменения в двух файлах: Main. ino и WiFiModule. cpp. Переписал процесс разбора данных от ESP, чтобы в случае с приходящим MQTT-пакетом он вычитывался целиком, а остальные - пущай бьются по строкам, там не страшно.

Сейчас гоняю одновременно: MQTT - раз в 5 секунд топики публикуются; ThingSpeak - раз в 30 секунд туда данные пуляются; gardenboss. ru - тут полегче, всего раз в 5 минут; вебморда - открыта постоянно, обмен данными идёт примерно той же интенсивности, что и через конфигуратор. Пока полчаса работы - полёт нормальный.

Топик MQTT SET/LIGHT с сообщением ON - работает, т. е. уже нет проблемы с этим самым слешем. Надо пробовать, гонять туда-сюда, но уже представляется, что отлаживать весь зоопарк - крайне сложно, и, как бы не хотелось совершенства - оно, увы, пока недостижимо.

Поэтому буду очень признателен за багрепорт - что не так, что не работает и т. п. С введением MQTT (хотя это и крайне нужная вещь) - очень много уже крови потрачено из-за всяких нюансов. Но сдаваться - не хочется

В общем, заранее благодарен за отчёты И очень надеюсь, что ещё одной проблемой стало меньше и мы приблизились к финалу.

 

Прошёл час работы: увеличил частоту топиков MQTT на раз в 5 секунд, гоняю через MQTT. fx разные команды - пока все выполняет без проблем (ттт). ThingSpeak тоже, ттт, живой. На gandenboss. ru данные отправляются, вебморда, сто раз ттт - доступна: переключался между показаниями и настройками много раз.

Продолжаю тестирование.

 

Восемь с половиной часов работы - пока ничего страшного не замечено, всё работает паралельно. Иногда пересекаются по времени меж собой модули, поэтому чуть сдвигается время отсыла то там, то здесь, но в целом - всё отсылается и на сервисы, и в вебморду, и в MQTT-брокер. Предварительный осторожный вывод - крайние исправления можно считать удачными, ттт.

 

Иногда таки где-то есть хитрые зависимости - видно, что ESP переинициализируется. На работоспособность это в целом не влияет, т. к. все соединения восстанавливаются, однако факт остаётся фактом - одновременная работа сразу во все дырки - это вызов

Буду наблюдать. Пока отключил ThingSpeak, оставил MQTT, вебморду, gardenboss. ru - посмотрим, изменится ли что-то в плане довольно редких переконнектов.

 

Хз, короче По виду всё работает нормально, учитывая костыли Какие-то тонкие зависимости всё равно есть, и наверняка есть - без этого никуда. Буду наблюдать, в принципе, редкие переконнекты не страшны, да и не знаю я, чем они вызваны - тем, что ESP иногда теряет коннект к роутеру (и такое с ней случается), или тем, что в коде где-то что-то иногда так срастается, что не отпускает очередь команд и ESP становится как бы "зависшим", с точки зрения логики.

В целом - всё работает стабильно, не замечал вылетов вебморды, иногда, как я уже упоминал, из-за коллизий - тот или иной функционал тормозит, пока не отработает что-то другое и ESP не освободится.

Короче - вопрос: чего делать будем? Переписывать всю архитектуру работы с SIM800 и ESP на новую? Вот честно - этого я хочу меньше всего Но и костыли в виде принудительных указаний индексов клиентов для какого-то транспорта - напрягают неимоверно.

Поделитесь мыслями, поддержите, тыксызыть - надо выработать какое-то решение. Повторюсь только - что сейчас всё работает параллельно и стабильно, откуда вылазят редкие реконнекты - хз, надо разбираться в отладочном режиме, этим сейчас занимаюсь.

Но сторонние мнения - очень интересны, не скупитесь - черкните пару строк.

 

Сейчас буду ловить реконнект - вставил бесконечный цикл в место, где по внутренним признакам надо перезагружать ESP - вот и посмотрим, что перед этим делом вызывает такое поведение Поймаем заразу

 

Потихоньку ищу - уже нашёл один косячок, тема Так все и выловим