Escolha do protocolo para comunicação Machine-to-Machine - nível: n00b

Question

Estou construindo um sistema de monitoramento para uma bomba de irrigação e a tubulação conectada. Até agora eu completei a rede de sensores. Tudo se conecta a uma placa micro-controladora (na verdade, 4 placas Teensy 3.0 ) e a placa é programada para produzir uma seqüência de dados formatados (as leituras) em intervalos predeterminados.

O que eu quero fazer é conectar a placa via USB-serial a uma RaspberryPI (ou alguma outra SBC) e ter o computador envia as leituras que recebe da placa do sensor para um servidor remoto para registro.

As opções que eu considerei são:

1 - Syslog ... Pareceu-me no início como uma possibilidade, porque parece oferecer praticamente tudo que eu preciso. A complexidade me assusta embora.

2 - REST ... Peça ao RaspberryPI POST os dados, linha por linha, pela rede para o CouchDB no servidor.

3 - HTTP ... Mantenha uma conexão HTTP aberta com node.js e "escreva" as linhas de dados. Obviamente, ele precisará ser recebido por um segundo script node.js para armazenar no banco de dados.

Agora, para os requisitos:

~ Precisa ser leve e relativamente rápido. Haverá muitos dados (intervalos de 1s) e o RaspberryPI não é uma potência.

~ Eu gostaria muito da opção por uma string compactada. O uplink é via 3G e eu espero ir com um plano mensal "pequeno".

~ A criptografia será boa, mas não obrigatória. A paranóia é strong com os rednecks ...

~ Eu realmente preciso que isso seja como K.I.S.S. quanto possível.

Para encurtar a história, eu penso nisso como um tipo de conexão serial over-the-net, onde um computador alimenta linha após linha para outro computador.

Então, qual das opções que eu tenho aqui é preferível? Ou melhor ainda, alguém tem uma ideia melhor?

Estou sinceramente aberto a editar e até repostar a pergunta se alguém tiver um bom ponto para fazer.

EDITAR:

Todos os comentários e respostas até agora foram apreciados e considerados.

O syslog é realmente ótimo, mas eu realmente preciso evitar a complexidade e a sobrecarga. Além disso, após alguns testes, o RaspberryPI parece ficar paralisado logo após iniciar o rsyslog.

Até agora, foi decidido que o SGBD será o CouchDB.

A opção óbvia seria usar curl ou um servidor vest.jial node.js para fazer as chamadas REST para o servidor de banco de dados imediatamente assim que os dados chegassem. Isto, apesar de simples e eficaz, é por uma série de razões não preferíveis. A segurança também é uma preocupação; Eu não gosto da idéia de um PC em miniatura em um campo fazendo chamadas diretas para o SGBD.

O motivo pelo qual estou iniciando uma recompensa é que espero que alguém possa sugerir uma idéia nas seguintes linhas: "Algum tipo de conexão persistente entre o PC miniatura em miniatura e o DBMS. Os dados serão formatados por algum tipo de protocolo e encaminhados através desta conexão, a fim de ser recebido no extremo oposto. Esta conexão deve ser o mais leve possível, com a menor quantidade possível de overhead ".

    

Answer 1

Já pensou em usar o SMTP (email)? O Raspberry tem dois processos: um lê os dados e os anexa a um arquivo, outro (possivelmente no crontab) move os arquivos (possivelmente agregando alguns) e os envia por email para o computador de destino. Dessa forma, você não tem nenhum acoplamento entre a frequência de amostragem e a frequência de registro, se estiver tudo bem com você (enviando um e-mail a cada 20 ou a cada minuto, por exemplo).

O email pode ser compactado, criptografado (usando SMTP TLS). Além disso, é resiliente: no caso de você perder seu uplink, os dados serão enviados quando o link for restaurado. Do ponto de vista do seu processo de registro, o link está sempre "ativo".

No seu servidor couchdb (ou em outra máquina conectada ao couchdb), você cria um usuário dedicado e coloca um script em seu .forward que descompacta a mensagem e a alimenta para couchdb.

Se você quiser autenticar, você pode ir com muitos esquemas de um segredo compartilhado para a assinatura do PGP!

Fazemos isso para alimentar nosso data warehouse, porque não queremos qualquer tipo de conexão de entrada (https ou ssh), reconhecidamente não a uma taxa de amostragem de 1s (mas com dados maiores).

Por último, mas não menos importante, você pode testar cada componente individualmente (logger, remetente, receptor e db-feeder) sem precisar de toda a infraestrutura em execução.

    

Answer 2

Geralmente, tudo depende do que você faz do outro lado. Por exemplo: se você precisar que esses dados sejam encaminhados para o Zabbix - você usa o agente Zabbix, para o SNMP - você usa o snmpd, para o processamento de aplicativos da Web - HTTP etc.

O Rsyslog pode ser uma boa opção para o transporte, porque ele já pode resolver muitos problemas que você pode encontrar ao desenvolver uma solução personalizada (ou seja, ao trabalhar com REST, HTTP genérico):

1. É confiável com o RELP
2. Possui a opção de enfileiramento no disco, para que você possa entregar mensagens depois que a conexão for restabelecida
3. Suporta compactação de mensagem gzip
4. Suporta TLS
5. Suporta vários módulos de entrada
6. E módulos de saída
7. Filtragem e modificação nos dois lados

O TLS terá uma sobrecarga enorme - tente não usá-lo.

Você precisará configurar o mesmo sistema do outro lado, então você pode fazer truques com mensagens como você quer, ou seja, inseri-lo no mysql ou / e banco de dados postgresql , ou / e qualquer outro com DBI ou / e encaminhar para arquivo , ou / e para o canal nomeado , ou / e como snmp trap ou / e como e-mail e / ou para aplicativo personalizado etc.

Estou usando um sistema semelhante ao que você tem (Arduino + Raspberry), mas estou executando um aplicativo proprietário com sua fila específica e transporte SOAP. Para mensagens simples, acho que usaria o rsyslog.

    

Answer 3

Você também pode procurar em RabbitMQ Desde que é um corretor de mensagens, o que é meio que projetado para esse problema.

RabbitMQ is a message broker. The principal idea is pretty simple: it accepts and forwards messages. You can think about it as a post office: when you send mail to the post box you're pretty sure that Mr. Postman will eventually deliver the mail to your recipient. Using this metaphor RabbitMQ is a post box, a post office and a postman.

The major difference between RabbitMQ and the post office is the fact that it doesn't deal with paper, instead it accepts, stores and forwards binary blobs of data ‒ messages.

Aqui há um post descrevendo como usá-lo em um Rpi.