Entrar na plataforma envolve duas frentes: o usuário entra via Keycloak e o sensor passa a existir no Meters Service. Quando o sensor vem de um Raspberry Pi, o próprio device pode fazer o boot e registrar a carteira Besu.

​
1. Login do usuário

O frontend inicia o fluxo OAuth no Gateway: Também existe o fluxo em que o callback chega ao Gateway e depois o frontend troca um session_id em POST /auth/exchange-session. Com o access_token, as chamadas protegidas usam:

​
2. Criar sensor pelo Gateway

Usuários com papel global de operador de sensor podem criar sensores em POST /sensors. Campos principais:
  • name
  • description
  • metadata
  • admins, lista opcional de keycloak_user_id
Ao criar o sensor, o Gateway:
  1. cria o sensor no Meters Service;
  2. registra o criador como sensor_admin no Auth Service;
  3. registra admins adicionais quando informados.

​
3. Boot automático do Raspberry Pi

O simulador e o device real usam POST /transactions/account. O campo pubkey é o endereço da carteira Besu do device. A chave privada nunca é enviada ao servidor.

​
Idempotência do boot

Se o mesmo deviceId já existir com a mesma carteira, o servidor responde already_registered: true. Nesse caso:
  • o sensor_id é devolvido;
  • a public_key HMAC não é reenviada;
  • o device deve continuar usando o segredo já salvo no .env.
Se o mesmo deviceId vier com outra carteira, a API retorna DEVICE_WALLET_MISMATCH.

​
Arquivo .env do device

O comando device-boot atualiza automaticamente:
SIM_PRIVATE_KEY e SIM_WALLET_PRIVATE_KEY não devem ser versionadas nem enviadas para o servidor.

​
Fluxo resumido

Provar a geração

O próximo passo: enviar medições assinadas