|
Воскресенье, 01.12.2024, 19:21 | | RSS |
|
Защита, контроль, управление |
|
Web интерфейс,JS и все что с ними связано.
|
|
pop | Дата: Среда, 28.02.2018, 08:52 | Сообщение # 121 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html Это официальный ресурс. По-русски, к сожалению, не нашёл. Но протокол довольно простой. Да. ESP-шку можно и как шлюз для других протоколов использовать. Но чисто шлюзом, ИМХО, не совсем рационально, и разве только для датчиков. Мне больше нравится концепция "законченное умное устройство", независимое от внешних устройств, но способное с ними взаимодействовать. Пока, не понимаю - возможно есть ограничения для такого подхода. Может, Вы как практик, поможете увидеть что-то нереализуемое в такой концепции?
|
|
| |
AlexAW | Дата: Среда, 28.02.2018, 09:24 | Сообщение # 122 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| pop, Все реализуемо. Вопрос на сколько это ресурсоемко, и какие физические среды использовать. По сути в MQTT Брокер работает как буфер с точки зрения клиента подключаемого к сети. Задача произвести процедуру соединения с брокером получить подтверждение и забрать (отдать) сообщение. Если в качестве среды передачи можно воспользоваться последовательным интерфейсом, то возможно будет создавать не слоные законченные устройства и на МК среднего семейства.... В том числе и среду RS485 так же использовать для MQTT не переделывая устройства физически а тупо меняя прошивку.... Это к вопросу о смене протокола в распределенном сегменте. Вообще конечно центральное устройство лучше снабжать несколькими протоколами для распределенного сегмента, это будет позволять встраивать весь имеющийся зоопарк периферийных устройств.
|
|
| |
pop | Дата: Среда, 28.02.2018, 09:37 | Сообщение # 123 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| http://www.tssonline.ru/article....otocol. Вот немного основного по-русски.
Добавлено (28.02.2018, 09:37) ---------------------------------------------
Цитата AlexAW ( ) Вообще конечно центральное устройство лучше снабжать несколькими протоколами для распределенного сегмента, это будет позволять встраивать весь имеющийся зоопарк периферийных устройств. MQTT , вроде бы, организован поверх TCP. По крайней мере, то, что уже узнал о нём. Суть в том, что подключиться и не "забрать", а получить то, что брокер тебе отдаст. А отдаст он то, на что подпишешься. По сути, очень похоже на "форум" или "чат" для устройств. Что приятно, есть 3 уровня QoS. Т.е., в зависимости от потребностей, можно получать сообщения гарантированно или нет. Т.е., даже разрывы связи на короткое время не страшны. Недостатки в таком подходе тоже мне кажется есть. Вся работа основывается на СОБЫТИЯХ. Хранить состояния брокер не умеет (при "наивной" организации). Но он умеет хранить события и гарантировать их доставку когда надо. Насчёт ресурсов. Основное - уметь создать подключение к серверу. Остальное - минимум. Накладных расходов не много, практически, по сети летает только то, что в неё отправляется, и подтверждения о получении.
Сообщение отредактировал pop - Среда, 28.02.2018, 09:42 |
|
| |
AlexAW | Дата: Среда, 28.02.2018, 09:51 | Сообщение # 124 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| Читая вот тут https://ipc2u.ru/articles/prostye-resheniya/chto-takoe-mqtt/ Протокол MQTT работает на прикладном уровне поверх TCP/IP Я понимаю что для его реализации надо создать физику сети типа проводной сети или радиоканала, потом организовать канальный уровень TCP/IP а уж потом прикручивать MQTT. Эт задачка для среднего семейсва МК напряжная. Тут надо переезжать на СИ и МК старшего семейства. Или садиться для более быстрого решения задач на ардуинки нано или те же ESP и пользовать кучу наработаных библиотек. Это короткий путь.
Задача написать шлюз MQTT ModBus не тривиальная, и я считаю полезная - наличие шлюза или даже шлюзов может позволить организовать взаимодействие уже разработанных ModBus устройств в мини сетях под руководством этих шлюзов, между собой и с центральным устройством. У этих шлюзов должен быть свой интерфейс настройки (например ВЕБ) где дужет указываться подписки -преобразуемые в команды модбаса подаваемые на устройства и преобразование полученой информации от устройств в соответствующие издания. В малых модбас сетях опрос будет происходить очень быстро и соответственно переброска в MQTT будет быстрой. Значит и контроль и управление от центрального устройства будет проходить быстрее..... Опять же благодаря наличию шлюзов можно выполнить сложную распределенную сеть устройств в большом домохозяйстве где периферии может быть много и раскидано на приличные расстояния....
|
|
| |
pop | Дата: Среда, 28.02.2018, 10:28 | Сообщение # 125 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| Цитата AlexAW ( ) Читая вот тут https://ipc2u.ru/articles/prostye-resheniya/chto-takoe-mqtt/ Протокол MQTT работает на прикладном уровне поверх TCP/IPЯ понимаю что для его реализации надо создать физику сети типа проводной сети или радиоканала, потом организовать канальный уровень TCP/IP а уж потом прикручивать MQTT. Эт задачка для среднего семейсва МК напряжная. Тут надо переезжать на СИ и МК старшего семейства. Или садиться для более быстрого решения задач на ардуинки нано или те же ESP и пользовать кучу наработаных библиотек. Это короткий путь. Угу. Потому и зацепился за ESP. Физически вафлю даже в большом доме организовать не проблема - проводов не надо, канальный уровень в ней уже есть. LUA - прямо на блюдечке, портов - более чем для простенькой вещицы, и с расширением - для непростенькой. Цена - копеешная. Ну, ещё на STM32 можно посмотреть для "сложных" вещей, тоже с готовым TCP, или с шлюзом в вайфай на той же ESP. Шлюз с TCP на MODBUS - совсем не проблема. Вижу немного другую проблему, вытекающую из MQTT. Когда подписчик подписан на несколько топиков, то сообщения летят в одну кучу, без уточнения из какого топика. Но это, впринципе, можно обойти на уровне содержания сообщений. Т.е., от термометра посылать не "23", а что-то типа "я, такой-то, живу там-то, температура 23". Или организовывать отдельного "клиента" для подписки на каждый интересный топик. Первое проще обработать (меньше ресурсов), но больше информации гонять по сети.
Сообщение отредактировал pop - Среда, 28.02.2018, 15:54 |
|
| |
AlexAW | Дата: Среда, 28.02.2018, 12:47 | Сообщение # 126 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| Вот тут про организацию адресной доставки кое что есть интересное....
|
|
| |
Zoolu | Дата: Среда, 28.02.2018, 14:46 | Сообщение # 127 |
Группа: Пользователи
Сообщений: 490
Статус: Offline
| Цитата AlexAW ( ) Тут надо переезжать на СИ и МК старшего семейства Пырился сегодня в исходники MQTT клиента на МК... Приличные объемы кода однако)))) Под AVR, ESP и STM32 есть готовые либы.
|
|
| |
pop | Дата: Среда, 28.02.2018, 15:51 | Сообщение # 128 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| Угу. Для ESP аж для Lua.
|
|
| |
bagotu | Дата: Четверг, 01.03.2018, 12:55 | Сообщение # 129 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| Вот тут уже многое придумано... wifi-iot
homes-smart
|
|
| |
pop | Дата: Пятница, 02.03.2018, 09:11 | Сообщение # 130 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| Цитата pop ( ) Вижу немного другую проблему, вытекающую из MQTT. Когда подписчик подписан на несколько топиков, то сообщения летят в одну кучу, без уточнения из какого топика. Вот тут я был неправ. Поразбирался поглубже. Топик тоже прилетает с сообщением.
Вот, что меня удивляет, так это то, что везде всегда пытаются навешать на одно устройство кучу разных датчиков и исполнительных механизмов, зачастую разнесённых по разным углам. Что на ардуине, что на малине, что на ESP. И даже, извините, радиомодуль уважаемого AlexAW пытается всё услышать и всем сразу управлять. Вот в этом, ИМХО, главная ошибка, когда мы говорим, что хотим делать "распределённо-централизованную систему" умного дома.
|
|
| |
T2M © 2024 | Сайт управляется системой uCoz |
| |
|