2016-02-11 6 views
1

У меня есть подключенное к Интернету устройство IoT (скажем, встроенный датчик погоды, подключенный к Интернету, который может отправлять данные датчиков и выполнять некоторые расширенные операции, такие как вращение, включение , открытие клапанов/и несколько других операций).Для устройства IoT с питанием от стены, каковы наилучшие способы чтения данных и отправки команд

EDIT:

Устройства стена питание (электрическая розетка), и имеет мобильного интернет соединение стандартного подключения проводной Ethernet (просто подключите кабель Cat5)

мне нужно, чтобы иметь возможность получить информацию о состоянии (приблизительно 500bytes данных) устройств, и хочет, чтобы иметь возможность отправлять простых команд как:

  • rotate-180-deg
  • turn-lights-on
  • turn-lights-off
  • open-valve-1
  • switch-sensor-X-on
  • switch-sensor-X-off

В настоящее время мое устройство посылает запрос HTTP каждый (2мин) на мой центральный сервер с его статус. Это отлично работает для получения показаний датчиков устройств. Однако этот подход становится более проблематичным, когда я хочу отправлять команды на устройства. Например. если я хочу отправить команду rotate-180-degrees, мой центральный сервер должен дождаться, пока с ним свяжется устройство, и в ответе для HTTP-запроса - я могу поместить некоторую команду, поэтому, когда устройство получит ответ, оно фактически выполнит команду ,

Однако такой подход имеет недостатки:

  • это не в реальное время (я должен ждать в течение 2-3 минут, прежде чем у меня есть шанс, чтобы послать команду)
  • я не знаю, является ли команда была получена устройством или нет (например, в случае ошибки сети)
  • я не знаю, имеет ли данное устройство признано или выполнив команду (ни статус)

Что может быть решение для этой проблемы?

UPDATE: Как предложено @mhopeng, наиболее гибкое решение, похоже, превращает устройство в «сервер», чтобы оно могло принимать входящие соединения. Однако, поскольку соображения безопасности, брандмауэров и сложности мы не можем идти таким образом. Также устройство должно быть прост в установке: средства стороннего обслуживания должны иметь возможность просто подключать устройство к стене и ethernet, и он должен работать. (Нет необходимости настраивать переадресацию портов, межсетевые экраны и т. Д.).

FYI Мы также используем микроконтроллеры PIC в этом устройстве.

+0

Кажется, что вы хотите, чтобы на вашем устройстве был сервер, ожидающий входящих команд. Выберите свой протокол (возможно, HTTP, поскольку вы его уже используете), а затем реализуйте сервер. – mhopeng

+0

@mhopeng благодарит вас за идею, но я подумал, что превращение устройства в сервер (в отличие от пассивного клиента) увеличит сложность: что, если устройство находится за брандмауэром и не имеет открытого IP-адреса для подключения. В этом случае уровень безопасности будет намного сложнее. Также он открывает новый вектор атак (например, наводнение и т. Д.). Поэтому, хотя превращение устройства в сервер представляется наиболее гибким, он кажется сложным для нашего простого устройства и среды. Любые новые идеи оценены! –

+0

Вы можете рассмотреть легкий протокол обмена сообщениями, например [MQTT] (http://pubsubclient.knolleary.net) или [zeroMQ] (http://stackoverflow.com/questions/8867881/is-it-possible-to-run- ZeroMQ-на-ан-Arduino). Конечно, «это просто работает, когда я подключаю его», это непростая задача, независимо от протокола ... – mhopeng

ответ

1

This article содержит три варианта отправки данных с сервера на устройство.

Из вашего описания, это звучит, как вы используете короткий опрос:

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

В статье затем переходит к описанию вариант 2, длинный опрос:

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

И, наконец, детали вариант 3, использует другой протокол:

Третий вариант состоит в использовании более новые протоколы, такие как COAP или MQTT, например, которые были разработаны, чтобы обеспечить малое время задержки , небольшие размеры пакетов и стабильную связь по слабым сетям. Эти новые протоколы обеспечивают двухсторонний канал связи, который, в свою очередь, поддерживает push-уведомления. Это делает их хорошим выбором для проектов IoT, требующих возможности управлять подключенными устройствами в режиме реального времени. Единственным недостатком может быть отсутствие библиотек прошивки и примеров для встроенных устройств, которые значительно более распространены для HTTP-подключений. Выбор правильного протокола будет зависеть от вашего приложения и от того, как часто вам нужно будет общаться с устройством.

+1

спасибо! В конце концов мы пошли на MQTT. :) –