Integração do Azure IoT Edge com Arduino

Use esta habilidade quando o usuário precisar conectar dispositivos da classe Arduino ao Azure IoT, especialmente em cenários com forte presença de edge (gateways, redes intermitentes, buffering offline e atuação local).

Quando usar

Use esta habilidade para solicitações como:

• "Quero conectar sensores Arduino ao Azure"
• "Como envio telemetria MQTT para o IoT Hub?"
• "Preciso de um gateway de edge para dispositivos de campo"
• "Quero comandos de nuvem para dispositivo e atualizações de configuração OTA"

Revisão obrigatória da documentação

Antes de recomendar uma topologia de IoT Edge ou comportamento de runtime, revise:

• https://learn.microsoft.com/azure/iot-edge/

Se a documentação não puder ser consultada, prossiga com suposições explícitas e destaque-as em uma seção dedicada.

Referências oficiais do Arduino e melhores práticas (obrigatório)

Antes de propor detalhes de implementação de firmware, fiação ou comunicação, consulte primeiro as fontes oficiais do Arduino:

• https://www.arduino.cc/en/Guide
• https://docs.arduino.cc/
• https://docs.arduino.cc/language-reference/
• references/arduino-official-best-practices.md

Ao escolher entre alternativas de implementação, priorize a orientação oficial do Arduino sobre trechos da comunidade, a menos que haja uma razão técnica clara para desviar.

Objetivos

• Produzir um caminho de referência seguro de ponta a ponta do dispositivo Arduino a insights na nuvem.
• Lidar com links instáveis (armazenar e encaminhar, novas tentativas, idempotência).
• Definir um backlog acionável de dispositivos e nuvem.

Padrões de integração

Padrão A: Arduino direto para o IoT Hub

Use quando a conectividade for estável e a latência da nuvem for aceitável.

• Protocolo: MQTT sobre TLS.
• Identidade: credenciais por dispositivo (SAS ou X.509).
• Carga útil de telemetria: JSON compacto com timestamp, ID do dispositivo, métricas e flags de qualidade opcionais.

Padrão B: Arduino para gateway local, depois IoT Edge

Use quando os links forem restritos, o controle local for necessário ou o agrupamento melhorar o custo/confiabilidade.

• O Arduino se comunica com um gateway local (serial, BLE, MQTT local, RS-485, ponte Modbus).
• O gateway publica upstream através do runtime do IoT Edge e roteia dados para o IoT Hub.
• Módulos locais podem filtrar, agregar e acionar ações mesmo durante interrupções na nuvem.

Fluxo de design

1) Contrato do dispositivo

Defina:

• Catálogo de sensores e unidades.
• Frequência de amostragem e taxa de transferência esperada.
• Estratégia de versionamento do esquema de mensagens.
• Propriedades de twin de dispositivo desejadas/reportadas para controlar o comportamento do runtime.

2) Linha de base de segurança

Exija:

• Identidade única por dispositivo.
• Sem segredos codificados em código-fonte ou artefatos de firmware.
• Estratégia de rotação de credenciais.
• Firmware assinado e um processo de atualização controlado, quando possível.

3) Confiabilidade e comportamento offline

Planeje e documente:

• Backoff com jitter.
• Estratégia de fila/buffer local com tamanho limitado.
• Supressão de duplicatas ou processamento idempotente downstream.
• Fallback para a última configuração conhecida como boa.

4) Roteamento de nuvem e edge

Defina rotas para:

• Telemetria bruta para armazenamento a frio.
• Telemetria curada para análise quente.
• Alertas para canais de operações.
• Comandos e configuração de volta para edge/dispositivo.

5) Observabilidade

Especifique telemetria mínima de operações:

• Heartbeat do dispositivo e versão do firmware.
• Transições de estado de conectividade.
• Contadores de sucesso/erro de envio de mensagens.
• Saúde do módulo do gateway e motivos de reinicialização.

Reutilize outras habilidades

Quando relevante, combine com:

• azure-smart-city-iot-solution-builder para arquitetura em nível de cidade e implantação em fases.
• azure-resource-visualizer para diagramas de relacionamento.
• appinsights-instrumentation para padrões de telemetria de aplicativos e serviços.

Use também references/arduino-official-best-practices.md como uma linha de base de qualidade para recomendações de firmware e hardware, e references/arduino-iot-checklist.md antes de finalizar a arquitetura ou orientação de implementação.

Saída necessária

Sempre forneça:

1. Padrão de conectividade escolhido e justificativa.
2. Contrato de mensagem (campos, unidades, carga útil de exemplo).
3. Checklist de segurança para identidade/credenciais/atualizações.
4. Plano de confiabilidade (tentativa, buffering, deduplicação).
5. Backlog de implementação (firmware, gateway, nuvem).

Modelo de saída

1. Cenário e suposições
2. Arquitetura recomendada
3. Contrato de dispositivo e gateway
4. Controles de segurança e confiabilidade
5. Plano de implantação e testes de validação

Diretrizes

• Não proponha implantações de produção com credenciais compartilhadas entre dispositivos.
• Não assuma conectividade sempre ativa em implantações de campo.

…