Automatiseringen

Automatiseringen voeren een instructie volgens een planning uit en leveren het resultaat als een normale chatsessie. Een dagelijks nieuwsoverzicht, een wekelijkse beoordeling, een maandelijks rapport: elke uitvoering draait zonder interface op de server, verschijnt in uw chatlijst en kan net als elk ander gesprek worden geopend en voortgezet.

Opbouw

Een automatisering heeft een naam, instructies in vrije tekst, een of meer triggers, een optioneel model (leeg betekent Auto: uw standaardchatmodel op het moment van uitvoeren), een uitvoeringsdoel en een meldingsvoorkeur (in de app of uit). Het doel bepaalt wat een uitvoering produceert: Chat session (standaard) plaatst de instructies als gesprek in de wachtrij, terwijl Work task een geïsoleerde Work-sandbox start met de instructies als openingsbericht, eventueel onder een in het formulier gekozen benoemd Work-beleid. Als meldingen zijn ingeschakeld, verschijnt een mislukte uitvoering ook in het meldingenpostvak, zodat fouten u ook bereiken wanneer de pagina Automations gesloten is. Los daarvan: Resultaten van automatiseringen inschakelen onder Instellingen → Meldingen → E-mailmeldingen mailt u de uitkomst van elke uitvoering zodra een beheerder een uitgaande mailserver heeft ingesteld (zie Meldingen). Namen en instructies worden versleuteld opgeslagen. Elke automatisering hoort bij de gebruiker die haar heeft gemaakt.

Triggers hergebruiken het gedeelde agendamodel — once, hourly, daily, weekly, monthly, yearly — en een automatisering kan er maximaal vijf bevatten. De volgende uitvoering is altijd het vroegste aankomende tijdstip van alle triggers, berekend in de lokale tijdzone van de server.

Gebeurtenistriggers

Een zevende soort, event, heeft helemaal geen klok: hij gaat af zodra een van uw meldingen binnenkomt.

{ "kind": "event", "event": "channel-mention", "match": "release" }

event kan elk meldingstype zijn behalve automation-failed — een routine mag zichzelf niet via haar eigen foutmelding kunnen herstarten. De optionele match is een niet-hoofdlettergevoelige deeltekst-test tegen de titel van de melding; zonder match activeert elke melding van dat type de routine.

Een gebeurtenistrigger levert nooit een volgend uitvoeringstijdstip. Een automatisering waarvan alle triggers gebeurtenissen zijn, toont daarom geen volgende uitvoering: de lijst en het bewerkingsvenster tonen dan Wordt uitgevoerd wanneer … in plaats daarvan. Een gebeurtenistrigger combineren met een planning kan gewoon — de geplande triggers blijven dan de klok aandrijven.

Twee grenzen beperken de impact. Een routine gaat door gebeurtenissen hooguit één keer per minuut af, hoe druk de stroom ook is, en de eigen foutmelding van een uitvoering activeert nooit opnieuw de routine die haar veroorzaakte.

De uitvoering ontvangt wat haar activeerde, toegevoegd aan de instructies:

---
Trigger payload (JSON):
{"event":"channel-mention","title":"...","body":"...","href":"..."}

Uitvoering

Elke minuut wordt achter een coördinatielease een schedulertik uitgevoerd, zodat precies één replica planningen vooruitzet. Wanneer een automatisering moet worden uitgevoerd, registreert de tik een uitvoering, zet een duurzame taak automation.run.v1 in de wachtrij en schuift next_run_at met compare-and-set door, zodat elk tijdstip maximaal eenmaal wordt geactiveerd. De taak maakt een chatsessie met de naam van de automatisering en zet de instructie daarna in dezelfde duurzame chatgeneratiepijplijn die elk gesprek gebruikt, inclusief providerroutering, standaardwaarden van persona's en persistentie.

Als de server niet actief was toen een tijdstip verstreek, activeert de volgende tik dat tijdstip eenmaal en slaat alle oudere gemiste momenten over. Als u een automatisering onderbreekt, wordt de planning gewist; hervatten of bewerken berekent haar opnieuw vanaf het huidige moment. Als u een automatisering verwijdert, wordt de uitvoeringsgeschiedenis via een foreign-keycascade verwijderd.

Uitvoeringen worden afgehandeld vanuit het duurzame taakregister: geslaagd wanneer de chatgeneratie is voltooid, mislukt wanneer de taak in de dead-letterwachtrij terechtkomt en mislukt als stalled wanneer een uitvoering in de wachtrij niet binnen 30 minuten is gestart.

