Genéricos MQTT Background

Com o MQTT o remetente e o receptor não se conhecem um ao outro - o corretor trata das mensagens. Isto permite que as mensagens sejam separadas no espaço, tempo e intensidade. O remetente pode enviar à velocidade que quiser, e à hora que quiser. O receptor pode pegar as mensagens na velocidade que quiser, e na hora que quiser. O remetente e o receptor não têm de se conhecer e não têm de ter uma rota directa estabelecida entre eles (como seria o caso, por exemplo, de uma linha telefónica). O MQTT permite desenhar facilmente configurações de multicast - onde um remetente pode enviar para muitos receptores subscritos.

• Os clientes não sabem quem publicou a mensagem originalmente - a menos que esteja claro a partir do tópico (e possivelmente imposto ao corretor pelas ACLs), ou do conteúdo da mensagem (possivelmente assinado com HMAC)
• MQTT é projetado para comunicação de baixa potência e baixa latência (HMAC, etc. pode ser caro).
• Você não pode obter uma lista de todos os tópicos de um corretor. O corretor descarta mensagens (e tópicos) às quais ninguém está subscrito (possivelmente apenas se a bandeira de retenção não estiver definida).
• Você não sabe quem subscreveu um tópico (use ACLs para limitar subscrições de clientes não autorizados)

última vontade e testamento / manter vivo

Os clientes podem se conectar, publicar uma mensagem e desconectar, ou manter uma conexão persistente com o servidor. No caso de uma ligação persistente, será enviado o keep-alives. Se o cliente não enviar o keep-alives no prazo acordado durante a configuração da conexão, o servidor (corretor) pode enviar uma chamada mensagem de última vontade e testamento, que o cliente enviou durante o estabelecimento da conexão. Esta mensagem pode ser qualquer coisa e pode ser publicada para um único tópico por conexão. O corretor irá enviá-lo a todos os clientes subscritos neste tópico.

Se o cliente se desconecta graciosamente, a última vontade e testamento não serão publicados.

A manutenção da vida é especialmente útil para clientes móveis, onde a conexão pode quebrar (por exemplo, para uma rede ruim, túneis, etc.)

Veja também:

http://www.steves-internet-guide.com/checking-active-mqtt-client-connections/

http://www.steves-internet-guide.com/mqtt-last-will-example/

https://owntracks.org/booklet/tech/mqtt/

Identificação do cliente / Aquisição pelo cliente

Cada cliente que se liga a um corretor MQTT deve ter uma identificação de cliente única. Clientes que se conectam com o mesmo id de cliente matam a conexão anterior e assumem a nova. Se você tem dois clientes com o mesmo client id, isso pode levar a um ping-pong de conexões desconectadas.

Mensagens retidas

O último A mensagem retida para um tópico é salva e entregue a todos os novos assinantes deste tópico. Isto pode ser usado para comunicar o estado do dispositivo / configuração / etc.

Você define o estado retido como uma bandeira por mensagem.

As mensagens retidas podem ser usadas para muitas coisas interessantes, por exemplo, para facilitar a auto-descoberta (ver Sugestão 4 abaixo).

Qualidade de Serviço / QoS

Há três níveis de qualidade de serviço, que determinam o quanto de sobrecarga é encontrado durante o processamento de uma mensagem. Quanto maior o nível, mais custos indiretos.

• 0: sem qualquer garantia
• 1: a mensagem será enviada pelo menos uma vez (é possível duplicar)
• 2: a mensagem será enviada exactamente uma vez (não é possível duplicar)

A QoS pode ser definida por mensagem enviada ao corretor, e durante a subscrição. O menor dos dois valores será usado para a entrega real da mensagem.

Dê uma olhadela nisto para mais detalhes:

https://www.eclipse.org/paho/files/mqttdoc/MQTTClient/html/qos.html

Tópicos

Fatos sobre os tópicos

Os nomes dos tópicos são sensíveis a maiúsculas e minúsculas, e cordas UTF-8. É aconselhável limitar-se a caracteres ASCII imprimíveis para facilitar a depuração.

Os nomes dos tópicos devem consistir de pelo menos um caracter para serem válidos.

/

já é um nome temático

O $SYS tópico é para uso do corretor / estatísticas.

