A dojot é uma plataforma brasileira desenvolvida principalmente pelo CPqD e que surgiu com uma proposta open source, visando facilitar o desenvolvimento de soluções e subsidiar o ecossistema IoT com conteúdo local voltado às necessidades do País.
O código dos componentes que compõem a solução está disponível no repositório do Github. Descritivos detalhados da arquitetura, do funcionamento dos componentes e alguns casos de uso podem ser encontrados na documentação.
Introdução
Nos artigos anteriores, foram abordados os passos iniciais para inicializar a plataforma dojot e enviar informações a partir de um dispositivo que realiza o sensoriamento de temperatura.
Contudo, capturar e salvar as medições enviadas pelos sensores é só parte do arranjo. Para que ações possam ser tomadas, é necessário que estes dados sejam analisados de acordo com as regras de negócio específicas da aplicação.
Os Melhores Treinamentos sobre Sistemas embarcados e IoT
Cursos com professores qualificados para acelerar sua carreira e projetos
Para alcançar esse objetivo, este artigo abordará a utilização do sistema de fluxos da dojot. Esse sistema é baseado em eventos: quando um dispositivo envia um ou mais dados de medição, os fluxos vinculados ao mesmo são executados.
Atualizando a modelagem
Partindo do exemplo de monitoramento de temperatura, serão inseridos dois novos componentes: um sinalizador para indicar temperatura alta e outro para temperatura baixa.
O novo arranjo da modelagem segue o seguinte layout:
Partindo da mesma metodologia de modelagem apresentado anteriormente, será criado um modelo (template) que caracterize este tipo de sinalizador: atributo de valor dinâmico denominado ativo, do tipo booleano, indicando o status do sinalizador.
Em seguida, os dois componentes baseados neste modelo são criados e nomeados de forma a facilitar a diferenciação.
Com isso, é possível criar um fluxo onde:
(1) caso a temperatura atinja um valor acima de um valor predeterminado, o sinalizador de temperatura alta será ativado – e desativado, caso contrário.
(2) de forma análoga, o sinalizador de temperatura baixa será ativado quando a temperatura medida estiver abaixo de um limiar predeterminado – e desativado, caso contrário.
Criando um novo fluxo
No menu lateral, a opção Data Flow leva o usuário à seção de criação de fluxos customizados para a aplicação.
A imagem a seguir ilustra a modelagem do fluxo descrito anteriormente. As partes utilizadas serão explicadas em mais detalhes.
Cada fluxo tem, em geral, três etapas:
- obtenção da leitura dos sinais do dispositivo ao qual o fluxo é relacionado;
- avaliação dos valores frente às regras de negócio;
- tomada de ação de acordo com o resultado da análise total do fluxo.
Baseando-se nesta divisão, o cenário do exemplo abordado pode ser visto como:
- leitura do valor da temperatura no escritório;
- verificação se a temperatura está acima ou abaixo dos limiares configurados;
- acionamento dos sinalizadores de temperatura alta ou baixa.
 | Dispositivo de entrada |
 | |
|
(A) Name: nome de exibição do bloco no diagrama. No caso do exemplo, é nomeado com o nome do próprio dispositivo: o sensor de temperatura do escritório. (B) Device: identifica qual dispositivo será monitorado para acionar o fluxo. (C) Status: define se as mudanças de estado (online/offline) serão considerados ou não para ativação do fluxo. |
 | Tomada de decisão |
 | |
|
(A) Name: nome de exibição do bloco no diagrama. No exemplo, é nomeado com a função do bloco: controlar os casos de temperatura alta. (B) Property: define qual propriedade será utilizada na comparação. Neste caso, se espera comparar o atributo “temperatura” enviado no payload do dispositivo. (C) Lista de comparações: define as regras checadas para acionar a saída. A cada regra adicionada, também é acrescido o número de saídas deste bloco. No exemplo, existem duas regras – e é possível ver, no diagrama completo, a presença de duas saídas. (D) Critério de comparação: define se todas as regras serão verificadas ou se o bloco acionará apenas a primeira que for válida. |
 | Atribuição de valor | ||
| |||
|
(A) Name: nome de exibição do bloco no diagrama. No exemplo, é nomeado baseado na ação que o bloco executa: acionar o sinalizador. (B) Lista de atribuições: define os valores que serão atribuídos às variáveis de saída. Neste caso, valor true foi atribuído à saída payload.ativo, visando ativar o sinalizador. | ||
|
(A) Name: nome de exibição do bloco no diagrama. No exemplo, é nomeado baseado na ação que o bloco executa: acionar o sinalizador. (B) Lista de atribuições: define os valores que serão atribuídos às variáveis de saída. Neste caso, valor true foi atribuído à saída payload.ativo, visando ativar o sinalizador. | |||
 | Dispositivo de saída |
 | |
|
(A) Name: nome de exibição do bloco no diagrama. No caso do exemplo, é nomeado com o nome do próprio dispositivo: o alerta de temperatura alta. (B) Device: identifica a qual dispositivo o sinal de entrada será enviado. Neste caso, foi escolhida a opção de selecionar um dispositivo específico. Também é possível escolher o dispositivo que ativou o fluxo ou mesmo um criado durante o fluxo. (C) Nome do dispositivo: no caso onde (B) tem um dispositivo específico, neste campo é especificado qual. (D) Source: variável na qual o valor está presente. Para os casos onde a temperatura está acima do limiar, o payload contém o objeto {ativo : true}. |
Validando o fluxo configurado
Uma vez salvas, as alterações do fluxo são automaticamente carregadas no componente contido no contêiner identificado por flowbroker. Essas alterações, juntamente com a execução de cada fluxo, podem ser monitoradas através do acompanhamento dos logs deste contêiner.
Enviando valores de temperatura à plataforma, é possível simular o comportamento esperado para cada saída do fluxo.
Note que os comandos a seguir utilizam o device id 90a144. Esse valor deve ser atualizado de acordo com o gerado na criação do dispositivo.
mosquitto_pub -i 'admin:90a144' -t /admin/90a144/attrs -h localhost -p 1883 -m '{"temperatura":23}'
 |  |
| Estado após envio da leitura de temperatura de 23ºC. |
mosquitto_pub -i 'admin:90a144' -t /admin/90a144/attrs -h localhost -p 1883 -m '{"temperatura":14}'
 |  |
|
Estado após envio da leitura de temperatura de 14ºC. Note que os valores são ordenados inversamente ao horário de recebimento. |
mosquitto_pub -i 'admin:90a144' -t /admin/90a144/attrs -h localhost -p 1883 -m '{"temperatura":32}'
 |  |
|
Estado após envio da leitura de temperatura de 32ºC. |
Com isso, é possível notar que os sinais de alerta estão de acordo com o comportamento esperado para diferentes valores de temperatura, conforme especificado pelas regras de negócio.
Conclusão
Até aqui, foram abordadas as principais funcionalidades iniciais da plataforma. A partir destes procedimentos, já espera ser possível a um novo usuário a criação de aplicações customizadas às suas necessidades.
Ainda que a aplicação abordada tenha caráter introdutório, espera-se despertar no leitor o interesse em investigar novas formas de utilizar esses procedimentos para criação de soluções de maior complexidade.
