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

3.1. Nós da dojot

3.1.1. Evento dispositivo - entrada (Device Event in)

device_node

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:

{
    "data": {
        "attrs": {
            "temperature": 10,
            "some-static-attr": "efac"
        }
    }
}

Essa estrutura pode ser referenciada em nós como Modelo do dispositivo:

Sample message {{payload.data.attrs.temperature}}

Para configurar o dispositivo no nó, uma janela como a Fig. 3.1 será exibida.

devicein_node_cfg

Fig. 3.1 : Dispositivo na janela de configuração

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.

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)

devicetemplatein_node

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.

devicetemplatein_node

Fig. 3.2 : Modelo de dispositivo janela de configuração

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.

3.1.3. Saída para múltiplos dispositivos (Multi device out)

deviceout_node

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.

deviceout_node_cfg

Fig. 3.3 : Janela de configuração do dispositivo

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 ponto final.

  • Origem (Source) (obrigatório): estrutura de dados que será mapeada como mensagem para saída do dispositivo

3.1.4. Multi atuador (Multi actuate)

actuate_node

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.

actuate_node_cfg

Fig. 3.4 : Configuração de atuação

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 ponto final.

  • Origem (Source) (obrigatório): estrutura de dados que será mapeada como mensagem para saída do dispositivo

3.1.5. Requisição HTTP

http_node

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.

httpin_node

Fig. 3.5 : Configuração do nó Requisição HTTP

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

http_node

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”.

httpin_node

Fig. 3.6 : Modelo de dispositivo janela de configuração

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)

http_node

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.

httpin_node

Fig. 3.7 : Modelo de dispositivo janela de configuração

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)

change_node

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.

change_node_cfg

Fig. 3.8 : Definir valor (Change) configuração

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)

switch_node

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.

switch_node_cfg

Fig. 3.9 : interruptor configurações

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

template_node

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

template_node_cfg

Fig. 3.10 : Configurações do Modelo

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

cron_node

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.

cron_node_cfg

Fig. 3.11 : Cron configuração

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)

cron_batch_node

Funciona como o cron node, mas aqui você pode usar agendamentos em lote.

cron_batch_node_cfg

Fig. 3.12 : Cron batch configurações

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)

geofence_node

Selecione uma área de interesse para determinar quais dispositivos irão ativar o fluxo

geofence_node_cfg

Fig. 3.13 : Geo referência (Geofence) configuração

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)

getcontext_node

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.

getcontext_node_cfg

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)

merge_data_node

Este nó permite que os objetos sejam mesclados no contexto.

merge_data_node_cfg

Fig. 3.15 : Configuração de Mesclar dados

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)

cumulative_sum_node

O nó de soma cumulativa acumula os dados para um atributo em uma janela temporal e mantém isso no contexto.

cumulative_sum_node_cfg

Fig. 3.16 : Configuração de Soma acumulada

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)

kafka2ftp_node

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.

kafka2ftp_node_cfg

Fig. 3.17 : Configurações do Publicar no tópico FTP

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. Dispositivo de entrada (Device in)

device_node

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.

devicein_node_cfg

Fig. 3.18 : Dispositivo na janela de configuração

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. Modelo de dispositivo - entrada (Device template in)

devicetemplatein_node

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.

devicetemplatein_node

Fig. 3.19 : Modelo de dispositivo janela de configuração

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. Dispositivo (saída) [Device out]

deviceout_node

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.

deviceout_node_cfg

Fig. 3.20 : Janela de configuração do dispositivo

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 ponto final.

  • Origem (Source) (obrigatório): estrutura de dados que será mapeada como mensagem para saída do dispositivo

3.1.18.4. Atuar (Actuate)

actuate_node

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.

actuate_node_cfg

Fig. 3.21 : Configuração de atuação

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.

using_http_node_flow

Fig. 3.22 : Fluxo usado para explicar o nó http

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.

using_http_node_template

Fig. 3.23 : Configuração do nó do modelo

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.

using_http_node_http

Fig. 3.24 : Configuração do nó do modelo

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.

using_http_node_change

Fig. 3.25 : Configuração do nó do modelo

using_http_node_deviceout

Fig. 3.26 : Configuração do dispositivo de saída

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:

using_http_node_result

Fig. 3.27 : Dispositivo atualizado

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:

using_geofence_node_flow

Fig. 3.28 : Fluxo usando geo referência

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.

using_geofence_node_geofence

Fig. 3.29 : Configuração do nó de geo referência

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”

using_geofence_node_template

Fig. 3.30 : Configuração do nó do modelo se o carro estiver na área marcada

using_geofence_node_result

Fig. 3.31 : Saída no dispositivo

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.

using_cum_sum_noti_flow

Fig. 3.32 : Fluxo usando os nós de soma acumulada, interruptor e notificação

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.

using_cum_sum_node_cumulative

Fig. 3.33 : Configuração de Soma acumulada

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.

using_cum_sum_node_switch

Fig. 3.34 : Configurações do nó interruptor (Switch)

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 .

using_cum_sum_node_template

Fig. 3.35 : Configuração do nó do modelo

Finalmente, vamos configurar o nó de notificação, como na imagem Fig. 3.36.

using_cum_sum_node_noti

Fig. 3.36 : Configuração do nó de notificação

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.

using_cum_sum_result

Fig. 3.37 Notificação (notification)