• implementação do caso de uso de quando é registrado um código de pareamento e qual o tipo do participante.

No payload de exemplo abaixo, o código de pareamento é o "4444" e o tipo do participante é "web" (web browser).

payload para testes da função

/* registerPairCode */
{
  "requestContext": {
    "connectionId": "abc123"
  },
  "body": "{\"data\": { \"pairCode\": \"4444\", \"partyType\": \"web\" }}"
}

• usuário acessa o spa, e a página informa pra ele
  que o web socket está desconectado, em um label
  mas também um ícone em vermelho, que demonstre
  este estado.
• é apresentado próximo um botão pra o usuário
  poder se conectar

• led de status de pareamento informa status ativado/ligado
• leds do código ficam todos desligados

• implementação do caso de uso de quando é submetido um comando/mensagem, de um participante pareado para outro participante pareado.

No payload de exemplo abaixo, o código de pareamento é o "4444" e o tipo do participante é "web" (web browser).

payload para testes da função

/* sendMessage */
{
  "requestContext": {
    "connectionId": "abc123"
  },
  "body": "{ \"data\": { \"pairCode\": \"4444\", \"targetPartyType\": \"web\", \"message\": { \"heartBeat\": \"beat\" } } }"
}

...implementado no issue #6 ;

- device dispara mensagem/evento na porta SERIAL, que deve
  possibilitar a inferência para requisitar o rest service, que
  calcula e registra o código em tabela específica

...e o que deve ser implementado neste issue;

• a tabela de código, contém apenas este atributo
• tabela pode se chamar PAIRING_CODES
• como há apenas este atributo, este deve ser PARTITION KEY,
  e por definição o PRIMARY KEY (simple)
• quando recebido a resposta da requisição rest, com o
  código gerado, tentamos abrir a comunicação web socket
  fornecendo como header, o código recebido e o "client type"
  como "device"
• e por fim, com a comunicação web socket estabelecida,
  devemos colocar uma mensagem/evento na porta
  SERIAL, com o código recebido

linux + docker + node red

Estrutura para websocket, na AWS

• como criar estrura, exposição de serviços (lambda) através do API Gateway com websocket
• alternativa a montar esta estrutura, deixar o exemplo do meu próprio endpoint, já exposto e pronto para uso
  -- o endereço alternativo exposto pela minha conta AWS, está hardcoded no endpoint WebSocket (in/out) do fluxo no Node-Red.

Montar circuito de acordo com o esquema disponível no arquivo/imagem fiap-iot-test.png;

Checkout e deploy do código Arduino na placa;

• como fazemos utilização do sensor de distância ultrasonico hc-sr04, se faz necessário importar a biblioteca correspondente na IDE Arduino
  -- obter biblioteca do sensor em; https://github.com/filipeflop/Ultrasonic
  -- importar biblioteca na IDE Arduino

• agora sim, fazer checkout do código do trabalho corrente, compilar e deployar para a placa; https://github.com/jeanvillete/fiap-iot-test/tree/master/arduino/Main

Dependência de ordem de execução, se for executar com as ferramentas utilizadas aqui no teste;

• plugar a placa arduino ao cabo usb, para que o device seja registrado, i.e; /dev/ttyACM0

• o device supracitado está sob permissões do usuário ROOT, então sugiro permitir que o usuário corrente possa utilizá-la inclusive para deployar o código Arduíno na placa

$ sudo chmod u+rw /dev/ttyACM0

• (se ainda não tiver feito) deployar o código Arduíno na placa, se já tiver deployado uma vez, este passo é facultativo

• iniciar a imagem docker com privilégios de comunicação com o device do host;

$ docker run -p 1880:1880 --privileged -v /dev/ttyACM0:/dev/ttyACM0 --name fiap-iot-test --rm nodered/node-red

