Automations Grundlagen

Automations sind Chatlix' visueller Regel-Builder für „Wenn X, dann Y (und Z, und ggf. W)". Im Gegensatz zu einer einfachen Event Reaction können sie mehrere Actions in Reihenfolge fahren, Bedingungen prüfen, Counter/Variablen führen, per-User-Sperren setzen und externe Webhooks ansprechen.

Kurz: Automations sind das, was du nimmst, sobald eine Reaction nicht mehr reicht — sobald Bedingungen, Zähler oder mehr als 1-2 Actions ins Spiel kommen.

Wann eine Automation?

„Auf jeden 100. Cheer ein Konfetti-Overlay." → Counter + Condition.
„Wenn Stream länger als 1 h läuft, andere Begrüßung als am Anfang." → Variable + Condition.
„Bei einem Sub: Sound + Overlay + Chat + Discord-Webhook + Punkte für den Inviter." → mehrere Actions in Reihe, inkl. externer.
„Wenn eine Twitch-Werbeunterbrechung beginnt, sag im Chat Bescheid." → Ad-Break-Automation, siehe unten.
„Pro Zuschauer max. 1× pro Stunde diese Action, und generell nur 1× pro Stream." → Cooldown + One-Time-Lock (siehe eigene Seite Cooldowns).

Für simple 1-Action-Fälle ohne jede Bedingung bleibt eine Event Reaction meist die schlankere Wahl — schneller gebaut, schneller gewartet. Automations lohnen sich, sobald mindestens eines dazukommt: Bedingung, Zähler/Variable, mehr als eine Action, oder ein Cooldown/Lock, der über eine einfache globale Sperre hinausgeht.

Wo im Dashboard

Wichtig: Automations liegen nicht alle unter einem gemeinsamen /dashboard/automations/...-Unterpfad — die Wiki-Vorversion hatte hier falsche Pfade. Die echten Seiten sind eigenständige Top-Level-Routen:

/dashboard/automations — Liste aller Automations, Editor (Modal), und oben auf der Seite eine Karte mit den aktuell verfügbaren Logic-Packs (dazu mehr auf der Seite Automation-Templates).
/dashboard/automation-templates — die kuratierte, kategorisierte Template-Bibliothek (älteres, größeres System als die Logic-Packs).
/dashboard/automation-variables — Runtime-Variablen (Power-Tier).
/dashboard/automation-debug — Automation-Tester: einzelne Regel isoliert mit Mock-Event durchspielen (Power-Tier).
/dashboard/automation-runs — Lauf-Historie/Verlauf aller Ausführungen (Power-Tier).
/dashboard/automation-queues — Warteschlange/Pending Actions (Power-Tier).