Você tem a opção de colocar a informação na estrutura do tópico, ou colocá-la na mensagem. Uma estrutura JSON para a mensagem ajudará o usuário a poder estendê-la com mais dados.

Considere que em cada chamada para o corretor, cada publicação do tópico será enviada juntamente com a carga útil do pacote MQTT - portanto, tente evitar comprimento desnecessário.

Considere o uso de wild cards

• # corresponde a tudo para uma profundidade de nível arbitrária a partir do nível actual (wildcard de vários níveis, só pode ser inserido no final)
• + corresponde a tudo ao nível actual (curinga de nível único)

Por exemplo, se você tiver vários sensores de temperatura, você poderia facilmente assinar mensagens para todos eles se você projetar sua árvore de tópicos corretamente.

Wild cards são apenas para subscrição, não estão autorizados a publicar.

Você pode se inscrever em todos os tópicos usando #

exceto o tópico $SYS. Utilize $SYS/# para subscrever todos os tópicos do $SYS

Possivelmente, a utilização da parte "função" antes do identificador do dispositivo permite-lhe subscrever mais facilmente determinados canais.

Por exemplo, se você definir seus caminhos como tele/room1/sensorname1 tele/room2/sensorname2 etc. e stat/room1/sensorname1 stat/room1/sensorname2 assinaturas são possíveis em:

tele/#

stat/#

Se você fizer o contrário, com sensor1/stat e sensor2/estágioetc., você pode usar

+/stat

para subscrever as estatísticas, mas não se igualará em profundidade arbitrária como no exemplo anterior. Ou seja, o caminho para o seu sensor deve consistir precisamente em um componente.

Desta forma, se você prefixar a ação, seus caminhos serão mais consistentes.

Veja por exemplo https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch/

Não faça

- Não use uma barra principal (por exemplo, /mytopics ) para iniciar sua árvore de tópicos - ela adiciona overhead, sem valor

- Não usar $SYS como tópico de partida, isto é reservado ao corretor

- Não utilize espaços no tópico

- Não utilizar caracteres não imprimíveis no tópico

- use um tópico MQTT para mensagens com diferentes significados - crie tópicos diferentes para eles

Sugestões / Fazer

- incorporar a identificação do cliente na árvore de tópicos

- criar tópicos específicos para endereçamento individual (por exemplo, de sensores), em vez de enviar todos os valores sobre um tópico - isto evitará o envio de mensagens aos destinatários que não precisam delas.

- tente manter os nomes dos tópicos curtos (pois eles serão enviados em cada publicação e mensagem)

- considerar que dados terão de ser enviados com que frequência

Por exemplo, considere separar metadados para o seu próprio tópico e publicá-los com uma bandeira de "retenção".

- separar os tópicos de comando/cmd e status para um dispositivo - desta forma será possível a comunicação bidirecional, e o dispositivo não terá que filtrar suas próprias mensagens.

- usar uma mensagem de última vontade & testamento para indicar uma desconexão inesperada do cliente

Considere multi-tenancy & Bridging

Você precisa apoiar vários clientes / organizações / aplicações independentes? Existe a possibilidade de utilizar, por exemplo com o VerneMQ, diferentes pontos de montagem. Outra alternativa é incluir multi-tenancy na sua árvore de tópicos (usando um prefixo apropriado no início da árvore de tópicos).

Eu prefiro a rota anterior, pois ela proporciona uma camada adicional de separação ACL - e menos oportunidade para "estragar as coisas".

Além disso, você pode querer juntar vários corretores MQTT, compartilhando parte de suas árvores temáticas (como definido por seus ACLs).

Veja este https://owntracks.org/booklet/guide/bridge/ para mais informações sobre pontes.

Considere a encriptação

O MQTT pode ser executado em redes criptografadas (por exemplo, através de websockets / TLS criptografados) ou através de canais não criptografados. Adicionalmente, você pode considerar criptografar e/ou assinar a carga útil dos seus dados.

Considerar a possibilidade de descoberta

Considere a criação de tópicos que ajudarão a descobrir os serviços e capacidades dos seus dispositivos, por exemplo, usando mensagens retidas.

Considere comentários sobre comandos

