O Home Assistant apresenta dados desatualizados após uma alteração do caminho de armazenamento

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Dados desatualizados do Home Assistant após uma alteração do caminho de armazenamento normalmente significam que a instância em execução está a ler um /config ou uma base de dados diferente da esperada, e não que o Home Assistant recriou estados antigos a partir da memória.

Pare de fazer alterações aos caminhos e preserve tanto as localizações de dados antigas como as novas. A partir do contentor em execução, confirme a origem montada, identifique a base de dados e a instância ativas, compare marcas temporais e estados exclusivos e só depois corrija um mapeamento. Se o histórico ou os registos puderem ser substituídos, pare o Home Assistant antes de copiar ou mudar o nome de qualquer elemento.

Confirme qual o caminho que o contentor em execução vê efetivamente

Inspecione o contentor ativo em vez de se basear apenas no ficheiro Compose. Confirme a origem no anfitrião mapeada para /config, se se trata de uma montagem bind ou de um volume nomeado e se a origem resolvida existe e contém os ficheiros de configuração esperados. Uma declaração aparentemente correta pode diferir do contentor em execução após uma recriação incompleta.

Uma discussão sobre uma migração resolvida salienta que a mudança de contentor depende de uma pasta de configuração montada por bind com permissões utilizáveis. Isto justifica verificar primeiro o mapeamento ativo; não prova que todos os casos de dados desatualizados sejam causados por permissões.

Crie um ficheiro marcador inofensivo no caminho pretendido do anfitrião enquanto o Home Assistant está parado e confirme que o mesmo marcador é visível em /config dentro de um contentor temporário de inspeção. Se estiver ausente, corrija o mapeamento. Se estiver presente, prossiga para a base de dados e a identidade da instância.

Distingua uma cópia antiga de ficheiros de uma base de dados externa

Compare as marcas de modificação e alguns factos de configuração exclusivos entre os caminhos antigo e novo: o nome de uma automação, uma alteração no painel, um auxiliar ou uma cópia de segurança recente. Se o novo diretório for simplesmente uma cópia antiga, não misture ficheiros seletivamente enquanto o Home Assistant estiver em execução; escolha o conjunto autoritativo e copie-o como uma unidade consistente, com o serviço parado.

Verifique o URL da base de dados do Recorder. Mover /config não move uma base de dados MariaDB ou PostgreSQL externa, e uma configuração restaurada pode continuar a apontar para a base de dados anterior. Se as entidades atuais parecerem corretas, mas o histórico for antigo, a hipótese da base de dados é mais forte do que a de uma incompatibilidade total da configuração.

O artigo da ZimaSpace sobre dados persistentes após a recriação da stack explica o modo de falha relacionado: uma montagem vazia pode parecer uma perda de dados, enquanto uma montagem antiga pode dar a impressão de que os dados recuaram no tempo.

Exclua uma instância duplicada e uma cache exclusiva do cliente

Confirme que o URL do navegador, o nome do servidor, o endereço IP, o ID da instância e o certificado pertencem ao anfitrião pretendido do Home Assistant. Durante as migrações, um registo DNS antigo, um destino de proxy inverso, uma entrada de servidor na aplicação móvel ou um anfitrião antigo ligado podem encaminhar clientes diferentes para instâncias diferentes.

Compare a mesma entidade e a mesma marca temporal do histórico numa sessão privada do navegador e num segundo cliente. Se apenas um cliente estiver desatualizado, enquanto os registos do servidor e outro cliente estiverem atualizados, limpe a ligação desse cliente ou os dados em cache do frontend, em vez de voltar a alterar o armazenamento.

Se os clientes alternarem entre estados antigos e novos, pare a instância antiga e corrija os destinos do DNS, do proxy ou do balanceador de carga. Não permita que dois controladores executem automações nos mesmos dispositivos enquanto diagnostica a identidade.

Corrija um único mapeamento e preserve uma cópia para reverter

Pare o Home Assistant, crie um instantâneo ou copie ambos os caminhos candidatos e identifique-os com o anfitrião, a data e o estado conhecido. Selecione o /config e a base de dados autoritativos como um conjunto de recuperação correspondente. Corrija apenas o mapeamento do contentor ou o URL da base de dados responsável pela incompatibilidade verificada.

Verifique a propriedade e o acesso de escrita antes de iniciar. Se o contentor conseguir ler o caminho escolhido, mas não conseguir escrever nele, o sistema poderá parecer correto inicialmente e depois não conseguir guardar novos estados. Não utilize alterações recursivas e abrangentes de permissões sem confirmar a identidade do serviço e a propriedade esperada.

Inicie o Home Assistant uma vez e inspecione os registos antes de fazer mais alterações. Se as entidades, os painéis, o histórico e as alterações recentes esperados aparecerem, prossiga para os testes de persistência. Caso contrário, pare e reverta para a cópia identificada, em vez de combinar as duas árvores de dados.

Verifique se os dados corretos sobrevivem à recriação e ao reinício

Faça uma alteração de teste reversível, como criar um auxiliar temporário ou mudar o nome de uma automação de teste. Reinicie o Home Assistant e confirme que a alteração permanece. Em seguida, recrie o contentor a partir da configuração de implementação guardada e verifique novamente.

Um resultado bem-sucedido demonstra a mesma identidade da instância, o histórico esperado, os registos atuais, a origem de montagem correta, gravações bem-sucedidas e a inexistência de um controlador duplicado. Confirme que uma nova cópia de segurança inclui o estado selecionado e guarde-a afastada de ambos os caminhos de migração.

Peça ajuda adicional se os dados variarem consoante o cliente, se o histórico vier de uma base de dados diferente da do estado ativo ou se o caminho correto ficar só de leitura após um reinício. Preserve a inspeção da montagem, o URL da base de dados, as marcas temporais, os registos e as duas cópias de reversão intactas, para que o passo seguinte possa visar o ramo restante.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.