Um dispositivo local-first faz o seu trabalho principal no próprio hardware e na rede local, e trata a Internet como um extra e não como um requisito. Quando a nuvem é opcional, uma ligação em baixo ou um período de load shedding significa um breve incómodo e não um aparelho morto. Este texto explica porque é que os gadgets dependentes da nuvem se transformam em tijolos, os padrões que continuam a funcionar offline e um teste simples para fazer antes de comprar.

Porque é que os dispositivos dependentes da nuvem se transformam em tijolos

Muitos produtos inteligentes põem o raciocínio noutro sítio. O botão na parede não decide nada; envia uma mensagem a um servidor, o servidor decide e a resposta volta pela Internet. Essa ida e volta é invisível quando tudo funciona. Torna-se óbvia no instante em que a ligação falha.

Na África do Sul, a ligação falha muitas vezes. O load shedding deita abaixo o router e a caixa da fibra ao mesmo tempo. Os dados móveis acabam ou ficam lentíssimos. O servidor de um fornecedor fica sobrecarregado, ou a empresa descontinua discretamente a linha de produto e desliga o serviço que estava por trás. Quando algo disto acontece, um interruptor de luz que precisa da nuvem para acender uma lâmpada na mesma parede deixa de funcionar. O hardware está bom. É o cérebro que vive longe demais.

O pior cenário é o lento. Um dispositivo pode funcionar na perfeição durante dois anos e depois transformar-se em lixo eletrónico no dia em que o fabricante decide que já não vale a pena manter o serviço de nuvem. Comprou um produto; estava a alugar uma dependência.

O que local-first significa de facto

Local-first não é ser contra a Internet. É uma questão de onde acontecem as decisões importantes. Num desenho local-first, o ciclo de controlo central corre no próprio dispositivo, ou num pequeno hub instalado na sua própria rede. A nuvem fica reservada para tarefas que precisam mesmo do mundo exterior: chegar ao dispositivo quando está fora de casa, guardar histórico de longo prazo, entregar atualizações de software e partilhar acesso com outras pessoas.

Pense nisto como três camadas. A lógica no dispositivo trata da tarefa imediata. A coordenação na rede local permite que o telemóvel fale com o dispositivo por Wi-Fi sem sair de casa. A sincronização opcional com a nuvem trata de tudo o resto, e só quando há ligação. Retire a camada de cima e as duas de baixo continuam a andar.

Padrões que continuam a funcionar offline

Não é preciso desenhar hardware para reconhecer bons hábitos. Alguns padrões separam os dispositivos que sobrevivem a uma falha dos que não sobrevivem.

• Ciclo de controlo local. As leituras dos sensores e as decisões que despoletam acontecem no microcontrolador e não num servidor. Um termóstato mantém o seu horário; um interruptor interrompe.
• Hub na rede local. Um pequeno aparelho sempre ligado coordena os outros pela sua LAN, para que os comandos do telemóvel para o dispositivo nunca tenham de sair da casa.
• Sincronização diferida, não dados perdidos. Quando está offline, o dispositivo guarda as suas leituras e envia-as assim que a ligação volta, em vez de as deitar fora.
• Degradação graciosa. O dispositivo tem um comportamento definido para quando está offline: manter o último estado conhecido, seguir um horário-padrão seguro ou falhar para a posição mais segura. Não se limita a piscar um erro e desistir.
• Credenciais locais. Continua a poder iniciar sessão e configurar o dispositivo na sua própria rede sem que o servidor de contas do fornecedor esteja acessível.

O teste do funciona-offline

Consegue avaliar quase tudo isto logo na primeira noite, antes de fechar o prazo de devolução. Instale o dispositivo e depois experimente-o de propósito contra uma Internet morta.

1. Desligue o router, ou desative os dados móveis, e use a função principal. O interruptor continua a interromper e o sensor continua a responder?
2. Reinicie o dispositivo com a Internet ainda desligada. Volta sozinho a um estado funcional, ou fica pendurado à espera de telefonar para casa?
3. Abra a aplicação na mesma rede Wi-Fi sem Internet nenhuma. Consegue encontrar e controlar o dispositivo localmente?
4. Faça ao fornecedor uma pergunta directa: o que acontece a este hardware se desligarem o serviço? Uma resposta confiante costuma querer dizer que existe uma alternativa local.
5. Procure protocolos abertos como Matter, Zigbee ou MQTT para o seu próprio broker. As normas que controla são a diferença entre trocar de aplicação mais tarde e comprar tudo outra vez.

Se um dispositivo chumbar nos dois primeiros passos, não é um dispositivo inteligente. É um comando à distância para o servidor de outra pessoa.

Ensinar a mentalidade local-first

O instinto constrói-se mais facilmente em novo. As crianças que aprendem a programar em hardware que corre o programa na própria placa crescem à espera de que um dispositivo seja dono da sua própria lógica. Quando o código vive no chip, um projeto de luz e sensor continua a funcionar haja ou não Wi-Fi na sala, e quem aprende vê exatamente onde a decisão é tomada.

É esse o modelo que a nossa placa sheenbot∞ usa: o programa executa no microcontrolador, por isso um projeto comporta-se da mesma maneira numa rede doméstica, na escola ou numa mesa sem ligação nenhuma. É uma forma prática de mostrar que "inteligente" não tem de querer dizer "online". Se quiser ver como o ensinamos, a nossa academy constrói estes projetos passo a passo, pode marcar uma aula experimental, e as placas e os kits estão na loja.

O que fica

A nuvem é útil para acesso remoto, histórico e atualizações. É um mau sítio para guardar a capacidade básica de um dispositivo funcionar. Prefira produtos em que o ciclo central corre localmente, em que os dados são guardados e sincronizados em vez de descartados, e em que os protocolos abertos evitam que fique preso a uma só empresa. Depois gaste uma noite a fazer o teste do funciona-offline. Os dispositivos que passam são os que ainda estão a funcionar da próxima vez que faltar a luz.

FAQ

Local-first quer dizer que perco o acesso remoto?

Não. O local-first mantém a função principal a funcionar sem Internet, mas um dispositivo pode continuar a oferecer acesso remoto como extra opcional. A diferença é que perder esse extra não impede o dispositivo de fazer o seu trabalho principal.

A nuvem é sempre a escolha errada?

Não. Os serviços de nuvem são a ferramenta certa para histórico de longo prazo, atualizações over-the-air e chegar a um dispositivo quando se está fora. A regra é usar a nuvem para o que precisa do mundo exterior, e não para decisões que o dispositivo poderia tomar sozinho.

Como funcionam as atualizações de software se o dispositivo estiver offline?

Os bons desenhos descarregam uma atualização quando há ligação e aplicam-na localmente, em vez de precisarem de estar online no momento em que a executam. Os períodos offline atrasam as atualizações; não devem inutilizar o dispositivo.