Quando você publica um comando, você não tem um canal de retorno imediato. Portanto, pode ser útil estabelecer uma hierarquia para feedback específico sobre comandos específicos - se o dispositivo recebeu e foi capaz de executar o comando, para ser capaz de fornecer feedback ao usuário.

Um padrão que eu estava pensando em aplicar aqui era dar ids de comando únicos como parte da carga útil da mensagem, que são referenciados no canal de feedback com um código de status.

Considere cenários multicast

Você quer que vários dispositivos reajam a uma única mensagem que você publica? Lembre-se, você não pode publicar tópicos wildcard - apenas inscreva-se neles. Neste caso, devem ser criados tópicos adicionais que permitam aos clientes reagir a cenários de multicast. Todos os clientes / todos os clientes de um determinado grupo subscreveriam o tópico multicast e reagiriam às mensagens.

Se você combinar isso com o meu feedback / referência ao comando id sugestão acima, um novo requisito de id de cliente como carga útil é introduzido no canal de feedback (genérico). Outra possibilidade é ter os dispositivos respondendo em seus canais de feedback individuais - onde o id do dispositivo já faz parte do caminho. (Ou seja, eles recebem um comando no caminho multicast, mas respondem em sua própria hierarquia exclusiva de tópicos de mensagens).

Considere o tráfego e a privacidade, Tipos de sensores

Se você estiver rodando um sistema comercial, por exemplo, coletando dados de sensores para usuários, eles podem querer ter um bom grau de controle sobre quais valores de sensores são publicados.

Além disso, a simples publicação automática de todas as leituras do sensor aumentará o tráfego e a carga no(s) seu(s) servidor(es).

Portanto, simplesmente empurrar todos os valores de sensor disponíveis para o seu corretor MQTT pode não ser a melhor escolha. Uma possibilidade é criar um tópico retido, com uma configuração que o cliente pode subscrever. Quando o cliente se conectar, ele receberá automaticamente a configuração no tópico retido, e pode ajustar os valores que publica de acordo com a configuração. Além disso, ele pode reagir a alterações de configuração reagindo a quaisquer mensagens adicionais que cheguem sobre este tópico de configuração.

Além disso, é importante considerar que existem diferentes tipos de sensores. Por exemplo, para um sensor de porta você estaria interessado em uma mudança de status (fechado vs. aberto), enquanto que com um sensor de temperatura, você pode querer receber leituras contínuas. É importante para o seu projeto considerar que tipo de valores os assinantes estarão recebendo quando o cliente responsável pelas leituras do sensor se desconecta. Lembre-se de que você pode definir um último testamento somente em um tópico (para dispositivos multi-sensores). No caso de uma desconexão, mensagens retidas podem dar uma impressão errada (por exemplo, da porta estar aberta enquanto está fechada na realidade, mas não ter sido actualizada, etc.).

Por outro lado, se, por exemplo, a sua interface web que controla o cliente estiver ligada apenas depois de o cliente-sensor de porta ter estado ligado durante algum tempo, e utilizar mensagens não retidas, a mensagem da última actualização do estado da porta será perdida;

Há aqui duas possibilidades:

• solicitar ativamente uma atualização do status da porta (por exemplo, usando seu próprio tópico get)
• usar mensagens retidas e usar a lógica do lado do cliente na interface web para descartar o último valor caso o próprio cliente não esteja conectado / marcá-lo como obsoleto

Em qualquer caso, o usuário deve ser informado se uma leitura de sensor pode ser confiável, ou se ela é possivelmente incorreta devido a um sensor-cliente desconectado.

Veja também http://www.steves-internet-guide.com/mqtt-sensors-traffic-observations/

• Steve observa que combinar dados de sensores de vários sensores em uma carga útil codificada JSON não diminui o tráfego, mas pode até mesmo aumentá-lo ligeiramente (em relação à carga útil não codificada!)

caminho tópico semântico vs. físico

coisas significativas para um humano criam a estrutura temática: ("abordagem semântica")

casa/banheiro/humidade

Os caminhos dos dispositivos (a que dispositivos estão ligados os sensores, como são endereçados?) criam a estrutura do tópico: ("abordagem física")

pi/00000234898324734/i2c/10/pressure

