Qual é a diferença entre a hora do evento e a hora de processamento nas automações domésticas?

O tempo do evento regista quando ocorreu um evento doméstico, enquanto o tempo de processamento regista quando o motor de automação avalia esse evento.

Um sensor de porta pode registar um evento às 18:00, armazenar a mensagem durante uma falha da rede mesh e fazê-la chegar ao servidor doméstico às 18:03. A lógica baseada no tempo de processamento trata-o como atual; a lógica baseada no tempo do evento coloca-o na sequência anterior. A escolha altera a pertença a janelas, a ordenação, a reprodução e a latência, sobretudo quando os dispositivos sem fios restabelecem a ligação ou quando o servidor de automação recupera após um período de inatividade.

Os Dois Relógios Descrevem Partes Diferentes do Mesmo Percurso do Evento

O tempo do evento pertence à própria observação: quando o botão foi premido, quando a leitura foi obtida ou quando o movimento começou. O tempo de processamento pertence ao ambiente de execução da automação: quando o seu processo recebeu e avaliou o registo. Só coincidem quando o transporte, o armazenamento temporário, o agendamento e o erro do relógio são negligenciáveis.

o tempo do evento e o tempo de processamento divergem devido a atrasos de rede, armazenamento temporário e processamento. Esses componentes variam, pelo que a ordem de chegada pode diferir da ordem de ocorrência, mesmo quando cada sensor publica corretamente.

Os sistemas domésticos acrescentam outra complicação: os relógios dos dispositivos podem estar errados ou não existir. Um campo de tempo do evento só é útil quando o relógio de origem e a semântica do carimbo temporal são fiáveis. O tempo de processamento está sempre disponível no servidor, mas descreve o comportamento da entrega e não a sequência física na divisão.

O Tempo de Processamento Favorece a Reação Imediata

A automação baseada no tempo de processamento avalia um registo em relação ao relógio do servidor assim que este chega. É simples e rápida para regras como emitir um alerta sobre a carga atual da CPU ou acender uma luz após o premir de um botão em direto. Não precisa de esperar por mensagens anteriores que ainda possam estar em trânsito.

o processamento de fluxos de eventos dá ênfase à atuação sobre eventos contínuos à medida que chegam, sendo o tempo e a ordem importantes para operações com estado. O benefício da baixa latência torna-se um custo de correção quando os registos atrasados são interpretados como novas condições, em vez de indícios tardios sobre um estado anterior.

A reprodução expõe a diferença. Se os eventos da semana passada forem processados hoje, as janelas baseadas no tempo de processamento colocam-nos em torno do relógio de hoje, salvo se uma lógica especial restaurar os carimbos temporais originais. Assim, um histórico de ocupação reconstruído ou um conjunto de dados de treino pode mudar consoante o momento em que a reprodução foi executada.

O Tempo do Evento Preserva a Sequência, mas Tem de Aguardar pelos Atrasos

A lógica baseada no tempo do evento atribui os registos a janelas e sequências utilizando os carimbos temporais de ocorrência incorporados. Um evento de movimento gerado antes da abertura de uma porta continua a ser anterior, mesmo que chegue depois. Isto torna o reprocessamento histórico mais consistente e protege funcionalidades baseadas na duração ou na ordem.

o processamento baseado no tempo do evento utiliza carimbos temporais, marcas de água e tratamento de dados tardios, porque o motor não pode saber instantaneamente se todos os eventos anteriores já chegaram. Esperar mais tempo melhora a completude, mas atrasa os resultados finais e mantém o estado aberto.

O compromisso é visível nas automações. Uma tolerância de atraso de um segundo pode manter as luzes responsivas, mas não detetar um sensor de bateria atrasado durante um minuto; uma tolerância longa produz análises precisas, mas não é adequada para a atuação imediata. Muitas casas precisam de uma ação provisória rápida e de uma correção posterior, em vez de uma única política temporal para todas as regras.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

As Reconexões Transformam Estados Antigos em Novas Chegadas

Os dispositivos sem fios, os brokers e as integrações podem colocar mensagens em fila ou retê-las enquanto os subscritores estão indisponíveis. Após a reconexão, o servidor pode receber um conjunto de mensagens cujos tempos de processamento são muito próximos, embora os eventos subjacentes abranjam minutos ou horas. As regras orientadas pela chegada podem reagir como se o conjunto descrevesse o presente.

Isto explica por que motivo as mensagens retidas podem alterar o estado da casa após um reinício. Um instantâneo de estado retido, um comando em fila e um evento gerado recentemente têm significados diferentes, mesmo quando partilham um tópico e chegam durante a mesma reconexão.

Os carimbos temporais, por si só, não resolvem a ambiguidade. A automação tem de saber se um registo representa um estado, uma transição, um comando ou uma reprodução. As atualizações de estado podem substituir em segurança o valor atual, enquanto um comando antigo de “destrancar” deve normalmente falhar nas verificações de atualidade, em vez de ser executado tardiamente.

Utilize a Semântica Temporal Adequada a Cada Resultado da Automação

Escolha o tempo de processamento quando a reação imediata é mais importante do que a reconstrução exata do passado e for seguro ignorar os registos atrasados. Escolha o tempo do evento para durações, sequências, históricos de ocupação, janelas de energia, funcionalidades de modelos e qualquer cálculo que deva reproduzir o mesmo resultado após uma reprodução.

a ordem temporal torna-se pouco fiável quando a chegada difere do carimbo temporal transportado pelo evento. Os testes devem introduzir atrasos, duplicações, conjuntos de mensagens após reinícios e desvios do relógio, comparando depois as ações imediatas e o histórico corrigido.

Um design híbrido costuma funcionar melhor: atuar provisoriamente aquando da chegada, rejeitar comandos perigosos obsoletos e atualizar o estado analítico com base no tempo do evento. O limite é definido pelas expectativas do utilizador. Uma luz não deve esperar minutos por uma ordenação perfeita, enquanto um relatório de ocupação não deve reescrever o dia de ontem de acordo com o relógio de processamento de hoje.