• com a página do node-red carregada no webbrowser (http://localhost:1880/), instale o Plugin/Palette node-red-node-serialport

• ainda na aplicação node-red, importe o arquivo com o fluxo; ./node-red/fiap-iot-test-flow.json
  -- mencionar que está hardcoded no fluxo do node-red o endpoint do websocket que eu expus via a minha conta AWS

Página com a interação web (web party na comunicação websocket)

• mencionar e apontar a página que eu expus no github.io

• device dispara mensagem/evento na porta SERIAL, que deve
  possibilitar a inferência para requisitar o rest service, que
  calcula e registra o código em tabela específica

• led de status de pareamento informa status desativado/desligado
• leds do código estão todos desligados
• todos os atuadores e sensores estão desligados,
  sendo que nenhuma mensagem de evento deve ser
  disparada

• na leitura, devemos ter a capacidade de interpretar o comando de resposta com o código de pareamento, e.g;

:91:4324

• no exemplo, o valor 91 significa o comando de leitura do código de paeamento, e o valor 4324 é o código do pareamento propriamente dito.

• GIVEN; com o SPA carregado, com uma conexão ativa
  do web socket e com o código de um device
• WHEN; usuário submete o código, e o associa
• THEN; é necessário registrar esta associação em uma
  tabela associativa, que permita que mensagens
  submetidas a este código cheguem até todos os
  clientes web socket associados.

• device atualiza a hora de recebimento do heart beat

• implementação do caso de uso de quando a conexão é estabelecida

payload para testes da função

/* connect */
{
  "requestContext": {
    "connectionId": "abc123"
  }
}

• definição da estrutura do banco dynamodb
• definição dos recursos/serviços lambda e exposição via websocket

• é esperado receber heart beat dentro do período máximo
  de 30 segundos
• não recebendo o evento dentro deste período, o led de
  conexão informa status desativado (led vermelho)
• leds do código ficam todos desligados

• neste ponto, a comunicação web socket está estabelecida
  para o device como um cliente válido
• led de status de pareamento informa status desativado/desligado
• leds do código piscam de acordo com o código recebido
  infinitamente

• no pressionar do "push button", deve-se printar o comando SERIAL;

:19:

• os eventos devem ser de status dos sensores e/ou
  atuadores conectados ao device
• **Nota; ** o device deve o status de pareado

Sensor de distância: Ultrasonic

• distância será obtida em centímetros; CM
• distância mínima calculada; 4 cm
• distância máxima calculada; 50 cm
• tempo entre inferência de alteração; 100 milisegundos
• corpo da mensagem

{
    "device": {
        "name": "sensor ultrasônico",
        "model": "hc-sr04",
        "distance": {
                "unit": "cm",
                "value": 40.4
        }
    }
}

• neste cenário, é necessário que basicamente a conexão web socket com a função lambda aws correspondente seja estabelecida
• simplesmente registramos o connectionId na tabela de conexões em questão
• Nota: esta tabela não tem neste momento a relação com nenhum dispositivo remoto, é de fato apenas uma lista das comunicações websocket possíveis de serem feitas no modo broadcast.

• implementação do caso de uso de quando a conexão é perdida/finalizada

payload para testes da função

/* disconnect */
{
  "requestContext": {
    "connectionId": "abc123"
  }
}

• fazer com que os leds específicos do código de pareamento "pisquem" de acordo com o código recebido

- o código de pareamento é formado por 4 dígitos, que devem
  ir de 1 a 4, e.g; 1234, 1144, 4444, etc.

premissa; leds para código de pareamento
- o esquema de apresentação de determinado código de
  pareamento é formado de 4 leds, onde cada um dos leds
  representa um dígito, ou seja, led_1, led_2, led_3 e led_4,
- quando o código de pareamento for recepcionado,
  exemplo, 4324, o led_4 irá acender por 2 segundos e então
  apagar, logo depois o led_3 irá acender por 2 segundos
  e apagar, então o led_2 irá acender por 2 segundos e
  apagar, e por último o led_4 voltará acender por 2 segundos
  e apagar novamente, então todos os leds ficam apagados por
  outros dois segundos, e o ciclo se repete enquanto o código
  de pareamento estiver disponível para ser printado.

premissa; definição alocação dos pinos
- leds para o código de pareamento;
  led_cod_dig_1_pin_12
  led_cod_dig_2_pin_11
  led_cod_dig_3_pin_10
  led_cod_dig_4_pin_9

• push button, solicita código pareamento;
  btn_cod_pair_pin_13
• leds para o código de pareamento;
  led_cod_dig_1_pin_12
  led_cod_dig_2_pin_11
  led_cod_dig_3_pin_10
  led_cod_dig_4_pin_9
• leds para informar se o pareamento foi estabelecido
  com algum cliente com web browser, via websocket ou não;
  led_pair_active_pin_8
• sensor ultra sonico;
  sen_ultr_trigger_pin_4
  sen_ultr_echo_pin_5