Суббота, 23.11.2024, 21:44
| RSS
Главная | Web интерфейс,JS и все что с ними связано. - Страница 13 - Форум
Защита, контроль, управление
Форма входа
[ Новые сообщения · Участники · Правила форума · Поиск · RSS · Чат

Наш канал в YouTube
]
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