LINUX.ORG.RU

Протокол для простого девайса

 , , , ,


1

1

Есть девайс с простым GSM-модемом (настолько простым, что нет даже AT-команд на HTTP, только на TCP).
Есть сервер. На сервере крутится openresty (nginx+lua).
Задача — читать сенсоры с девайса, по команде из веб-интерфейса помигать светодиодом.
Как это разумнее всего сделать? Мне сейчас приходит в голову только очень простой метод: девайс постоянно совершает HTTP 1.0 запросы к серверу и отправляет данные с сенсоров. Сервер отвечает «OK». Если вдруг нужно помигать светодиодом, сервер отвечает не «OK», а «LED». На что в следующем запросе девайс отвечает, что успешно мигнул, на сервере флаг мигания светодиодом убирается и приходит обычное «OK».
Плохо придумал? Тупо? Нужно городить какие-нибудь веб-сокеты?

★★★★★

логичнее наоборот - девайс должен отвечать на команды и запросы сервера.

сервер ему к примеру «STATE» а тот в ответ показания/состояния. и с миганиями также.

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

Я понимаю, как на сервере входящие запросы обрабатывать — написал простой обработчик и готово.
Я понимаю, как на девайсе исходящие запросы делать: подключился к сети, получил IP, сделал DNS-запрос по хостнейму сервера, отправил самобытный HTTP POST или GET.
А вот как наоборот — этого я не понимаю.

CYB3R ★★★★★ ()

ИМХО, делать новый коннект на каждую команду - не правильно. Лучше держать непрерывный коннект с сервером с периодическими Keep Alive-пакетами (по GSM соединения рвуться, если долго ничего не передавать).

KivApple ★★★★★ ()

Пиши на вебсокетах. Удобно и отлично.

На тебе для затравки.

anonymous ()
Ответ на: комментарий от CYB3R

А вот как наоборот — этого я не понимаю.

это не повод делать такую странную вещь, когда некая железка по собственной инициативе спамит сервер постоянными запросами. А если потребуется читать показания другим процессом (да хоть при отладке)?

MKuznetsov ★★★★★ ()

TCP есть? Зачем все остальное? TCP, построчное общение, запрос-ответ.

t184256 ★★★★★ ()

Как это разумнее всего сделать?

Я не понимаю, тебе протокол какой-то нужен стандартный поверх TCP? Modbus — стандартный промышленный протокол как раз для таких целей: получить значения датчиков, чем-нибудь мигнуть. Тебе нужен Modbus TCP/IP (Modbus TCP)

Zubok ★★★★★ ()

Если девайс достаточно производительный (раз может быть http клиентом) - то лично я бы делал наоборот - WWW сервер опрашивает девайс (по необходимости) через cgi запросы, девайс отвечает и выполняет. Можно использовать fastcgi например (почитай http://habrahabr.ru/post/154187/ ). Или вообще реализовать на борту полноценный www-сервер используя libmicrohttpd или mongoose (civetweb)

sigurd ★★★★ ()
Ответ на: комментарий от TDrive

Веб сокеты — это интересно. Я потому и спрашиваю.

CYB3R ★★★★★ ()
Ответ на: комментарий от Zubok

Да Modbus TCP был изначальным вариантом, но потом я решил использовать nginx, так как ничего городить не нужно.

CYB3R ★★★★★ ()
Ответ на: комментарий от CYB3R

Для modbus тоже есть всякое готовое. Вот, например, библиотеки в Debian. Да и для микроконтроллеров уже есть готовые библиотеки.

$ aptitude search ~dmodbus
collectd-core             statistics collection and monitoring daemon (core system)
libmodbus-dev             development files for the Modbus protocol library
libmodbus5                library for the Modbus protocol
node-crc                  module for calculating Cyclic Redundancy Check (CRC)
python-pymodbus           full Modbus protocol implementation
Zubok ★★★★★ ()
Ответ на: комментарий от CYB3R

потом я решил использовать nginx, так как ничего городить не нужно.

Веб сокеты — это интересно

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

tailgunner ★★★★★ ()
Ответ на: комментарий от CYB3R

но потом я решил использовать nginx, так как ничего городить не нужно.

Насколько я понимаю, решение ты уже выбрал. То есть вопрос твой уже ориентирован на предопределенное решение, а ты хочешь, чтобы мы тут подбодрили чуть-чуть. Ведь что еще можно посоветовать тебе? :) Твое решение имеет смысл только тогда, когда ты делаешь сугубо для себя. Но если ты повышаешь свой уровень до специалиста, то уже не годится - надо думать об интеграции, надежности, стандартизации. Придешь ты со своим девайсом с датчиком куда-нибудь на производство, а там тебе: «И куда нам это втыкать?».

Zubok ★★★★★ ()
Ответ на: комментарий от tailgunner

А по-моему, ты хочешь получить удовольствие от разработки своего велосипеда.

Ну, я только ради этого всё и затеял.

CYB3R ★★★★★ ()
Ответ на: комментарий от Zubok