Counter-Verwaltung ist keine Automation-Unterseite, sondern ein eigenständiges Top-Level-Feature: /dashboard/counters („Death-/Win-/Custom-Counter"). Automations können diese Counter lesen/schreiben, aber angelegt und verwaltet werden sie dort, nicht im Automations-Bereich. Eine eigene Seite /dashboard/automations/webhooks gibt es ebenfalls nicht — die Webhook-Zugangsdaten (URL, Secret, Signatur-Pflicht) einer einzelnen Regel holst du dir direkt im Regel-Editor selbst, sobald der Trigger Webhook empfangen gewählt ist (siehe unten).

/dashboard/automation-variables, /dashboard/automation-debug, /dashboard/automation-runs und /dashboard/automation-queues sind als Power-Tier markiert — auf kleineren Plänen siehst du sie im Menü evtl. nur abgegraut mit Upgrade-Hinweis.

Anatomie einer Automation

Jede Automation-Regel (automation_rules-Zeile im Backend) besteht aus:

Trigger — was startet sie. Es gibt weit mehr als „Twitch-Event" — siehe Tabelle unten.
Conditions — optionale Bedingungen, z. B. message_contains, time_window (Stunde von–bis, UTC, keine konfigurierbare Zeitzone), oder generische event_field_equals / event_field_gt / event_field_lt / event_field_in_array auf beliebige Felder des Trigger-Events. (Korrektur: viewer_segment existiert zwar als alter Condition-Typ im Backend-Code, ist aber im aktuellen Condition-Schema der Automations (ConditionEvaluator::knownTypes()) nicht enthalten und über den Automation-Editor nicht nutzbar — totes Legacy-Feld. Auch der Feldname war falsch: es heißt event_field_in_array, nicht event_field_in.)
Actions — eine geordnete Liste von Schritten, die nacheinander ausgeführt werden (inkl. stage_delay für dramatisches Timing zwischen zwei Actions).
Cooldowns / User-Locks — siehe eigene Seite.

Im Builder (« Neue Automation » auf /dashboard/automations) ziehst du das per Formular zusammen, ohne Code — mit Ausnahme der Action script_block, die eine sichere, sandboxed Ausdrucks-Sprache (kein eval) für Power-User bereitstellt.

Trigger-Typen — die echte Bandbreite

Die Trigger-Registry ist deutlich größer, als „Twitch-Event, Reward, Chat-Befehl, Timer" vermuten lässt. Auszug nach Kategorie (Stand: aktueller Produktions-Code):

Kategorie	Beispiele
Twitch Core	`follow`, `sub`, `resub`, `gift_sub`, `sub_prime`, `sub_prime_upgrade`, `raid`, `raid_outgoing`, `cheer`, `channel_points_redemption`
Stream-Lifecycle	`stream_online`, `stream_offline`, `stream_category_change` (feuert nur bei echtem Kategorie-Wechsel, nicht bei reinem Titel-/Sprachwechsel), `ad_break_begin`
Hype/Goal	`hype_train_begin`/`_progress`/`_end`, `goal_progress`
Synthetische Aggregat-Trigger	`gift_bomb` (5+ Gift-Subs in 30 s, Worker-seitig via Redis erkannt), `first_chatter`, `bits_milestone`, `subscriber_milestone`, `chat_message_count_milestone`, `viewer_count_milestone`, `pyramid_detected`
Chat/Command	`chat_message`, `command_used`, `command_used_with_arg` (parst `!so <user>` → `ctx.event.arg`)
Donations	`donation_received`, `donation_threshold` (ab konfigurierbarem Mindestbetrag)
Externe Integrationen	`spotify_track_started`/`_changed`/`_paused`/`_resumed`/`_device_changed`, `game.steam_achievement_unlocked`, `game_stat` und `game_watcher_event` (Game-Watcher-Bridge), `football_goal`/`_match_start`/`_match_end`/`_card`
Chatlix-eigene Features	`shoutout_started`/`_displayed`, `gaming_queue_joined`/`_left`/`_called`/`_playing`/`_done`/`_skipped`/`_empty`/`_full`/`_paused`/`_unpaused`, `giveaway_entry`, `giveaway_drawn`, `songrequest_received`, `minigame_command_invoked`
Timer / Manuell / Webhook	`timer` (Intervall 60 s – 24 h), `webhook_received` (öffentlicher POST-Endpoint pro Regel)
Lokale Hardware (Chatlix Connect nötig)	`local.midi.note`, `local.midi.control_change`, `local.gamepad.button`, `local.gamepad.axis`, `local.voice.phrase`, `local.hotkey`, `local.streamdeck.button`

Für die meisten Trigger bekommst du im Condition-Editor Zugriff auf die konkreten Event-Felder (z. B. {event.stat_value}, {event.rarity_bucket}, {event.tournament}) — schau in den jeweiligen Fach-Wiki-Büchern (Rewards, Overlay, Loyalty, Football) nach den genauen Feldnamen, wenn du tiefer filtern willst.

Ad-Break-Automation — Sonderfall, kein Extra-System

Die „Ad-Break-Automation" ist keine separate Funktion neben Automations, sondern schlicht der Trigger ad_break_begin (EventSub channel.ad_break.begin, Scope channel:read:ads) plus einer beliebigen Action-Kette. Es gibt dafür einen fertigen Logic-Pack ad_break_bot_message_v1 („Twitch Werbung — Chat-Hinweis"), der bei Werbebeginn automatisch eine Chat-Nachricht postet. Willst du mehr als nur Chat (z. B. Szenenwechsel auf eine „Wir sind gleich zurück"-Szene, Overlay-Timer starten, Sound abspielen), baust du das als normale Multi-Action-Automation mit diesem Trigger — es gibt keinen separaten „Ad-Break-Modus" im Dashboard.

Action-Typen — mehr als Sound/Overlay/Chat

Auch die Action-Seite ist groß gewachsen. Grobe Einteilung nach „wo läuft das":

Cloud-seitig, kein Zusatz-Setup nötig: send_chat, send_announcement, timeout_user, ban_user, delete_message, add_points, add_vip/remove_vip/remove_mod, set_stream_title, set_stream_category, clip_create, shoutout_user, set_variable, increment_counter, set_label, create_redemption_note, add_to_queue, webhook/webhook_send (mit SSRF-Schutz — interne/private IPs werden geblockt).
Overlay-Actions: trigger_overlay_alert, set_overlay_counter, set_element_visibility, set_element_text, switch_overlay_scene, show_sprite_asset/show_sprite_tts_asset (Sprite Studio), emote_storm, celebration_trigger (Confetti & Co., Free-Plan nur Confetti), overlay_burst (mehrere Alerts in Folge, ein Action-Aufruf).
Sound/Sprache: soundboard_play, play_audio_asset, play_media_sound, speak_text (TTS), random_speak, random_sound.
OBS: obs_switch_scene, random_scene, obs_set_source_visibility, obs_toggle_source, obs_toggle_filter, obs_play_media, obs_set_text, obs_mute_source/obs_unmute_source, obs_set_volume, obs_trigger_hotkey. Dispatch läuft automatisch über zwei mögliche Wege: Ist Chatlix Connect online, geht die Action per WebSocket/Redis über Connect raus; ist Connect nicht online, fällt Chatlix auf eine direkt unter Integrationen hinterlegte OBS-WebSocket-Verbindung (TCP) zurück. Du brauchst also entweder Connect laufend oder eine gültige direkte OBS-Verbindung — beides gleichzeitig ist nicht nötig.
Discord: discord_send_message, discord_send_embed.
Lokale Hardware/PC-Steuerung — Chatlix Connect zwingend nötig: alle local.*-Actions (local.key_press, local.key_combo, local.gamepad_button, local.mouse_click, local.mouse_move, local.process_start, local.window_focus, local.file_write/_append, local.obs_hotkey, local.midi_output, local.sound_play). Diese laufen NICHT ohne die Chatlix-Connect-Desktop-App online und werden serverseitig zusätzlich mit einer harten Whitelist geprüft (erlaubte Tasten, keine Pfad-Injection, keine gefährlichen Kombos).
Hardware/Licht: lighting.wled.pulse, smart_light_control, device_beacon (USB-Rundumleuchte).
Sonstiges: ai_image_generate, stream_commerce_post, create_postcard_print_job, script_block (Ausdrucks-DSL für Power-User), stage_delay (Pause zwischen zwei Actions in derselben Regel, für Timing-Effekte).

Faustregel: Sobald eine Action mit local. beginnt oder direkt deine Maus/Tastatur/USB-Geräte anfasst, muss Chatlix Connect auf dem Stream-Rechner laufen und online sein — sonst bleibt die Action in der Queue hängen bzw. schlägt fehl. Alles andere läuft rein cloud-seitig. Details zu Connect: Buch Connect.

Routen / API (Auszug)

GET/POST /v1/automations — Liste / neue Regel anlegen (Plan-Limit automations_max wird hier geprüft, HTTP 402 bei Überschreitung).
GET/PUT/DELETE /v1/automations/{id}, POST /v1/automations/{id}/toggle, POST /v1/automations/{id}/re-enable.
POST /v1/automations/{id}/test, POST /v1/automations/{id}/test-fire — Dry-Run bzw. echter Testlauf.
GET /v1/automations/{id}/webhook-info, POST /v1/automations/{id}/webhook-require-signature, POST /v1/automations/{id}/rotate-webhook-secret — Zugangsdaten für den Trigger webhook_received.
GET /v1/automations/export, POST /v1/automations/import/preview, POST /v1/automations/import — Portabilität (Export/Import einer Regel als JSON-Envelope, inkl. Secret-Redaction).
GET /v1/automations/templates — ältere Kategorie-Templates (Bibliothek unter /dashboard/automation-templates).
GET /v1/automations/logic-packs, POST /v1/automations/logic-packs/{id}/preview, POST /v1/automations/logic-packs/{id}/apply — neueres, textbasiertes Pack-System (Karte oben auf /dashboard/automations). Angewendete Packs landen immer deaktiviert (is_enabled = false) — du musst sie nach Prüfung selbst einschalten.
POST /webhook/automations/{id} — öffentlicher Empfangs-Endpoint für den Trigger webhook_received (Legacy: ?secret=... in der Query; empfohlen: HMAC-Header X-Chatlix-Signature: t=...,v1=hex).

Internal Pipeline 200/ok:false

Chatlix' interne Worker→PHP-Endpoints geben fachliche Fehler mit HTTP 200 + JSON {"ok": false, "error": "..."} zurück, nicht mit 4xx/5xx. Das verhindert dumme Retry-Loops in Workern. Bindest du selbst externe Webhooks an, plane ähnlich — Chatlix retried bei 5xx auch von außen.

Service-Struktur (zum Verstehen, falls was hakt)

Backend-Logik liegt in Chatlix\Service\Automation\ und Chatlix\Service\AutomationService:

ActionExecutor — validiert Config pro Action-Typ, führt sie aus (oder im Dry-Run: nur Validierung + {type}_would_run).
ConditionEvaluator — wertet Conditions gegen das Trigger-Event aus.
CooldownStore — atomare DB-Cooldowns (claim-before-execute, release-on-failure).
AutomationUserLockService — Once-per-Stream/Day/Ever-Sperren, dünner Wrapper auf CooldownStore (kein Redis mehr nötig).
AutomationTemplatePacks — die Logic-Packs.
AutomationPortability — Export/Import/Redaction.
VariableStore / CounterStore — Variablen- und Counter-Persistenz.

Wenn etwas kaputt ist: /dashboard/automation-debug zeigt dir, welche Stage (Trigger-Match, Condition, welche Action) geknallt hat.

Plan-Limits

Zwei Deckel greifen unabhängig voneinander:

Anzahl Automations (automations_max): Free 10, höhere Pläne 30 / 100 / 300, Enterprise bis 1.000. Beim Anlegen prüft POST /v1/automations das Limit und antwortet mit HTTP 402, wenn du drüber willst.
Actions pro Automation (actions_per_automation): 5 auf Free, steigend bis 25-30 auf den Top-Plänen. Hartes Server-Limit unabhängig vom Plan: maximal 20 Actions pro Regel.

Bei Multi-Channel-Regeln (dieselbe Automation über mehrere deiner Twitch-Kanäle) zählt nur die logische Regel gegen dein Limit, nicht jede Kanal-Kopie einzeln — 10 Regeln über 5 Kanäle sind intern 50 Zeilen, aber nur 10 gegen dein Kontingent. Multi-Channel-Setups brauchen mindestens den Pro-Plan.

Automations exportieren/importieren

Über GET /v1/automations/export kannst du deine Regeln als JSON exportieren — z. B. um sie auf einen zweiten Account zu übertragen oder mit anderen Streamern zu teilen. Wichtig für die Sicherheit: der Export ist strikt auf deine eigenen Regeln beschränkt, enthält nie Laufzeitdaten (IDs, Channel, Fehlerzähler, Zeitstempel) und redigiert alle Geheimnisse (Webhook-Secrets, Authorization-Header, API-Keys, Discord-Webhook-Token) zu einem (redacted)-Platzhalter. Beim Import (POST /v1/automations/import/preview zum Prüfen, POST /v1/automations/import zum Anlegen) entstehen komplett neue, deaktivierte Regeln unter deinem Account — Secrets musst du danach neu setzen (z. B. Webhook-Secret neu rotieren, Discord-URL neu eintragen).

Was du auf den nächsten Seiten findest

Erste Automation bauen — Schritt-für-Schritt eine simple Automation.
Cooldowns — Anti-Spam, inkl. der Once-per-Stream/Day/Ever-Sperren.
Automation-Templates — Logic-Packs und die klassische Template-Bibliothek.

Neue Auslöser seit August 2026

Zwei Auslöser sind neu hinzugekommen und tauchen in älteren Beschreibungen noch nicht auf:

🎡 Glücksrad-Ergebnis

Feuert, wenn ein Glücksrad auf einem Feld stehen bleibt. Auswählbar sind das Rad (oder „jedes Glücksrad“) und worauf reagiert werden soll: jedes Feld, nur Gewinner, nur Verlierer, nur neutrale — oder genau ein bestimmtes Feld.

Wichtig: Ausgelöst wird erst, wenn das Rad steht, nicht beim Losdrehen. Einzelheiten im Buch „Glücksrad“.

betterplace-Spende

Feuert bei einer neuen Spende auf ein betterplace.org-Spendenprojekt. In der Automation trägst du ein:

betterplace-Link oder Event-Nr. — die Adresse deiner Spendenaktion genügt, die Nummer wird daraus gelesen
Intervall (Sekunden) — wie oft nachgesehen wird, zwischen 60 und 86400
Nur bei Betrag — optionale Betragsgrenze: egal — jede Spende, mindestens, mehr als, genau, höchstens oder weniger als

Für „ab 10 € anders reagieren als darunter“ legst du zwei Automationen an — eine mit mehr als 10, eine mit höchstens 10. Zusammen decken sie jeden Betrag genau einmal ab.

Abgefragt wird ausschließlich die öffentliche betterplace-Schnittstelle; ein Zugangsschlüssel ist nicht nötig. Enthält der eingetragene Link ein Token, wird es verworfen.