- A SmartThings informou em 14 de setembro que o beta de migração de códigos ainda não foi habilitado devido a comportamentos que precisam ser corrigidos.
- A mudança retira o Smart Lock Guest Access da aba Life e leva gestão de PINs diretamente para o cartão da fechadura.
- A antiga capacidade lockCodes será substituída por lockUsers e lockCredentials.
- O novo modelo já é usado por fechaduras Matter e será estendido a modelos Zigbee e Z-Wave compatíveis.
- Desenvolvedores que usam lockCodes precisarão migrar suas integrações; o cronograma final ainda não foi divulgado.
A SmartThings ainda não liberou o beta público da nova gestão de códigos de fechaduras. Em 14 de setembro, Brian Jeffers, da equipe SmartThings, informou no fórum oficial que a empresa continua corrigindo comportamentos encontrados no processo de migração antes de habilitar os testadores. A mudança é grande: o serviço Smart Lock Guest Access será retirado da aba Life, e usuários e credenciais passam a ser tratados separadamente dentro do próprio cartão da fechadura.
A mudança foi anunciada no fim de agosto#
Em 28 de agosto, a SmartThings detalhou a transição. O antigo lockCodes juntava nome da pessoa e PIN num único slot físico. O novo modelo divide a identidade em lockUsers e a forma de acesso em lockCredentials. A arquitetura é mais flexível porque um usuário pode, em tese, ter diferentes credenciais sem que o sistema trate cada PIN como uma pessoa independente.
Matter já usa esse modelo em fechaduras compatíveis. O plano é levar a mesma API a Zigbee e Z-Wave, reduzindo diferenças para desenvolvedores. Lock e unlock continuam na capacidade tradicional; a mudança atinge principalmente cadastro, edição, remoção e histórico de quem entrou.
Setembro trouxe os primeiros problemas de migração#
Testadores e desenvolvedores começaram a validar drivers compatíveis e relataram inconsistências. Em 14 de setembro, a equipe confirmou que o beta destinado aos usuários cadastrados ainda não tinha sido ativado. A justificativa foi objetiva: existem comportamentos no processo de migração que precisam ser corrigidos primeiro.
É uma decisão correta para uma função sensível. Migrar uma lâmpada com erro é inconveniente; migrar PINs de uma porta e deixar dados antigos e novos divergirem pode bloquear um usuário ou manter acesso que deveria ter sido removido.
O próprio guia alerta para estado inconsistente#
Durante a transição, algumas fechaduras ainda expõem lockCodes junto das novas capacidades. A SmartThings criou o atributo migrated para indicar qual API deve ser usada. Se ele não estiver verdadeiro, desenvolvedores não devem mandar comandos para lockUsers e lockCredentials. Fazer isso pode criar divergência entre o modelo antigo e o novo.
O caminho de verificação está no anúncio oficial do SmartThings Community, que traz exemplos de API, checklist de transição e a atualização da equipe em 14 de setembro. O documento também confirma que não haverá um comando de edição em lote equivalente ao antigo updateCodes; operações devem ser feitas sequencialmente e esperar o resultado de cada comando.
O que muda para usuários quando o beta finalmente abrir#
A gestão de convidados sairá de uma área separada e ficará diretamente no dispositivo. Códigos existentes serão transferidos por uma ferramenta de migração no app. Quem usa apenas o aplicativo deverá perceber uma interface mais coerente. Quem mantém integrações próprias, Rule API ou software de aluguel temporário precisará atualizar a lógica.
O que ainda falta saber#
A SmartThings ainda não publicou o cronograma definitivo por modelo nem a data de encerramento do lockCodes. Também falta saber quando o beta de usuários será habilitado depois das correções. Até lá, desenvolvedores devem manter os dois caminhos e checar o atributo de migração antes de enviar qualquer comando sensível à fechadura.