(os números que simbolizam a série BCM, e o endereço I2C, respectivamente).

republicação

Nesta idéia você combinaria as duas abordagens, e criaria um serviço adicional que se traduzisse entre os dois mundos.

Veja: https://tinkerman.cat/post/mqtt-topic-naming-convention

Visão geral das sugestões de design online

Sugestão 1: Raspberry-Valley

...de: https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/

dispositivo-categoria/dispositivo-id/payload-contexto/payload-diferenciador

• categoria de dispositivo: por exemplo "pi", "arduino", etc.
• dispositivo-id: por exemplo, BCM serial
• contexto de carga útil: por exemplo, temperatura
• diferenciador de carga útil: por exemplo, frente / trás (adicionando um nível de medição para um determinado contexto)

Note a simetria entre dispositivo-categoria/dispositivo-id e payload-context/payload-diferenciador (genérico-> específico; genérico -> específico)

Sugestão 2: Steve

(Por Steve): http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/

Você pode incluir os seguintes itens em sua árvore de tópicos:

• dispositivos de agrupamento de temas de alto nível
• nome do sensor atribuído
• função (por exemplo, set / status / get / cmd )

A abordagem do Steve:

• usar o nome do tópico para um dispositivo individual (por exemplo, um sensor)
• usar carga útil / dados JSON para atributos deste sensor
• usar tópico separado para dados e comandos

Sugestão 3: MQTT-Smarthome

MQTT Smarthome proposta

https://github.com/mqtt-smarthome/mqtt-smarthome

um caminho parecido com este nesta proposta:

nome da pessoa/função/item

knxgateway1/status/Kitchen/Lights/Front Left

• primeiro nível (knxgateway1) = toplevelname, sendo abordado o gateway de concreto
• para vários gateways semelhantes, este nome deve ser ajustável para evitar colisões no namespace
• segundo nível (status) = função
• terceiro nível, e outros níveis -> hierarquia de endereço individual da porta de entrada específica (item)

A parte interessante são as funções, e a sua posição antes de os caminhos mais profundos (considere os wild cards para assinatura - desta forma você pode assinar facilmente todos os relatórios de status do dispositivo!)

Funções disponíveis / definidas nesta proposta:

• status - para obter relatórios de status
• set - para solicitar mudanças de estado
• obter - (opcional) para solicitar ativamente uma atualização do estado (para gateways que o suportam)
• o resultado da leitura será publicado para o situação hierarquia.

As hierarquias subsequentes para os verbos individuais devem corresponder umas às outras, de modo que você estaria abordando o mesmo dispositivo / nó / parâmetro.

Há um tópico especial "conectado" por gateway, que permite ao cliente definir uma mensagem de última vontade & testamento

nome do povo/conectado

valores simples são definidos para este tópico:

• 0 = desconectado do corretor (definido como última vontade)
• 1 = conectado ao MQTT, desconectado do hardware
• 2 = ligado ao MQTT e ao hardware (totalmente operacional)

Note que o valor 0 não distingue entre desconexões voluntárias ou uma conexão perdida (onde o "keep-alives" é temporizado para fora).

Há também sugestões para a carga útil:

A codificação JSON da carga útil é opcional.

No caso da codificação do JSON, o valor estará sempre na chave "val". Adicionalmente,

ts : timestamp (timestamp, milissegundos desde a época)

lc : última mudança de valor (timestamp, milissegundos desde a época)

Sugestão 4: Homem Sininho

https://tinkerman.cat/post/mqtt-topic-naming-convention

considere se você quer uma abordagem "semântica" (por exemplo, coisas significativas para os humanos) ou uma abordagem "física" (por exemplo, caminhos reais do dispositivo no qual seu sistema está conectado).

A abordagem física é mais amigável à máquina.

(Por favor, note que o Tinkerman e o meu entendimento dos pontos de montagem e seus desvios de uso - para mim os pontos de montagem são árvores tópicos completamente segregados, por exemplo, para multi-tenancy)

Os metadados podem ser codificados como caminhos postfixos.

por exemplo

/home/quarto/teirão/temperatura -> 21

/home/quarto/teirão/temperatura/unidades -> °C

/home/bedroom/temperature/timestamp -> 2012-12-10T12:47:00+01:00