Насколько я понимаю, решение ты уже выбрал.

Да.

То есть вопрос твой уже ориентирован на предопределенное решение, а ты хочешь, чтобы мы тут подбодрили чуть-чуть.

Нет. Я хочу, чтобы тут сказали, что моё решение говно и посоветовали, как это сделать правильно.

CYB3R ★★★★★ ()
Ответ на: комментарий от CYB3R

Нет. Я хочу, чтобы тут сказали, что моё решение говно

Я понял. Нет, ну твое решение имеет право на жизнь. Все зависит от того, где, кем и как будет использоваться устройство.

и посоветовали, как это сделать правильно.

Альтернативы: MQTT или даже XMPP. В модном ныне напрвлении IoT (Internet of Things) эти протоколы вполне себе рассматриваются.

Zubok ★★★★★ ()
Ответ на: комментарий от CYB3R

А вообще, Modbus TCP — это промышленный стандарт, это надёжнее всего должно быть.

CYB3R ★★★★★ ()
Ответ на: комментарий от CYB3R

выше тебе намекнули про modbus. Наиболее правильный вариант.

Если так уж хочется http, то девайс ходит на сервер, который через websocket или long polling скармливает ему команды или получает состояние датчиков.

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

Dark_SavanT ★★★★★ ()

Бред какой то.

К девайсу можно подключиться по TCP и видеть там события и слать команды и получать результаты? Нужно сделать веб морду к этому «TCP»?

Это две сотни строк довольно простого кода на каком-нибудь node.js. Любому студенту будет интересно такое закодить.

redixin ★★★★ ()
Ответ на: комментарий от Dark_SavanT

Изначально я и хотел сделать Modbus и до сих пор от этой идеи до конца не отказался.
Открыть на сервере порт 502 — ничего сложного. Проблема в том, что на этот порт вешать.
Посоветуй примеры сервера и клиента что ли.

CYB3R ★★★★★ ()
Ответ на: комментарий от CYB3R

Но я думал, вебсокеты в IoT популярнее, чем XMPP.

ИМХО, о популярности IoT говорить рано. Каждый использует то, что ему нравится. Все, что мы используем в интернете, может быть использовано и тут: и WebSockets, и REST. Пока не попадешь в ситуацию, когда нужна интеграция, какие-то стандартные решения (именно это я имею в виду по «когда, где и кем»).

Zubok ★★★★★ ()
Ответ на: комментарий от CYB3R

Я брал libmodbus и пилил на сишечке две небольших софтины, одна выступает как slave, другая как master. Дальше обычный опрос мастером slave. Но есть момент, что modbus не позволяет slave говорить без обращения от master, прерывания не сделать.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

Но есть момент, что modbus не позволяет slave говорить без обращения от master, прерывания не сделать.

А и не нужно. В варианте, который я описал та же фигня.

Я брал libmodbus и пилил на сишечке две небольших софтины, одна выступает как slave, другая как master.

Можно код?

CYB3R ★★★★★ ()
Ответ на: комментарий от KivApple

Уточнение - можно воспользоваться нормальными корпоративными тарифами для телематики. Там рваться ничего не должно.

RiseOfDeath ★★★★ ()
Ответ на: комментарий от CYB3R

В исходниках libmodbus есть каталог tests - там примеры нескольких клиентов и серверов. Вот простейший сервер:


#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>

#include <modbus.h>

int main(void)
{
    int socket;
    modbus_t *ctx;
    modbus_mapping_t *mb_mapping;

    ctx = modbus_new_tcp("127.0.0.1", 1502);
    /* modbus_set_debug(ctx, TRUE); */

    mb_mapping = modbus_mapping_new(500, 500, 500, 500);
    if (mb_mapping == NULL) {
        fprintf(stderr, "Failed to allocate the mapping: %s\n", modbus_strerror(errno));
        modbus_free(ctx);
        return -1;
    }

    socket = modbus_tcp_listen(ctx, 1);
    modbus_tcp_accept(ctx, &socket);

    for (;;) {
        uint8_t query[MODBUS_TCP_MAX_ADU_LENGTH];
        int rc;

        rc = modbus_receive(ctx, query);
        if (rc != -1) {
            /* rc is the query size */
            modbus_reply(ctx, query, rc, mb_mapping);
        } else {
            /* Connection closed by the client or error */
            break;
        }
    }

    printf("Quit the loop: %s\n", modbus_strerror(errno));

    modbus_mapping_free(mb_mapping);
    modbus_close(ctx);
    modbus_free(ctx);

    return 0;
}

sigurd ★★★★ ()
Ответ на: комментарий от CYB3R

я думал, вебсокеты в IoT популярнее, чем XMPP.

Первое, с чем ассоциируются IoT сегодня — это MQTT. Второе — обычные HTTP-запросы. Про XMPP в IoT ни разу не слышал :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от TDrive

веб сокеты

девайс умеет только TCP

Шикарный совет! Да, использовать сокеты поверх http поверх сокетов — это просто генитально.

derlafff ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.