> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-pt/kilo-iot-server/rules-engine/triggers/trigger-timing.md).
# Temporização do gatilho
Escolha o tempo de acionamento imediato ou sustentado e controle quando uma condição Kilo é reposta ou inicia uma regra agendada.
O tempo do acionamento responde a uma pergunta: **quanto tempo a condição tem de ser verdadeira antes de o Kilo iniciar a regra associada?** Não determina quais os dispositivos monitorizados; a seleção de dispositivos é configurada separadamente no mesmo acionamento.
## Escolha um modo de temporização
Em **Quando deve começar?**, escolha:
* **Imediatamente** — ative o acionamento assim que a sua condição se tornar verdadeira.
* **Só se durar** — inicie uma contagem decrescente quando a condição se tornar verdadeira e ative o acionamento depois de esta ter permanecido verdadeira durante a duração especificada.
Use **Imediatamente** para condições urgentes, como uma fuga de água. Use **Só se durar** quando se esperam alterações curtas, como a abertura da porta de uma câmara frigorífica durante a carga.
## Configure Apenas se durar
1. Selecione **Só se durar**.
2. Introduza uma duração em número inteiro.
3. Selecione **segundos**, **minutos**, **horas**, ou **dias**.
O mínimo é 10 segundos, o máximo é 30 dias, e um novo acionamento de duração começa aos 10 minutos.
Defina a duração tendo em conta o intervalo de reporte. Uma lacuna sem novo relatório do sensor não reinicia uma contagem decrescente em curso. Se um sensor reportar de 15 em 15 minutos, uma duração de 10 minutos pode ainda depender da sua última leitura conhecida em vez de um segundo relatório de confirmação.
## Compreenda a reposição
Por predefinição, o acionamento é reposto quando uma nova avaliação deixa de satisfazer a condição de início. A reposição devolve esse dispositivo monitorizado ao seu estado normal para que uma ocorrência posterior possa ativar o acionamento novamente.
Ativar **Repor com uma condição separada** quando a recuperação requer lógica diferente. A condição de reposição tem as suas próprias comparações e pode ser:
* imediata; ou
* atrasada com **Só se durar**.
Por exemplo, inicie um acionamento de sobreaquecimento depois de a temperatura permanecer acima de 80 °C durante cinco minutos, mas repô-lo apenas depois de a temperatura permanecer abaixo de 70 °C durante 15 minutos. O limite e o atraso separados impedem que uma única leitura limítrofe termine o incidente.
Cada dispositivo monitorizado tem o seu próprio estado de início e de reposição. A reposição de um dispositivo não reinicia a contagem decrescente de outro dispositivo.
## Combine a temporização com um agendamento da regra
A duração do acionamento e a do evento de início **Ativar agendamento** resolvem problemas diferentes:
* A temporização do acionamento decide quando a condição se torna ativa.
* O agendamento da regra decide se a regra pode ser executada nesse momento.
O acionamento continua a monitorizar fora do agendamento da regra. Quando o acionamento sinaliza a regra, a regra verifica o seu agendamento e regista uma tentativa fora da janela como ignorada.
Para uma regra agendada das 22:00 às 06:00 com um acionamento de 10 minutos:
* uma condição que começa às 21:55 e termina às 22:05 pode executar a regra;
* uma condição que termina às 06:05 está fora do agendamento e é ignorada.
## Exemplos operacionais
### Roubo numa garagem de condomínio
Um operador de condomínio precisa de detetar atividade prolongada numa garagem onde, no passado, ladrões removeram rodas de veículos estacionados. Os moradores também entram na garagem à noite, pelo que um alarme em cada evento de movimento criaria frequentes falsos alarmes.
Configure o acionamento e a regra em conjunto:
* Condição do acionamento: a métrica de movimento da garagem indica movimento.
* Temporização do acionamento: **Apenas se durar — 10 minutos**.
* Agendamento da regra: **22:00–06:00** no fuso horário local do edifício.
* Ação da regra: emitir um alarme para a equipa de resposta noturna.
Um residente a caminhar até um carro e a sair ao fim de alguns minutos não completa a duração do acionamento. O movimento que permanece presente durante 10 minutos nas horas noturnas agendadas inicia a regra e dispara o alarme. A duração reduz falsos alarmes de curta duração; o agendamento impede que a mesma regra trate a atividade normal diurna da garagem como um incidente noturno.
### Porta do congelador deixada aberta durante a noite
Para um supermercado ou condomínio com armazenamento refrigerado partilhado, use `door_open = true`, **Apenas se durar — 10 minutos**, e o agendamento noturno do local. Uma verificação rápida do stock é ignorada. Se a porta permanecer aberta, a regra pode emitir um alarme de alta prioridade antes que a temperatura suba o suficiente para danificar o stock.
### Atividade na zona de carga após o fecho
Defina uma condição de movimento na zona de carga para durar cinco minutos e restrinja a regra ao horário fora de funcionamento. Um funcionário da limpeza ou empregado que passe não completa a duração, enquanto atividade prolongada após o fecho inicia a resposta de segurança.
### Condição do equipamento sem agendamento
Nem todo acionamento de duração precisa de um agendamento. Uma leitura de vibração acima do limite de funcionamento durante dois minutos pode parar uma máquina ou emitir um alarme a qualquer hora. Aqui, a duração filtra um pico breve, enquanto a regra permanece ativada 24 horas por dia.
## Ver também
* [Acionadores](/kilo-docs-pt/kilo-iot-server/rules-engine/triggers.md) — crie e conecte um acionamento
* [Um Gatilho para Vários Dispositivos](/kilo-docs-pt/kilo-iot-server/rules-engine/triggers/multiple-devices.md) — estados independentes dos dispositivos e leituras partilhadas
* [Referência de Nós](/kilo-docs-pt/kilo-iot-server/rules-engine/node-reference.md) — campos de agendamento do evento de início
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-pt/kilo-iot-server/rules-engine/triggers/trigger-timing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