Nota: uma vez que as unidades e alguns outros metadados são improváveis de mudar, eles podem ser enviados como tópicos retidos.

Uma parte interessante desta sugestão é também a agregação (lado do dispositivo):

/home/quarto/cama/temperatura/último -> último valor de temperatura

/home/sala de cama/temperatura/longa/temperatura

/home/ dormitório/temperatura/longa 24h/max -> valor máximo nas últimas 24h

/home/quarto/teirão/temperatura/longa 24h/max/ carimbo da hora -> carimbo da hora em que a temperatura era tão alta

/home/quarto/teirão/temperatura/últimas24h/min

/home/ dormitório/temperatura/ever/max -> a temperatura absoluta mais alta já medida

Novamente, esses valores poderiam ser definidos como tópicos retidos (especificamente "sempre") para salvar o tráfego da rede - o sistema receptor poderia descartar valores retidos mais antigos (se o sensor for desconectado, como deve ser evidente por outro tópico - possivelmente definido pelo último testamento & vontade), ou o sistema poderia mostrá-los como valores "obsoletos".

Este é um design interessante (para a agregação), e poderia servir de inspiração para permitir este tipo de flexibilidade.

Sugestão 5: Convenção Homie IoT

https://homieiot.github.io/

Home IoT está focada na capacidade de descoberta de nós na configuração de Home Automation do IoT. Homie não usa mensagens codificadas JSON, ele usa uma representação direta da carga útil para cada nó. Veja este exemplo:

Homie define um subconjunto rígido de caracteres que você está autorizado a usar para nomear os seus nós, como caracteres especiais (por exemplo, $ e o sublinhado _) são usados para fins especiais.

Define tipos de dados, que são publicados como metadados (retidos) ("atributos") para $datype da propriedade individual (ver abaixo para definição de propriedade):

• Cordão
• Inteiro
• Flutuar
• Booleano
• Enum
• Cor

(note o uso do $ para marcar tópicos especiais).

O último testamento é usado para marcar o dispositivo como perdido:

homie/deviceID/$state -> perdido

Homie define 6 possíveis estados para o dispositivo:

• init -> o dispositivo ligou-se ao MQTT mas ainda não publicou todas as mensagens Homie necessárias
• ready -> o dispositivo está conectado e terminou a configuração - todas as mensagens necessárias foram enviadas
• desconectado -> o dispositivo desconectado de forma limpa
• Dormir -> auto-descritivo
• lost -> o dispositivo desligou-se inesperadamente (definido pela última vontade & testamento)
• alerta -> o dispositivo está conectado, mas algo está errado, precisa de intervenção humana

Homie recomenda a utilização de QoS 1 (como a natureza do Homie o torna seguro para mensagens duplicadas).

Uma provisão para extensões é feito usando uma sintaxe de nome de domínio inversa, por exemplo org.mycompany.homie-extension

nodos e dispositivos

Em Homie-parlance, um dispositivo é a unidade básica de hardware. Por exemplo, uma Raspberry Pi, uma máquina de café, um carro.

A nodo é uma unidade lógica e independente do dispositivo. Por exemplo, um carro pode ter um nó de rodas, um nó de motor e um nó de luzes.

imóveis representam características básicas do nó/dispositivo. Um carro, por exemplo, poderia ter uma propriedade "velocidade" e uma "temperatura" para o nó do motor. As propriedades podem ser mantidas e/ou ajustáveis.

• retido + não regulável: por exemplo, sensor de temperatura
• retido + ajustável: o nó pode publicar uma propriedade e receber comandos para a propriedade (por exemplo, potência da lâmpada)
• não retido + não regulável: por exemplo, uma campainha de porta (eventos momentâneos)
• não retido + regulável: o nó pode receber comandos para a propriedade, por exemplo, café da cerveja

atributos:

os atributos são importantes para a auto-descoberta de Homie, são especificados e iniciados com um $ para indicar o seu significado particular / evitar colisões. Eles são usados para armazenar e atualizar metadados.

Por exemplo, o dispositivo publica uma mensagem retida em

homie/dispositivo ID/$nodes

