Como é que o Home Assistant protege a consistência durante alterações simultâneas?

O Home Assistant limita os conflitos de alterações concorrentes através do agendamento do ciclo de eventos, de atualizações da máquina de estados, dos modos de automação, da coordenação das integrações e de gravações transacionais na base de dados.

Esses mecanismos mantêm as estruturas internas coerentes, mas não inferem qual de duas intenções domésticas válidas deve prevalecer. Uma automação de movimento pode acender um candeeiro enquanto uma automação de hora de deitar o apaga, e ambas as chamadas de serviço podem ser executadas corretamente. A consistência abrange, por isso, duas camadas: o Core deve preservar transições de estado válidas, enquanto a configuração deve definir a ordem, o cancelamento ou a precedência de ações concorrentes.

O ciclo de eventos serializa o trabalho crítico no processo

O Home Assistant Core utiliza agendamento assíncrono para permitir que muitas tarefas aguardem por E/S sem que cada uma tenha de possuir uma thread. O código executado no ciclo de eventos avança de forma cooperativa, mantendo ordenadas as operações centrais de estado quando as integrações cumprem o contrato assíncrono.

Uma discussão detalhada sobre a concorrência no Home Assistant explica como a serialização do ciclo de eventos coordena callbacks e tarefas, enquanto o código bloqueante tem de ser afastado do ciclo.

A serialização nesta camada impede a mutação simultânea de algumas estruturas internas, mas não torna atómica uma automação completa com várias etapas. Uma tarefa pode aguardar pela E/S de um dispositivo enquanto outra tarefa válida avança.

Os modos de automação definem a admissão e a ordem

O modo único rejeita uma nova execução enquanto uma estiver ativa; o modo reiniciar cancela a execução anterior; o modo em fila preserva a ordem; e o modo paralelo permite a sobreposição. Selecionar um modo é, por isso, uma decisão de política sobre o significado dos acionamentos concorrentes para essa automação.

Uma discussão sobre condições de corrida que envolve automações em conflito mostra por que motivo as escritas de automações em conflito devem ser escolhidas tendo em conta o recurso controlado e a precedência pretendida.

O modo em fila pode preservar a ordem de chegada dentro de uma automação, mas automações separadas podem continuar a entrar em conflito. Quando várias regras escrevem na mesma entidade, é necessário consolidar a responsabilidade ou adicionar um árbitro explícito.

As integrações conciliam o estado pretendido e o estado observado do dispositivo

Uma chamada de serviço expressa uma ação pretendida, enquanto o feedback posterior do dispositivo fornece o estado observado. As integrações podem utilizar bloqueios, coordenadores, atualizações otimistas, sondagem ou confirmações para evitar operações de protocolo sobrepostas e conciliar diferenças.

Os exemplos dos modos de automação esclarecem como a execução em fila e em paralelo altera a ordem de execução, mas o protocolo do dispositivo pode ainda reordenar ou rejeitar comandos depois de o Core os enviar.

A ordem interna não garante a ordem física através de uma rede rádio sujeita a perdas, de um serviço na nuvem ou de um dispositivo adormecido. Quando o protocolo o suporta, o resultado autoritativo deve provir do estado confirmado do dispositivo, e não apenas da ordem pela qual as chamadas de serviço foram emitidas.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

As transações protegem o armazenamento, não a intenção doméstica

As transações do Recorder mantêm válidas as alterações relacionadas na base de dados durante as confirmações e a recuperação. Protegem a representação armazenada contra gravações parciais, mas a persistência histórica ocorre depois das decisões de estado e não consegue resolver comandos contraditórios.

Um guia prático alerta para o facto de o modo de automação predefinido poder não corresponder ao comportamento pretendido, reforçando que a política de intenção da automação é separada da consistência da base de dados.

Esta é a fronteira da falha: se duas regras corretas codificarem objetivos incompatíveis, o Core pode permanecer internamente consistente enquanto o dispositivo oscila. Adicione responsabilidade, precedência, um período de arrefecimento ou uma máquina de estados partilhada; ajustar a base de dados não pode corrigir uma intenção ambígua.

Teste um único conflito com um agendamento determinístico

Escolha uma entidade inofensiva e acione os caminhos concorrentes com intervalos controlados: simultaneamente, com um segundo de diferença e durante um atraso deliberado do dispositivo. Registe a ordem dos rastreios das automações, as chamadas de serviço, as confirmações, os eventos de estado e o estado físico final.

Os limites entre entrada e controlo acompanham uma automação local desde as entradas até ao controlo, fornecendo os limites necessários para distinguir a ordenação do Core da reconciliação do dispositivo.

Considere o teste aprovado apenas quando o vencedor declarado e o estado final do dispositivo coincidirem em ensaios repetidos, incluindo casos de reinício e de dispositivo indisponível. Se os resultados variarem, atribua a responsabilidade a uma única automação e encaminhe as outras intenções através dela; não adicione atrasos arbitrários até que os rastreios identifiquem o limite em disputa.