Direkt zum Hauptinhalt

Erste Automation bauen

Wir bauen jetzt eine Automation, die etwas tut, das eine einfache Reaction nicht kann: „Bei jedem 50. Cheer ein Konfetti-Overlay und eine Chat-Ansage."

Voraussetzungen

  • Twitch verknüpft, EventSub grün (Status siehe /dashboard/integrations).
  • Ein Konfetti-Overlay-Element existiert (Buch Overlay).
  • Der Twitch-Bot ist im Channel und darf Chat-Nachrichten senden.

Schritt 1 — Counter anlegen

Wir brauchen einen Counter, der jeden Cheer zählt. Wichtig: Counter sind kein Teil des Automations-Bereichs, sondern ein eigenständiges Top-Level-Feature.

  1. /dashboard/counters öffnen (nicht unter „Automation" im Menü — Counters hat einen eigenen Menüpunkt).
  2. « Neuer Counter ».
  3. Name: total_cheers.
  4. Reset-Verhalten: « Pro Stream resetten » (Alternative: « nie resetten » — wir nehmen hier pro Stream).
  5. Speichern.

Schritt 2 — Automation anlegen

  1. /dashboard/automations → « Neue Automation ».
  2. Name: Konfetti alle 50 Cheers.
  3. Trigger: cheer (im Dropdown als „Bits / Cheer" gelistet).
  4. Conditions — erstmal nichts filtern: leer lassen. Der Counter macht die Arbeit.
  5. Actions — drei Schritte in dieser Reihenfolge:
    • Action 1: increment_counter → Counter total_cheers, um 1.
    • Action 2: die dazugehörige Bedingung stellst du direkt als Condition der Automation ein, nicht als eigenen „If-Then"-Block — Chatlix' Actions laufen linear, Verzweigungen bekommst du über condition_expr pro Action (Power-Feature) oder indem du eine zweite Automation mit derselben Trigger + einer Modulo-Bedingung baust. Für dieses Beispiel: setz bei trigger_overlay_alert und send_chat jeweils ein condition_expr: total_cheers % 50 == 0.
    • Action 3: trigger_overlay_alert → dein Konfetti-Element, Dauer 4 Sekunden. condition_expr: total_cheers % 50 == 0.
    • Action 4: send_chat → Text 🎉 {user} hat den {counter:total_cheers}. Cheer ausgelöst!. Gleiches condition_expr.
  6. Speichern.

Wichtig: Im Editor referenzierst du den Counter direkt — {counter:total_cheers} als Platzhalter in Text wird zur Laufzeit durch den aktuellen Wert ersetzt. Eine reine Variable (ohne Counter-Bezug) referenzierst du dagegen mit {variablenname}.

Falls dir condition_expr pro Action zu fummelig ist: die einfachere, robustere Alternative ist eine zweite, separate Automation mit demselben Trigger cheer und einer Automation-weiten Condition event_field_equals/eigener Ausdruck auf den Counter-Wert. Für die meisten „alle N Events"-Fälle reicht das.

Schritt 3 — Testen

Geh in der Automation auf « Test » (API: POST /v1/automations/{id}/test). Du kannst ein Mock-Event setzen (z. B. Cheer mit 500 Bits) und das Verhalten vor Live-Gang prüfen. Das ist ein Dry-Run: Conditions und Action-Configs werden vollständig validiert und gerendert, aber es passiert kein echter Seiteneffekt — kein Sound spielt, kein Chat wird gepostet, der Counter zählt nicht mit. Für einen echten Testlauf mit tatsächlicher Ausführung gibt es zusätzlich « Test-Fire » (POST /v1/automations/{id}/test-fire) — der feuert wirklich, also nur nutzen, wenn du den echten Effekt sehen willst.

Schritt 4 — Live

Automation auf enabled lassen, los geht's. In /dashboard/automation-runs (Power-Tier) siehst du jeden Lauf in Echtzeit: Trigger-Event, Condition-Ergebnisse, ausgeführte Actions, Dauer, Status. Reale Status-Werte aus dem Backend: ok, condition_skip, cooldown_skip, action_failed, action_partial, depth_exceeded, dry_ok, test_ok.

Bei jedem 50., 100., 150. Cheer feuern dann Overlay und Chat-Ansage.

Anderes Beispiel — Stream-Online-Begrüßung

Noch ein typischer Use-Case: beim Stream-Start eine Sequenz fahren.

  1. Trigger: stream_online.
  2. Conditions: keine.
  3. Actions:
    • obs_switch_scene → Szene Intro.
    • stage_delay 5 s (Pause zwischen Actions in derselben Regel — dafür ist der Action-Typ da).
    • obs_switch_scene → Szene Hauptszene.
    • send_chat → Stream ist live! Viel Spaß euch allen.
    • webhook_send → POST an deinen Discord-Webhook (Body: {"content": "Stream ist live!"}).
    • set_variable → stream_started_at = aktueller Zeitstempel.

Damit hast du Intro-Sequenz, Chat-Hinweis, Discord-Push und einen Zeitstempel, den andere Automations später lesen können (z. B. für eine „Stream läuft seit X" Chat-Antwort via time_window-Condition oder eigener Logik).

Voraussetzung für die obs_switch_scene-Actions: entweder läuft Chatlix Connect auf deinem Stream-Rechner und ist online, oder du hast unter Integrationen eine direkte OBS-WebSocket-Verbindung hinterlegt. Ohne eins von beiden bleibt die Action im Run-Log mit Fehler connect_offline stehen.

Drittes Beispiel — Ad-Break-Hinweis

Ein Klassiker, der oft übersehen wird, weil er nicht wie eine „richtige" Automation aussieht:

  1. Trigger: ad_break_begin (im Dropdown „📺 Werbepause beginnt"). Braucht den Twitch-Scope channel:read:ads — falls der Trigger im Editor grau bleibt, fehlt dir der Scope; Twitch-Verknüpfung unter Integrationen neu autorisieren.
  2. Conditions: optional event_field_gt field=duration_sec value=60, falls du nur bei längeren Werbepausen reagieren willst.
  3. Actions: send_chat → z. B. Werbung läuft kurz — perfekt zum Strecken oder Trinken holen. Gleich geht's weiter ({event.duration_sec}s).

Es gibt dafür auch ein fertiges Template (ad_break_bot_message_v1, siehe Seite Automation-Templates) — das ist exakt diese Automation, nur eben schon vorgebaut. Willst du mehr als Chat (z. B. eine „Wir sind gleich zurück"-Szene, Timer-Overlay, Sound), hängst du einfach weitere Actions an dieselbe Regel — Ad-Break ist kein Sonderfall im Editor, sondern ein ganz normaler Trigger.

Variablen lesen und schreiben

Variablen-Operationen im Action-Block:

  • Setzen: Action set_variable → Name + Wert.
  • Zählen: Action increment_counter → Counter-Name + Delta (auch negativ möglich).
  • In Texten lesen: {name} für Variablen, {counter:name} für Counter (explizit unterscheidbar).

Variablen und Counter sind per Channel und überleben Streams — außer ein Counter ist explizit auf pro Stream resetten gesetzt.

Debugging

Wenn eine Automation nicht das tut, was du erwartest:

  1. /dashboard/automation-runs → letzten Lauf anklicken. Du siehst Step-by-Step, welche Condition true/false war und welche Actions liefen bzw. geskippt wurden.
  2. Bei tieferen Problemen /dashboard/automation-debug (Automation-Tester) → einzelne Regel isoliert mit Mock-Event durchspielen, ohne echte Live-Trigger abzuwarten.
  3. Schlägt eine Action fehl (z. B. Discord-Webhook antwortet mit 500), steht das im Run-Log mit Fehlercode/Response. Eine fehlgeschlagene Action bricht die Regel nicht komplett ab — die folgenden Actions laufen trotzdem (Status action_partial), es sei denn eine spätere Action hängt per branch/condition_expr logisch von der fehlgeschlagenen ab.
  4. Bleibt eine Regel dauerhaft in Fehlern hängen, greift ein interner Zähler consecutive_failure_count — bei anhaltenden Fehlern kann Chatlix die Regel automatisch deaktivieren (disabled_by_system), damit kaputte Automations nicht endlos gegen z. B. eine tote Webhook-URL feuern. Ein Run-Log-Eintrag zeigt dir, wenn das passiert ist.

Was nicht reingehört

  • Sehr kurze, einfache „Sound + Overlay"-Kombis ohne jede Bedingung bleiben besser in einer Event Reaction — schlanker und schneller zu warten.
  • Automations sind das richtige Werkzeug, sobald Bedingungen, Counter, mehrere Actions in Folge oder externe Calls ins Spiel kommen.

Nächste Seiten

  • Cooldowns — Anti-Spam-Schutz pro Automation, inkl. Once-per-Stream/Day/Ever-Sperren.
  • Automation-Templates — fertige Vorlagen und Logic-Packs, die du als Startpunkt nehmen kannst.