com uma lista separada por vírgulas dos nós. Para indicar que um nó é uma matriz (pode ser usado para agrupar, por exemplo, luzes dianteiras e traseiras em um carro), o nome é especificado com colchetes retangulares no final, por exemplo

luzes[]

Um exemplo para a sub-árvore de identificação do dispositivo:

Homie especifica diferentes estatísticas para o dispositivo fora da caixa, a maioria delas opcional (exceto o tempo de atividade). Por exemplo:

Com nós, novamente a auto-descoberta é possível para as propriedades, especificando-as no atributo $properties:

Desta forma você, como assinante, não tem de adivinhar / subscrever todos os eventos - pode subscrever selectivamente os que lhe interessam.

Em Homie, os metadados (atributos) são publicados como um sufixo para o caminho. Por exemplo, para uma determinada propriedade:

Controle em Homie

O Homie é estatal. Isto significa que não se "acende a luz", mas sim que se liga o estado de energia de um dispositivo.

então o dispositivo atualiza seu estado de energia para comunicar que o comando foi executado:

Transmissão

alerta é uma escolha arbitrária - a transmissão pode ser para qualquer outro tópico, para o qual os dispositivos podem filtrar. As mensagens são transmitidas a todos os dispositivos - os dispositivos podem reagir se assim o desejarem.

Esta é a especificação mais completa que consegui encontrar na minha pesquisa online. Pessoalmente, sinto que é muito elegantemente concebida.

Leia mais:

https://homieiot.github.io/specification/

Sugestão 6: Owntracks

https://owntracks.org/booklet/tech/json/

http://owntracks.org/booklet/guide/topics/

Owntracks é um aplicativo Open Source, para permitir que você rastreie sua própria localização física, para compartilhar com amigos, etc. A localização é publicada via HTTP ou MQTT, idealmente para o seu próprio corretor.

” Ele também pode detectar quando você entra ou sai de uma determinada região para a qual você define um chamado waypoint. As pessoas usam isto, digamos, para controlar algum aspecto do seu sistema de automatização de casa. (Todos saíram de casa? Podemos apagar as luzes)".

Se você quiser ler mais sobre OwnTracks, acesse este site: https://owntracks.org/booklet/

Sobre o desenho do tópico owntracks:

https://owntracks.org/booklet/guide/topics/

"Os princípios durante a concepção do esquema de nomes de tópicos OwnTracks foram

• legibilidade humana
• minimização de tráfego
• controle de acesso granular

“

Nome do tópico base (outros são possíveis):

owntracks/peter/iPhone

aqui owntracks é um prefixo, para permitir outras aplicações sem colisões no corretor MQTT.

peter é o proprietário dos dispositivos de rastreamento, e o iPhone é um dos seus dispositivos.

Os comandos para dispositivos são enviados para: owntracks/peter/iPhone/cmd

a saída dos comandos é publicada, por exemplo, para nomes de tópicos relativos etapa, lixão etc.

alguns outros tópicos são definidos (info, waypoint, evento). Os eventos são publicados, por exemplo, quando um usuário entra em uma área definida.

Desta forma, a subscrição de owntracks/+/+/event permitirá ver (para os utilizadores autorizados a ver) quando eles entram ou saem de uma área definida.

Owntracks publica as suas mensagens no formato JSON:

https://owntracks.org/booklet/tech/json/

como você pode ver as funções são depois de o dispositivo.

Como existe uma "profundidade" fixa para o utilizador/dispositivo conhecida antecipadamente, a subscrição de múltiplos utilizadores e dispositivos pode ser feita utilizando wildcards:

No JSON, o tipo do JSON em particular é transmitida na mensagem:

Esta é uma boa ideia! Desta forma, você pode verificar se a sua inscrição entende o evento corretamente, pode fazer verificações de tipo, etc.

Os elementos individuais são especificados de forma não-verbal. Isto ajuda a poupar tráfego, especialmente para mensagens que serão publicadas com frequência.

por exemplo..:

• acc: precisão da localização relatada em metros (sem unidade)

muitos dos elementos são opcionais.

Curiosamente, o tipo de localização é definido para diferentes dispositivos, que suportam diferentes elementos.

Uma simples última vontade e mensagem de testamento é publicada. Ela simplesmente inclui um carimbo de data/hora, no qual o dispositivo se conectou pela primeira vez.