Uitvoeringen met Work als doel gedragen zich op dezelfde manier, maar gebruiken de Work-levenscyclus in plaats van de chattaak: de uitvoering registreert de gemaakte taak (het tabblad Runs koppelt er rechtstreeks naartoe), slaagt wanneer de agent klaar is — of stopt om invoer te vragen — en mislukt wanneer de taak faalt of wordt geannuleerd. Een resultaatmail voor een uitvoering met Work als doel bevat de samenvatting die de Work-uitvoering zelf heeft bewaard — waarmee de agent eindigde, dezelfde tekst die de uitvoeringsgeschiedenis van de taak toont — en valt terug op de eenregelige status van de taak wanneer een uitvoering van vóór bewaarde samenvattingen dateert. Work-toegang wordt gecontroleerd wanneer de planning afgaat. Als de Work-toegang van een gebruiker wordt ingetrokken, worden diens Work-automatiseringen dus ook stilgelegd; de uitvoering mislukt als work-access-denied en wordt niet stilzwijgend overgeslagen. Een geselecteerd beleid wordt gecontroleerd wanneer de automatisering wordt opgeslagen en de netwerkstandaard en resourcelimieten ervan gelden voor elke taak die de automatisering start. Alleen directe modelproviders werken in Work en het model moet tools ondersteunen, volgens dezelfde regels als het Work-invoerveld.

Agentroutines

Een automatisering met Work als doel kan in plaats daarvan via workTaskId aan een bestaande Work-taak worden gekoppeld. Dit is de vorm achter de sectie Routines in het detailpaneel van een agent. Een gekoppelde routine maakt niet bij elk moment een nieuwe taak: elk tijdstip start een uitvoering in de eigen werkruimte en conversatie van die taak, met het model, de provider en het runtimebeleid van de taak. De model- en beleidsvelden op automatiseringsniveau zijn dus niet van toepassing en elk meegegeven beleid wordt bij het opslaan verwijderd. De koppeling wordt bij het opslaan gecontroleerd (de taak moet bestaan en van de aanroeper zijn). Op het moment van uitvoeren mislukt een verwijderde taak als work-task-missing en mislukt een taak die al wordt uitgevoerd — of een actief voorbeeld heeft — eerlijk als work-task-busy, in plaats van achter de taak te wachten.

Webhooktriggers

Naast de planning kan een automatisering ook door een extern systeem worden geactiveerd: een CI-pijplijn, een cron-dienst, domotica. In het bewerkingsvenster van de automatisering genereert Webhooktrigger → Inschakelen een geheim per automatisering; alleen de SHA-256 daarvan wordt opgeslagen, dus de leesbare tekst wordt precies één keer getoond. Het roteren van het geheim maakt het vorige onmiddellijk ongeldig en het uitschakelen van de webhook sluit het eindpunt weer.

Het externe systeem activeert de automatisering met:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..."

(X-Libre-Webhook-Secret: lwh_... werkt als alternatieve header.) Het antwoord is 202 met het ID van de uitvoering in de wachtrij — hetzelfde handmatige uitvoerpad als Nu uitvoeren, dus uitvoeringen worden identiek afgerond, gemeld en in de geschiedenis getoond. De vergelijking van het geheim verloopt in constante tijd, een ontbrekende automatisering en een verkeerd geheim antwoorden identiek (geen orakel voor automatiserings-ID's) en een onderbroken automatisering antwoordt 409: anders dan bij Nu uitvoeren van de eigenaar kan een externe aanroeper niet door een pauze heen activeren.

Een JSON-object in de aanvraagbody reist mee in de uitvoering als triggerpayload, zodat de routine kan zien waarop hij reageert:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..." \
  -H "Content-Type: application/json" \
  -d '{"commit":"abc123","branch":"main"}'

De payload wordt toegevoegd aan de instructies die de uitvoering uitvoert, onder een kop Trigger payload (JSON): — zowel voor chatuitvoeringen, nieuwe Work-taken als taakgebonden routines. Alleen JSON-objecten worden meegenomen (arrays en scalars worden genegeerd), en een payload waarvan de geserialiseerde vorm meer dan 4000 tekens beslaat, wordt niet afgekapt maar weggelaten, met een waarschuwing in het serverlog. Een activering zonder body gedraagt zich precies als voorheen.

API

Alle eindpunten behalve de webhookactivering vereisen authenticatie en werken uitsluitend op de eigen automatiseringen van de aanroeper; de webhookactivering authenticeert zich in plaats daarvan met het geheim van de automatisering.

Methode	Pad	Doel
GET	/api/automations	Automatiseringen weergeven
POST	/api/automations	Een automatisering maken
GET	/api/automations/occurrences?from=&to=	Aankomende berekende tijdstippen
GET	/api/automations/runs	Uitvoeringsgeschiedenis (filterbaar)
GET	/api/automations/runs/summary	Aantal ongezien + perioden van 30 dagen
POST	/api/automations/runs/seen	Voltooide uitvoeringen als gezien markeren
GET	/api/automations/:automationId	Eén automatisering lezen
PUT	/api/automations/:automationId	Een automatisering bijwerken
DELETE	/api/automations/:automationId	Een automatisering verwijderen
POST	/api/automations/:automationId/pause	De planning onderbreken
POST	/api/automations/:automationId/resume	De planning hervatten
POST	/api/automations/:automationId/run	Nu uitvoeren (202 met een uitvoerings-ID)
POST	/api/automations/:automationId/webhook	Activeren via geheim (202)
POST	/api/automations/:automationId/webhook-secret	Geheim genereren of roteren
DELETE	/api/automations/:automationId/webhook-secret	De webhook uitschakelen

Een gebruiker kan maximaal 50 automatiseringen bewaren; namen zijn beperkt tot 200 tekens en instructies tot 20.000.