3. Usando o construtor de fluxos (Flowbroker)¶
Este tutorial mostrará como usar corretamente o construtor de fluxo para processar mensagens e eventos gerados pelos dispositivos.
Nota
Para quem é: usuários iniciantes
Nível: básico
Tempo de leitura: 20 min
Índice
3.1. Nós da dojot¶
3.1.1. Evento dispositivo - entrada (Device Event in)¶
Este nó especifica as mensagens recebidas de ou enviadas para um dispositivo específico. A mensagem criada por este nó é um pouco diferente daquela criada pelo nó DeviceIn.
Para configurar o dispositivo no nó, uma janela como a Fig. 3.1 será exibida.
Campos:
Nome (Name) (opcional): Nome do nó
Dispositivo (Device) (obrigatório): o dispositivo dojot que acionará o fluxo
Eventos (Events) (obrigatório): selecione quais eventos acionarão esse fluxo. A opção Atuação (Actuation) seleciona mensagens de atuação (aquelas enviadas ao dispositivo) e Publicação (Publication) seleciona todas as mensagens publicadas pelo dispositivo.
Exemplo de mensagem gerada por este nó:
Para eventos de publicação (`Publication`):
{
"data": {
"attrs": {
"temperature": 10,
"static_example": "static_example_value"
},
"id":"9face8"
},
"metadata": {
"timestamp":1623163659936,
"tenant":"admin"
},
"event": "publish"
}
Para eventos de atuação (`Actuation`):
{
"data": {
"attrs": {
"temperature": 10,
"static_example": "static_example_value"
},
"id":"9face8"
},
"metadata": {
"timestamp":1623163659936,
"tenant":"admin"
},
"event": "configure"
}
Nota
Nos eventos Publication e Actuation os atributos estaticos também estarão sempre como uma key no json dentro da key data.attrs
com seus respectivos rótulo e valor
Essa estrutura pode ser referenciada em nós como Modelo do dispositivo e outros como:
Nota
Se o dispositivo que aciona um fluxo for removido, o fluxo não funcionará mais.
3.1.2. Modelo de dispositivo - Eventos - entrada (event device template)¶
Este nó especifica que as mensagens dos dispositivos compostos por um modelo específico acionarão esse fluxo. Por exemplo, se o modelo de dispositivo definido neste nó for o modelo A, todos os dispositivos compostos com o modelo A acionarão o fluxo. Por exemplo: dispositivo1 é composto pelos modelos [A, B], dispositivo2 pelo modelo A e dispositivo3 pelo modelo B. Então, nesse cenário, apenas as mensagens do dispositivo1 e do dispositivo2 iniciarão o fluxo, porque o modelo A é um dos modelos que compõem esses dispositivos.
Campos:
Nome (Name) (opcional): Nome do nó.
Dispositivo (Device) (obrigatório): o dispositivo dojot que acionará o fluxo.
Eventos (Events) (obrigatório): Selecione qual evento acionará esse fluxo. A criação (Creation), a atualização (Update) e a remoção (Removal) estão relacionadas às operações de gerenciamento de dispositivos. Atuação (Actuation) acionará esse fluxo no caso de enviar mensagens de atuação para o dispositivo e Publicação (Publication) acionará esse fluxo sempre que um dispositivo publicar uma mensagem para executar.
Exemplo de mensagem gerada por este nó:
Para eventos de publicação (`Publication`):
{
"data": {
"attrs": {
"temperature": 10,
"static_example": "static_example_value"
},
"id":"9face8"
},
"metadata": {
"timestamp":1623163659936,
"tenant":"admin"
},
"event": "publish"
}
Para eventos de atuação (`Actuation`):
{
"data": {
"attrs": {
"temperature": 10,
"static_example": "static_example_value"
},
"id":"9face8"
},
"metadata": {
"timestamp":1623163659936,
"tenant":"admin"
},
"event": "configure"
}
Para um evento de criação ( `Creation`) - criando um dispositivo usando esse modelo(*template*):
{
"data": {
"label":"template_name"
"id":"9face8"
"templates":["1"]
"created":"2021-06-08T14:46:27.008321+00:00"
"attrs": {
"temperature": {
"id":1,
"value_type":"float",
"static_value":"",
"type":"dynamic",
"template_id":"1",
"created":"2021-06-08T14:33:24.330779+00:00",
"is_static_overridden":false
}
},
},
"metadata": {
"tenant":"admin"
},
"event": "create"
}
Para um evento de atualização ( `Update`) - Gerado alterando um modelo(*template*) ou adicionando um modelo (*template*) a um dispositivo existente:
{
"data": {
"label":"template_name"
"id":"9face8"
"templates":["1"]
"created":"2021-06-08T14:46:27.008321+00:00"
"updated":"2021-06-08T14:51:16.003916+00:00"
"attrs": {
"temperature": {
"id":1,
"value_type":"float",
"static_value":"",
"type":"dynamic",
"template_id":"1",
"created":"2021-06-08T14:33:24.330779+00:00",
"is_static_overridden":false
}
},
},
"metadata": {
"tenant":"admin"
},
"event": "update"
}
Para um evento de remoção ( `Removal`) - Ao remover um modelo (*template*) de um dispositivo:
{
"data": {
"label":"template_name"
"id":"9face8"
"templates":["1"]
"created":"2021-06-08T14:46:27.008321+00:00"
"updated":"2021-06-08T14:51:16.003916+00:00"
"attrs": {
"temperature": {
"id":1,
},
},
"metadata": {
"tenant":"admin"
},
"event": "remove"
}
Nota
Para entender melhor o JSON dentro da chave data para os eventos` Creation`, Update,` Removal`, consulte a documentação do device-manager.
Nota
Nos eventos Publication e Actuation os atributos estaticos também estarão sempre como uma key no json dentro da key data.attrs
com seus respectivos rótulo e valor
Essa estrutura pode ser referenciada em nós como Modelo do dispositivo e outros como:
3.1.3. Saída para múltiplos dispositivos (Multi device out)¶
A saída do dispositivo determinará qual dispositivo (ou dispositivos) terá seus atributos atualizados na dojot de acordo com o resultado do fluxo. Lembre-se de que este nó não envia mensagens para o seu dispositivo; ele atualiza apenas os atributos na plataforma. Normalmente, o dispositivo escolhido é um dispositivo virtual, que existe apenas na dojot.
Campos:
Nome (Name) (opcional): Nome do nó.
- Ação (Action) (obrigatório): Qual dispositivo receberá a atualização. As opções são:
O dispositivo que acionou o fluxo: isso atualizará o mesmo dispositivo que enviou a mensagem que acionou esse fluxo.
Dispositivo(s) específicos (Specific device(s)): quais dispositivo(s) que receberão a atualização.
Dispositivo(s) definido(s) durante o fluxo (Device(s) defined during the flow): quais dispositivo(s) que receberão a atualização. Isso é referenciado por uma lista de valores, assim como os valores de saída (msg.list_of_devices).
Dispositivo (Device) (obrigatório): selecione “O dispositivo que acionou o fluxo” fará com que o dispositivo que foi o ponto de entrada seja o ponto final do fluxo. “Dispositivo específico” qualquer dispositivo escolhido será a saída do fluxo e “um dispositivo definido durante o fluxo” tornará um dispositivo que o fluxo selecionou durante a execução o endpoint.
Origem (Source) (obrigatório): estrutura de dados que será mapeada como mensagem para saída do dispositivo
3.1.4. Multi atuador (Multi actuate)¶
O nó de atuação é, basicamente, a mesma coisa que o nó de dispositivo (saída). Mas pode enviar mensagens para um dispositivo real, como dizer a uma lâmpada para desligar a luz e etc.
Campos:
Nome (Name) (opcional): Nome do nó.
- Ação (Action) (obrigatório): para qual dispositivo uma mensagem será enviada. As opções são:
O dispositivo que acionou o fluxo: isso enviará uma mensagem para o mesmo dispositivo que enviou a mensagem que acionou esse fluxo.
Dispositivo(s) específicos (Specific device(s)): para quais dispositivo(s) a mensagem será enviada.
Dispositivos definidos durante o fluxo (Device(s) defined during the flow): para quais dispositivo(s) a mensagem será enviada. Isso é referenciado por uma lista de valores, assim como os valores de saída (msg.list_of_devices).
Dispositivo (Device) (obrigatório): selecione “O dispositivo que acionou o fluxo” fará com que o dispositivo que foi o ponto de entrada seja o ponto final do fluxo. “Dispositivo específico” qualquer dispositivo escolhido será a saída do fluxo e “um dispositivo definido durante o fluxo” tornará um dispositivo que o fluxo selecionou durante a execução o endpoint.
Origem (Source) (obrigatório): estrutura de dados que será mapeada como mensagem para saída do dispositivo
3.1.5. Requisição HTTP¶
Este nó envia uma solicitação http para um determinado endereço e, em seguida, pode encaminhar a resposta para o próximo nó no fluxo.
Campos:
Método (Method) (obrigatório): o método http (GET, POST, etc …).
URL (obrigatório): a URL que receberá a solicitação http
Corpo da solicitação (Request body) (obrigatório): variável que contém o corpo da solicitação. Este valor pode ser atribuído à variável usando o nó modelo, por exemplo.
Resposta (Response) (obrigatório): variável que receberá a resposta http.
Retorno (Return) (obrigatório): Tipo do retorno.
Nome (Name) (opcional): Nome do nó.
3.1.6. Requisição FTP¶
Este nó envia um arquivo para um servidor FTP. Ao fazer upload de um arquivo, seu nome pode ser definido configurando o campo “Nome do arquivo” da mesma maneira que outras variáveis de saída (ele deve se referir a uma variável definida no fluxo). A codificação do arquivo definirá o enconding do arquivo, que pode ser, por exemplo, “base64” ou “utf-8”.
Campos:
Método (Method) (obrigatório): a ação do FTP a ser executada (PUT ).
URL (obrigatório): o servidor FTP
Autenticação (Authentication) (obrigatório): Nome de usuário e senha para acessar este servidor.
Nome do arquivo (File name) (obrigatório): variável que contém o nome do arquivo a ser carregado.
Conteúdo do arquivo (File content) (obrigatório): Essa variável deve conter o conteúdo do arquivo.
Codificação de arquivo (File encoding) (obrigatório): como o arquivo é codificado
Resposta (Response) (obrigatório): variável que receberá a resposta FTP
Nome (Name) (opcional): Nome do nó.
3.1.7. Notificação (notification)¶
Este nó envia uma notificação do usuário para outros serviços na dojot. Isso pode ser útil para gerar notificações de aplicativos que podem ser consumidas por uma aplicação front-end. O usuário pode definir uma mensagem estática a ser enviada ou, como outros nós de saída, configurar um conjunto de variáveis em um nó anterior que será resolvido no tempo de execução. Além disso, os metadados podem ser adicionados à mensagem: pode ser um objeto de chave-valor simples que contém dados arbitrários.
Campos:
Nome (Name) (opcional): Nome do nó
Mensagem (Message) (obrigatório): Estática se a notificação contiver um texto estático. Ou dinâmico que permitirá que uma variável seja configurada como saída para este nó. Essa variável será substituída no tempo de execução.
Valor (Value) (obrigatório): conteúdo da mensagem (texto estático ou referência variável).
Metadados (Metadata) (obrigatório): referência de variável que contém um dicionário simples (pares de chave-valores) que contém os metadados a serem adicionados à mensagem
3.1.8. Definir valor (Change)¶
O nó de Definir valor é usado para copiar ou atribuir valores a uma saída, por exemplo, copie valores de atributos de uma mensagem para um dicionário que será atribuído ao dispositivo virtual.
Campos:
Nome (Name) (opcional): Nome do nó
msg (obrigatório): definição da estrutura de dados que será enviada para o próximo nó e receberá o valor definido no campo para
para (to) (obrigatório): atribuição ou cópia de valores
Nota
Mais de uma regra pode ser atribuída clicando em +adicionar abaixo da caixa de regras.
3.1.9. Interruptor (Switch)¶
O nó Interruptor permite que as mensagens sejam roteadas para diferentes ramificações de um fluxo avaliando um conjunto de regras em relação a cada mensagem.
Campos:
Nome (Name) (opcional): Nome do nó
Propriedade (Property) (obrigatório): variável que será avaliada
Caixa de regras (obrigatório): regras que determinarão a ramificação de saída do nó. Além disso, ele pode ser configurado para interromper a verificação de regras quando encontrar uma que corresponda ou verificar todas as regras e rotear a mensagem para a saída correspondente.
Nota
Mais de uma regra pode ser atribuída clicando em +adicionar abaixo da caixa de regras.
As regras são mapeadas individualmente para os conectores de saída. Que a primeira regra está relacionada à primeira saída, a segunda regra à segunda saída e etc…
3.1.10. Modelo (Template)¶
Nota
Apesar do nome, este nó não tem nada a ver com modelos de dispositivos da dojot
Este nó atribuirá um valor a uma variável de destino. Este valor pode ser uma constante, o valor de um atributo que veio do dispositivo de entrada e etc.
Ele usa a linguagem mustache. Verifique a Fig. 3.10 como exemplo: o campo a da payload será substituído pelo valor de payload.b
Campos:
Nome (Name) (opcional): Nome do nó
Propriedade (Set Property) (obrigatório): variável que receberá o valor
Formato (Format) (obrigatório): o modelo de formato que será gravado
Modelo (Template) (obrigatório) *: Valor que será atribuído à variável de destino definida em **Propriedade*
Saída (Output as) (obrigatório): o formato da saída
3.1.11. Cron¶
Nó de processamento para criar/remover tarefas cron. Cron permite agendar tarefas para: enviar eventos para o data broker ou executar uma requisição http.
Campos:
Operação (obrigatório): define o tipo de processamento ao criar ou remover trabalhos cron (CREATE, REMOVE).
Expressão de Tempo do CRON (obrigatório): Expressão de Tempo do CRON, por exemplo * * * * * *. Obrigatório ao usar a operação do tipo CREATE.
Nome do Trabalho (opcional): Nome do JOB.
Descrição do Trabalho (opcional): Descrição do Trabalho.
Tipo do Trabalho (obrigatório): As opções são EVENT REQUEST ou HTTP REQUEST.
Ação do Trabalho (obrigatório): Variável que contém o JSON para Ação do Trabalho. Este valor pode ser atribuído à variável usando o nó do modelo, por exemplo.
Identificador do Trabalho (saída para) (obrigatório): Variável que receberá o Identificador do Trabalho.
Nome (Name) (opcional): Nome do nó
Exemplo de Ação do Trabalho quando Tipo do Trabalho é HTTP REQUEST:
{
"method": "PUT",
"headers": {
"Authorization": "Bearer ${JWT}",
"Content-Type": "application/json"
},
"url": "http://device-manager:5000/device/${DEVICE_ID}/actuate",
"body": {
"attrs": {"message": "keepalive"}
}
}
Exemplo de Ação do Trabalho quando Tipo do Trabalho é EVENT REQUEST:
{
"subject": "dojot.device-manager.device",
"message": {
"event": "configure",
"data": { "attrs": { "message": "keepalive"},
"id": "6a1213"
},
"meta": { "service": "admin"}
}
}
3.1.12. Cron em lote (Cron batch)¶
Funciona como o cron node, mas aqui você pode usar agendamentos em lote.
Campos:
Operação (obrigatório): define o tipo de processamento ao criar ou remover trabalhos cron (CREATE, REMOVE).
Requisições de trabalho (obrigatório): Variável que contém o array de JSONs para ações de trabalho.
Identificadores de trabalho (obrigatório): Variável que receberá o array de identificadores de trabalho.
Nome (Name) (opcional): Nome do nó
3.1.13. Geo referência (Geofence)¶
Selecione uma área de interesse para determinar quais dispositivos irão ativar o fluxo
Campos:
Área (Area) (obrigatório): Área que será selecionada. Pode ser escolhido como um quadrado ou um pentano.
Filtro (Filter) (obrigatório): Qual lado da área será selecionado: dentro ou fora da área marcada no campo acima.
Nome (Name) (opcional): Nome do nó
3.1.14. Obter contexto (Get Context)¶
Este nó é usado para obter uma variável que está no contexto e atribuir seu valor a uma variável que será usada no fluxo.
Nota: O contexto é um mecanismo que permite que um determinado conjunto de dados persista além da vida do evento, possibilitando o armazenamento de um estado para os elementos da solução.
Campos:
Nome (Name) (opcional)*: Nome do nó
Camada de contexto (Context layer) (obrigatório)*: a camada do contexto em que a variável está
Nome do contexto (Context name) (obrigatório)*: a variável que está no contexto
Conteúdo do contexto (Context content) (obrigatório)*: a variável no fluxo que receberá o valor do contexto
3.1.15. Mesclar dados (Merge data)¶
Este nó permite que os objetos sejam mesclados no contexto do flow.
Campos:
Dado alvo (JSON) (required): Variável que contém os dados a serem mesclados.
Dado mesclado (JSON) (JSON) (required): Variável que receberá os novos dados mesclados com os dados existentes.
Nome (Name) (opcional): Nome do nó
3.1.16. Soma acumulada (Cumulative sum)¶
O nó de soma cumulativa acumula os dados para um atributo em uma janela temporal e mantém isso no contexto do flow.
Campos:
Período de tempo (min) (obrigatório): Tempo em minutos para manter a soma.
Atributo alvo (obrigatório): Variável que contém o valor a ser soma.
Tempo do evento (Obrigatório): Variável que contém o timestamp advindo do device ou da dojot. Na maioria das vezes pode ser setado com payload.metadata.timestamp.
Somatório (Obrigatório): Variável que receberá a soma.
Nome (Name) (opcional): Nome do nó
3.1.17. Publicar no tópico FTP (Publish in FTP topic)¶
Nó para encaminhar mensagens para o tópico de FTP do Apache Kafka.
Publica no tópico tenant.dojot.ftp
(tenant é definido por qual tenant o fluxo pertence) onde as mensagens são produzidas com informações sobre o nome do arquivo, codificação e conteúdo do arquivo.
Campos:
Codificação (obrigatório): Codificação do conteúdo do arquivo a ser enviado. Os valores válidos são: ascii, base64, hex, utf16le, utf8 e binary.
Nome do arquivo (Filename) (obrigatório): variável que contém o nome do arquivo a ser enviado.
Conteúdo do arquivo (Content) (obrigatório): Essa variável deve conter o conteúdo do arquivo a ser enviado.
Nome (Name) (opcional): Nome do nó
Exemplo de mensagem enviada por este nó:
{
"metadata": {
"msgId": "33846252-659f-42cc-8831-e2ccb923a702",
"ts": 1571858674,
"service": "flowbroker",
"contentType": "application/vnd.dojot.ftp+json"
},
"data": {
"filename": "filename.jpg",
"encoding": "base64",
"content": "..."
}
}
Onde as chaves acima são:
msgId: Valor do tipo uuidv4 usado para identificar unicamente a mensagem no contexto da dojot.
ts: Timestamp no formato Unix Timestamp (ms) do momento em que a mensagem foi produzida.
service: Nome do serviço que gerou a mensagem.
contentType: Tipo de codificação usado pelo arquivo.
filename: Nome do arquivo a ser enviado ao servidor FTP.
encoding: codificação do conteúdo do arquivo. Os valores válidos são: ascii,base64, hex, utf16le, utf8 and binary.
content: conteúdo do arquivo.
Este nó pode ser usado com o componente kafka2ftp. Veja mais em Componentes e APIs.
3.1.18. Nós descontinuados¶
Esses nós estão programados para serem removidos em versões futuras. Eles funcionarão sem problemas com os fluxos atuais.
3.1.18.1. Device in¶
Este nó determina um dispositivo específico para ser o ponto de entrada de um fluxo. Para configurar o dispositivo no nó, uma janela como a Fig. 3.18 será exibida.
Campos:
Nome (Name) (opcional): Nome do nó
Dispositivo (Device) (obrigatório): o dispositivo dojot que acionará o fluxo
Estado (Status0 (obrigatório): excluir alterações de status do dispositivo não usará alterações de status do dispositivo (online, offline) para acionar o fluxo. Por outro lado, incluir alterações de status dos dispositivos usará esses status para acionar o fluxo.
Nota
Se o dispositivo que aciona um fluxo for removido, o fluxo se tornará inválido.
3.1.18.2. Device template in¶
Esse nó fará com que um fluxo seja acionado por dispositivos compostos por um determinado modelo. Se o modelo de dispositivo configurado no modelo de dispositivo no nó for o modelo A, todos os dispositivos compostos com o modelo A acionarão o fluxo. Por exemplo: dispositivo1 é composto pelos modelos [A, B], dispositivo2 pelo modelo A e dispositivo3 pelo modelo B. Então, nesse cenário, apenas as mensagens do dispositivo1 e do dispositivo2 iniciarão o fluxo, porque o modelo A é um dos modelos que compõem esses dispositivos.
Campos:
Nome (Name) (opcional): Nome do nó.
Dispositivo (Device) (obrigatório): o dispositivo dojot que acionará o fluxo.
Estado (Status) (obrigatório): escolha se as alterações de status dos dispositivos acionarão ou não o fluxo.
3.1.18.3. Device out¶
A saída do dispositivo determinará qual dispositivo terá seus atributos atualizados na dojot de acordo com o resultado do fluxo. Lembre-se de que este nó não envia mensagens para o seu dispositivo; ele atualiza apenas os atributos na plataforma. Normalmente, o dispositivo escolhido é um dispositivo virtual, que existe apenas na dojot.
Campos:
Nome (Name) (opcional): Nome do nó.
Dispositivo (Device) (obrigatório): selecione “O dispositivo que acionou o fluxo” fará com que o dispositivo que foi o ponto de entrada seja o ponto final do fluxo. “Dispositivo específico” qualquer dispositivo escolhido será a saída do fluxo e “um dispositivo definido durante o fluxo” tornará um dispositivo que o fluxo selecionou durante a execução o endpoint.
Origem (Source) (obrigatório): estrutura de dados que será mapeada como mensagem para saída do dispositivo
3.1.18.4. Actuate¶
O nó de atuação é, basicamente, a mesma coisa que o nó de dispositivo (saída). Mas pode enviar mensagens para um dispositivo real, como dizer a uma lâmpada para desligar a luz e etc.
Campos:
Nome (Name) (opcional): Nome do nó.
Dispositivo (Device) (obrigatório): um dispositivo real na dojot
Origem (Source) (obrigatório): estrutura de dados que será mapeada como mensagem para saída do dispositivo
3.2. Aprenda por exemplos¶
3.2.1. Usando nó http¶
Imagine este cenário: um dispositivo envia um usuário e uma senha e, a partir desses atributos, o fluxo solicitará a um servidor um token de autenticação que será enviado a um dispositivo virtual que possua um atributo de token.
Para enviar essa solicitação ao servidor, o método http deve ser um POST e os parâmetros devem estar dentro da requisição. Portanto, no nó do modelo, um objeto JSON será designado a uma variável. O corpo (parâmetros usuário e senha) da requisição será designado à chave de payload do objeto JSON. E, se necessário, esse objeto também pode ter um headers como chave.
Em seguida, no nó http, o campo Requisição receberá o valor do objeto criado no nó do modelo. E, a resposta será atribuída a qualquer variável, neste caso, é msg.res.
Nota
Se o buffer UTF-8 String for escolhido no campo de retorno, o corpo da resposta será uma string. Se o objeto JSON for escolhido, o corpo será um objeto.
Como visto, a resposta do servidor é req.res e o corpo da resposta pode ser acessado em msg.res.payload. Portanto, as chaves do objeto que veio na resposta podem ser acessadas por: msg.res.payload.key. Na figura Fig. 3.25, o token que veio na resposta é atribuído ao token de atributo do dispositivo virtual.
Em seguida, o resultado do fluxo é que o token de atributo do dispositivo virtual seja atualizado com o token que veio na resposta da solicitação http:
3.2.2. Usando o nó de geo referência (geofence)¶
Um bom exemplo para aprender como o nó geo referência (geofence) funciona é com o fluxo abaixo:
O nó de geo referência é definido como parece na Fig. 3.29. A única coisa que diferencia os nós de geo referência in area e out of the area é o campo Filtro que, no primeiro, é configurado para apontar apenas para dentro e para fora no segundo, respectivamente.
Em seguida, se o dispositivo definido como dispositivo de entrada enviar uma mensagem com um atributo geográfico, o nó geo referência avaliará o ponto geográfico de acordo com sua regra e se corresponder à regra, o nó encaminhará as informações para o próximo nó e, se não , a execução da ramificação, que possui a geo referência que a regra não corresponde, para.
Nota
Para o nó de geo referência funcionar, a mensagem recebida deve ter um atributo geográfico; caso contrário, as ramificações do fluxo serão interrompidas nos nós de geo referência.
De volta ao exemplo, se o carro enviar uma mensagem de que ele está na área marcada, como {"position": "-22.820156, -47.2682535"}
, a mensagem recebida no dispositivo será “Carro está dentro da área marcada” e se enviar {"position": "0,0"}
o dispositivo receberá “O carro está fora da área marcada”
3.2.3. Usando os nós de soma acumulada, interruptor e notificação¶
Imagine este cenário: um dispositivo envia o nível de chuva, queremos gerar uma notificação se o acumulado, soma, das chuvas nas últimas horas é maior que 100.
No nó cumulative sum, nós iremos acumular o valor de rain (Target attribute) na janela de tempo de 60 minutos (Time period) e iremos setar essa soma em um novo atributo chamado payload.data.attrs.rain60Min (Sum). A configuração Timestamp refere-se ao timestamp advindo do dispostivo ou da dojot. Na maioria das vezes pode ser setado com payload.metadata.timestamp. Veja mais em Fig. 3.33.
Nós queremos que a notificação seja disparada apenas se o valor de chuva acumulado seja maior que 100, para isso usaremos o nó switch. Como na imagem Fig. 3.34.
Agora, caso nosso valor seja maior que 100 precisamos gerar a notificação, para tal usaremos um nó auxiliar antes, o nó template. No nó template iremos criar a mensagem que irá aparecer na notificação e definir seus metadados, Fig. 3.35 .
Finalmente, vamos configurar o nó de notificação, como na imagem Fig. 3.36.
Portanto, se a estação meteorológica (dispositivo definido no nó do dispositivo de evento com publicação marcada) envia várias mensagens como {“rain”: 5} durante a última hora e em uma dessas vezes a soma for superior a 100, uma notificação será gerada. Nota: Várias notificações podem ser geradas, desde que o valor acumulado seja superior a 100 na última hora. Veja a imagem Fig. 3.37.