é um carimbo da época Unix.

Um aspecto interessante sobre este tipo de evento / tipo de carga útil é que são especificados vários timestamps:

• wtst: Timestamp da criação do waypoint
• tst: Carimbo da hora em que o evento ocorreu.

Um ponto de passagem é um ponto de interesse, por exemplo, a sua garagem - se você entrar ou sair da sua garagem, um evento de transição será desencadeado:

• evento: (enter|leave)

Um evento de configuração. Se ativado, os aplicativos também aceitam mensagens de configuração remota.

Este evento inclui muitos elementos possíveis, que são mais verbosos (por exemplo, validatecertificatechain) - isto é sensato, já que a configuração pode ser armazenada como JSON (! -> isto pode ser passado como mensagem MQTT e armazenado!), e também como não é enviado frequentemente, a verbosidade não é um grande problema, mas sim uma vantagem para os usuários.

por exemplo, uma ação com a "ação": "dump" desencadeará uma publicação da mensagem de configuração para o caminho relativo dump

podem ser dados subparâmetros opcionais para uma acção, por exemplo, para um período de tempo a ser analisado:

Outra idéia interessante de design é que por uma certa variação desta mensagem cmd um navegador pode ser aberto para um determinado URL. Por exemplo, se você entrar na garagem, um site de controle de garagem poderia ser aberto, ...

um gama de um tipo de mensagem diferente pode / deve ser passado como um parâmetro aqui.

A parte interessante desta mensagem é que ela também tem um campo para uma imagem PNG codificada Base64:

a ideia interessante aqui é que um opcional _criador item pode ser passado adiante, o que identifica a entidade que criou esses waypoints.

Note também, que owntracks usa o underscore _ para parâmetros "especiais".

Opcionalmente, todas estas mensagens podem ser criptografado para transporte com uma chave simétrica partilhada.

A carga criptografada (a mensagem original) estará no elemento "dados", Base64 codificado.

Mensagens

A carga útil das mensagens é binária e pode ser qualquer coisa, não há nenhuma exigência de que as mensagens sejam válidas UTF-8.

Portanto, você também pode publicar dados digitais, por exemplo, imagens, como carga útil em determinados tópicos.

Muitos dos actuais painéis IoT tomam os dados codificados como JSON.

Geralmente parece haver duas escolas de pensamento: onde as mensagens são na verdade valores brutos, e metadados são codificados na árvore de tópicos, e valores codificados pelo JSON que carregam metadados como a carga útil.

sugestões

• Utilizar o formato JSON para a carga útil das mensagens
• agrupar atributos em mensagens, em vez de criar tópicos individuais para elas
• incluir:
• dados de carga
• sensor / identificação do dispositivo (se não fizer parte da árvore temática)
• função
• carimbo da hora

Recursos interessantes

Awesome MQTT: Colecção de links relacionados com o MQTT:

• https://github.com/hobbyquaker/awesome-mqtt

projectos individuais:

twitter-to-mqtt - Um daemon python que usa a API do Twitter Streaming para acessar tweets e republicá-los para um tópico do MQTT.

• https://github.com/knolleary/twitter-to-mqtt

fritz2mqtt - Ligue o FRITZ!Box ao MQTT.

• https://github.com/akentner/fritz2mqtt

Ref:

• https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/
• https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/
• https://homieiot.github.io/
• https://github.com/homieiot/convention
• https://github.com/mqtt-smarthome/mqtt-smarthome
• http://www.steves-internet-guide.com/mqtt/
• http://www.steves-internet-guide.com/understanding-mqtt-topics/
• http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/
• https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch
• https://tinkerman.cat/post/mqtt-topic-naming-convention
• https://github.com/mqtt-smarthome/mqtt-smarthome/blob/master/howtos/homematic.md (mostrando o fluxo com o Nó VERMELHO)
• https://owntracks.org/booklet/tech/json/

A republicar:

• https://lodge.glasgownet.com/2012/09/23/mqtt-republishing-itch/
• https://github.com/kylegordon/mqtt-republisher

Sinal K para uso marítimo (como possível inspiração para o formato JSON):

• http://signalk.org/specification/1.3.0/doc/signalk.pdf