Какой протокол связи в реальном времени между оборудованием и веб-компонентами?

Question

Я не совсем знал, как сформулировать свой вопрос в заголовке, поэтому извиняюсь, если это сбивает с толку.

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

У меня есть хорошее представление о том, что я собираюсь сделать для аппаратного обеспечения, а также для отображения информации; Мой вопрос касается связи между оборудованием и веб-сервером.

Я бы хотел, чтобы аппаратные средства генерировали сообщения с довольно высокой скоростью, поэтому я не думаю, что HTTP POST будет достаточно. Я также не очень обеспокоен получением 100% сообщений, но получение как можно большего количества, безусловно, является плюсом. Данные будут поступать с оборудования, заполняя какую-то базу данных (вероятно, Redis).

Пока что я исследовал несколько вещей, но не уверен, что движусь в правильном направлении. Я посмотрел на промежуточное программное обеспечение, ориентированное на сообщения, такое как RabbitMQ , но не уверен, что мне нужны служебные данные. Я также изучил Redis Pub / Sub , который представляется мне более подходящим решением, поскольку я хотел бы, чтобы веб-приложение отображало данные за последние 5 минут, но даже тогда я не уверен. Могу ли я просто запустить UDP-пакеты для специально созданного слушателя?

Я почти уверен, что аппаратное обеспечение будет состоять из двух этапов (ОК, питающий небольшой встроенный Linux-компьютер), так что вы можете даже сравнить его с программным обеспечением для настольных компьютеров, запускающим сообщения на веб-сервере как можно быстрее.

Я углубляюсь в область, о которой я абсолютно ничего не знаю, поэтому любое руководство очень ценится.

Answer 1

Для связи между вашими сборщиками данных и сборщиками, вы можете рассмотреть стандартный протокол Modbus TCP .(В прошлой жизни я писал сетевой код для программируемых контроллеров.)

Я уверен, что для большинства микроконтроллеров есть библиотеки, хотя они могут быть не с открытым исходным кодом, , но я сомневаюсь в JSсуществует версия Modbus, поэтому вам нужно написать саму библиотеку на стороне сервера.Насколько я помню, Modbus не особенно сложен, особенно если вы не используете некоторые его более эзотерические функции. Конечно, написание этого заставило меня задуматься, как бы я написал такую ​​вещь, и о чудо, это уже сделано для nodejs !(Одна из многих причин, по которым я люблю сообщество nodejs!)

Так что это простой ответ ... теперь, когда моя хакерская шляпа прочно установлена ​​...

Вы упоминаете, что вашHW будет кормить один или несколько «небольших встроенных Linux-машин».

Рассматривали ли вы запуск nodejs на каждом сборщике данных?Если размер исполняемого файла nodejs является проблемой, я уверен, что есть большие части его готовых функциональных возможностей, которые могут быть удалены или перемещены в модули.

Я понимаю, что яРекомендовать - это не маленькая задача - перенести приложение, размер и сложность nodejs / V8 на новую платформу, безусловно, сложно - но я сильно подозреваю, что управляемый событиями дизайн nodejs был бы отличным выбором для сбора данных, дискретного производства,управление процессом и другие производственные приложения.

Answer 2

Как и у другого упомянутого автора, у вас не возникнет проблем с постом http. Реализация http узла создана для обеспечения высокого параллелизма.

Лично я думаю, что я бы пошел с:

1. Вывод аппаратного устройства ->
2. Linux box запускает http сообщение прямо на ваш центральный сервер (node.js) ->
3. Примите ваши изменения и немедленно опубликуйте их в веб-клиенте через socket.io (транспорт для браузера в режиме реального времени). https://github.com/LearnBoost/Socket.IO/

Socket.io, вероятно, является лучшим из готового транспорта в реальном времени для node.js <==> браузера

Если вам нужна постоянность, redis неплох (если вы получаете бесплатный паб / саб), если ваши данные соответствуют этой модели, что, вероятно, и делает.

Нет причин, по которым вы не могли бы также использовать Reglar TCP-соединение (сетевой модуль), если это ваша сумка. Если вы не хотите, чтобы данные были ненадежными, я бы не пошел на UDP. Это больше ориентировано на потоковые медиа с потерями.

Я действительно сомневаюсь, что у вас будет достаточно сообщений, чтобы беспокоиться о выделенной очереди сообщений. Rabbitmq представляет такие функции, как постоянство очереди и построен для невероятно высокой пропускной способности. Вероятно, на порядки больше, чем вы ищете.

Вы можете посмотреть на библиотеку, подобную zeromq, для которой есть привязки узлов: https://github.com/JustinTulloss/zeromq.node. Это похоже на тему / другой тип обмена в rabbitmq, но без центрального узла очереди сообщений (один вызывает это без посредников). Таким образом, вы можете просто общаться напрямую с вашими Linux / аппаратными узлами, но при этом получать очередь сообщений, подобную интерфейсу - вы публикуете свои аппаратные обновления на «канале», и узлы вашего сервера прослушивают такие обновления.

Answer 3

Что не так с http постом? Если вы используете node.js в качестве веб-сервера, он должен быть достаточно быстрым. Вы уже кодируете слой представления в узле, так что вам придется использовать его на один инструмент меньше, и в этом случае он идеально подходит. Сохраняйте это простым и придерживайтесь узла.