Category: Technology

Posted on

OpenClaw Maintenance mit Claude Code

Der Schmerz der OpenClaw Maintenance

OpenClaw ist ein Produkt des Vibe Coding. Man sagt, die Qualität des Code sei — hmm — optimierungsfähig bis fragwürdig. Ich kann das nicht wirklich beurteilen — ich bin kein (ausreichend guter) Entwickler. 

Was mir aber recht schnell klar wurde, nachdem ich seit Anfang 2026 mit OpenClaw experimentiere, dass selbst ein einfaches Update ziemlich herausfordernd sein kann. Während ich eines im Februar noch selbst durchführen und anschließend diverse Unstimmigkeiten beseitigen konnte, ging OpenClaw beim Wechsel von v2026.4.12 auf v2026.7.1–2 komplett auf die Bretter. 

Mit Hilfe von Claude konnte ich das zwar alles beheben, aber es war trotzdem extrem zeitaufwändig. Ich habe nämlich den “klassischen” Claude Chat benutzt, was dann zu ziemlichen Copy ‘n Paste-Orgien führte: Problem (Text oder Screenshot) und mit Bitte um Lösung prompten, Claudes Lösungsvorschlag sichten und ins Terminal pasten, Ergebnis und Logs wieder zurück zu Claude. 

Nach 2h mehr oder minder konstantem Rumgewerkel fasste Claude dann das Ergebnis wie folgt zusammen: 

- Gateway sauber auf 2026.7.1-2, über npm/stable statt dem alten Git-Checkout
- Alle Workspace-Daten erhalten
- Command Owner gesetzt
- pdf-tools und mcp-hass wieder aktiv
- iMessage komplett von BlueBubbles auf das native imsg-Plugin migriert – DM und Gruppe laufen

Das gesamte Vorgehen, das Claude wählte, um die Probleme nach der Migration von .4.12 auf .7.1–2 zu testen, zu analysieren, zu fixen und erneut zu testen war dabei extrem beeindruckend. Nach ich diesen Erfahrungsbericht dann auf Mastodon postete, meinte dann jemand, dass er Wartungsaufgaben durch ChatGPT Codex durchführen lässt. 

Da eines meiner Teams sehr gute Erfahrungen mit Codex gemacht hat, dachte ich mir, dass nun der Zeitpunkt gekommen ist, an dem ich mir hierzu mal selbst Hands-on-Erfahrungen hole — allerdings nicht mit Codex, sondern mit Claude Code.

OpenClaw Maintenance mit Claude Code

Hintergrund

Mein OpenClaw läuft auf einem dedizierten Mac Studio mit einer eigenen UserID und normalen Nutzerrechten (kein admin, kein root, kein sudo), hat eine eigene Identität im Netz (Max), eine eigene Mailadresse und kann nur auf seine eigene Daten schreibend zugreifen. Max kann nur lesend auf sehr wenige meiner Daten zugreifen, die ich hierfür extra selektiert habe (bspw. eine Obsidian Knowledge Base). Kommunizieren kann Max via Telegram, iMessage und Email. Ansonsten kann er ins Web gehen via Brave Search, WebFetch und Brave Browser. Auf extra für diesen Zweck selektierte Entitäten der Hausautomation kann er via Home Assistant MCP zugreifen, den Status auslesen und bei einigen wenigen den Status ändern (bspw. einige Schalter schalten oder auch die Temperatur von Klimaanlage oder Whirlpool einstellen). 

Die Aufgabe

Mein Ziel bei Max war und ist es, einen OpenClaw-Playground zu haben, bei dem nichts kaputt gehen kann, wenn ich damit experimentiere oder eine Prompt Injection das Ding Amok laufen lässt. Und wenn doch etwas kaputt geht — oder sogar alles — dann soll das schlichtweg nichts ausmachen, weil meine Daten getrennt sind und ich die Maschine plattmachen und wieder komplett neu aufbauen kann. Selbst eine potentielle Komplettexfiltration der Daten, die Max lesen kann, sollte kein Problem sein.

Ein weiteres Ziel ist Max’ Autarkie: Der gesamte Software-Stack, den der User “Max” benötigt, um OpenClaw mit Ollama und allen zugehörigen Skills und Tools laufen zu lassen, soll komplett in Max’ User-Kontext laufen und sich dort maintainen lassen. 

Dieses Ziel habe ich als Aufgabe formuliert an Claude Code gegeben. 

Und was soll ich sagen? Es hat grandios gut funktioniert: Claude Code zunächst unter einem Admin laufen gelassen, um die Abhängigkeiten zu Tools analysieren zu lassen, die Max nicht selbst maintainen kann (kein sudo) und soll (Impact auf andere User). Dann diese Abhängigkeiten aufgelöst: Claude Code unter Max laufen lassen und alles in seinem User-Kontext beschafft und installiert, was er benötigt.

Weil das so extrem gut funktioniert hat, habe ich anschließend noch mehrere Optimierung an OpenClaw vorgenommen: Performance optimiert, E‑Mail von Apple Mail MCP auf Himalaya umgestellt, Finetuning an iMessage- und Telegram-Gruppen, etc.

Abschließend habe ich Claude Code gebeten, seine gesamte Arbeit in einer strukturierten MD-Datei zu dokumentieren. Und da ich bei jedem Schritt dabei war, den er gemacht hat, kann ich sagen: Exzellente Arbeit! Sowohl die Analyse, die Arbeitsplanung, die Durchführung, das Testen und auch die abschließende Dokumentation: Einfach nur Wow. 

Um einen Eindruck von Claudes Fähigkeiten zu bekommen — und ich bin sicher nur an der Oberfläche gekratzt zu haben — folgt hier die Dokumentation, die er erstellt hat.

OpenClaw / Mac Studio — Änderungsprotokoll

Dokumentation aller Änderungen, die Claude am OpenClaw-Setup auf dem Mac Studio (macstudio*****, User max****) vorgenommen hat. Stand: 29. Juli 2026.

1 Node.js / nvm — Autonomie von max****

Ziel: OpenClaw und alle Abhängigkeiten sollen vollständig unter dem Nicht-Admin-User max**** laufen, unabhängig vom Admin-Account b****** und dessen Homebrew-Installation (/opt/homebrew, für max**** nicht beschreibbar).

  • nvm installiert (offizielles Install-Skript), Node 22.23.1 als Default gesetzt
  • ~/.npmrc bereinigt (prefix=...-Zeile entfernt, die mit nvm kollidierte)
  • openclaw und mcporter unter nvm neu installiert (parallel zur bestehenden Homebrew-Node-Installation)
  • uv installiert (~/.local/bin, kein Homebrew nötig) — für spätere Python-Abhängigkeiten ohne Admin-Rechte

2 OpenClaw-Gateway-Service

  • Service-PATH (~/.openclaw/service-env/ai.openclaw.gateway.env) manuell um ~/.local/bin ergänzt, da der reguläre gateway install-Reinstall die PATH nicht korrekt aus der interaktiven Shell übernimmt (betrifft z.B. Erkennung von himalaya, siehe Abschnitt 8)
  • openclaw doctor --repair mehrfach ausgeführt (Plugin-Registry-Reparatur nach nvm-Umstieg, Telegram-groupAllowFrom-Korrektur)
  • Tool-Sichtbarkeit tools.sessions.visibility von Default tree auf agent gesetzt — notwendig, damit isolierte Cron-Sessions (z.B. der Memory-Sync-Job) auf andere Sessions desselben Agents zugreifen können (sessions_history)

3 Apple Mail MCP (apple-mail-mcp) — Repariert, dann komplett abgelöst

3.1 Ursprüngliche Reparatur (mittlerweile obsolet, siehe Abschnitt 7)

  • Python-venv des Skills war leer/defekt (Python 3.9, ModuleNotFoundError: mcp) → mit uv + Python 3.12 neu aufgebaut
  • Falsche venv zuerst repariert (plugin/venv statt der tatsächlich von mcporter.json referenzierten Top-Level-venv) → korrigiert
  • macOS-Automation-Berechtigungen (AppleEvents) für zwei Prozess-Identitäten erteilt (Terminal, Homebrew-Node 22.23.1) — jeweils per physischer Bestätigung am Bildschirm
  • Syntax-Bug in SKILL.md: Beispiele nutzten ungültige tool(arg: "value")-Syntax statt key=value → korrigiert (verursachte zsh:1: number expected)
  • Zeilenumbruch-Bug: escape_applescript() in core.py wandelte echte Zeilenumbrüche in den literalen Text \n um (AppleScript kennt kein \n-Escape) → neue Funktion escape_applescript_multiline() ergänzt, nutzt AppleScripts & return &-Verkettung
  • Zitat-Bug: Mail.app verpackt per content-Property gesetzten Text automatisch in ein <blockquote> (Darstellung als Zitat mit blauem Balken auf iOS) — als Workaround auf Zwischenablage-Paste umgestellt (compose_emailgeneriert automatisch simples HTML via _build_html_from_text(), wenn kein body_html übergeben wird)

3.2 Warum trotzdem abgelöst

Die Paste-basierte Lösung hängt an macOS Accessibility/UI-Automatisierung (System Events), die sich als grundsätzlich instabil erwies (Fenster-Erkennung fiel wiederholt und unvorhersehbar aus, u.a. mit einem realen Mail-Verlust bei einem unbeaufsichtigten Cron-Lauf zur Folge). Auf Wunsch des Nutzers komplett durch eine protokoll-basierte Lösung ersetzt (Abschnitt 7).

4 Cron-Jobs — Diverse Fixes

JobFix
Täglicher Memory-Log Eintrag(a) tools.sessions.visibility global auf agent gesetzt (Grundproblem: isolierte Cron-Session konnte andere Sessions nicht lesen → sessions_history lief ins Leere, Job meldete fälschlich MEMORY_SKIP). (b) Prompt umgeschrieben: feste Session-Keys statt unzuverlässiger sessions_list-Suche; alle 4 relevanten Kanäle (Telegram/iMessage × direkt/Gruppe) statt nur einem. © Explizite Regel ergänzt: MEMORY_SKIP-Antwort und tatsächliches Schreiben schließen sich gegenseitig aus (behebt Fälle, in denen der Job schrieb, aber trotzdem “Skip” meldete).
Morgens — News“Kein \n”-Formatierungs-Notbremse entfernt (durch den Zeilenumbruch-Fix in Abschnitt 3 nicht mehr nötig), echte Absatzstruktur erlaubt. Später auf Himalaya umgestellt (Abschnitt 7).
Donnerstagsnachmittags — WochenendeSuche auf nichtkommerzielle Veranstaltungskalender eingeschränkt. Timeout-Fehler behoben (payload.timeoutSeconds von Default 600s auf 1200s erhöht, da Recherche + Versand bei diesem Job regelmäßig >600s brauchten). Später auf Himalaya umgestellt.
Donnerstagsnachmittags — J**Timeout ebenfalls auf 1200s erhöht (gleicher Grund).

5 Tailscale — Fernzugriff für die iOS-App

  • Tailscale (App Store, unter max**** eigener Apple-ID/Tailscale-Identität, getrennt von b****) installiert und eingerichtet
  • Gateway umgestellt: gateway.bind: loopback (kein LAN-Zugriff mehr) + gateway.tailscale.mode: serve(nur innerhalb des eigenen Tailnets erreichbar, kein öffentliches Funnel)
  • Erreichbar unter wss://macstudio*****.*.*.*
  • Für b***** iPhone: separates, eigenes Tailscale-Konto empfohlen, nur der Mac-Studio-Host gezielt geteilt (statt volles Tailnet-Mitglied)
  • Device-Pairing der iOS-App mehrfach neu aufgesetzt (Node-Rolle freigegeben für Kamera/Fotos-Zugriff)

Offen/ungelöst: Bild- und Text-Versand aus der iOS-App blieb sporadisch in der lokalen Warteschlange hängen (“In Warteschlange”, nie beim Gateway angekommen). Ursache nicht abschließend geklärt — es zeigte sich zusätzlich eine instabile Accessibility-Erkennung von Mail-Fenstern durch macOS selbst (siehe Abschnitt 3), möglicherweise ein verwandtes systemseitiges Phänomen. Nutzer hat das Thema vorerst zurückgestellt (Telegram funktioniert zuverlässig für Bilder).

6 Gruppen-Verhalten (Telegram & iMessage)

  • Problem: Max antwortete in der gemeinsamen Gruppe (Bodo & Y****) auf jede Nachricht, auch wenn nur Y**** direkt angesprochen wurde
  • requireMention: true für die Telegram-Gruppe UND für alle iMessage-Gruppen (channels.imessage.groups.*.requireMention) gesetzt
  • Globales Trigger-Wort ergänzt: messages.groupChat.mentionPatterns: ["\\bmax\\b"] — Max reagiert jetzt nur bei @max****, direkter Antwort auf seine eigene Nachricht, oder dem Wort “Max” im Text. Gilt für beide (Bodo und Y****) gleichermaßen.

7 Mail-Migration: Apple Mail MCP → Himalaya CLI

Vollständige Ablösung der AppleScript/Mail.app-Automatisierung durch direktes SMTP/IMAP.

  • Himalaya CLI installiert (curl ... | PREFIX=~/.local sh, kein Homebrew nötig), Version 2.0.0
  • Skill in OpenClaw aktiviert (skills.entries.himalaya.enabled: true), lag zuvor deaktiviert unter skills.entries.<name>.enabled (unabhängig von Binary-Verfügbarkeit)
  • ~/.config/himalaya/config.toml angelegt (iCloud SMTP smtp.mail.me.com:587, IMAP imap.mail.me.com:993)
  • Sicheres Credential-Handling: App-spezifisches Passwort liegt in der macOS-Keychain (security add-generic-password ... -s himalaya-icloud), Config referenziert es nur per password.command — kein Klartext-Passwort in Dateien
  • Bundled SKILL.md hatte veraltete Befehlssyntax (z.B. folder statt mailbox, message write statt message compose --send) — korrigiert auf die tatsächliche v2.0‑Syntax
  • End-to-end getestet: Senden (SMTP) und Empfangen/Lesen (IMAP) funktionieren zuverlässig, deutlich schneller und stabiler als die alte Mail.app-Automatisierung
  • Cron-Jobs Morgens — News und Donnerstagsnachmittags — Wochenende auf himalaya message compose ... --send --save "Sent Messages" umgestellt; explizite Anweisung, Erfolg nur bei tatsächlicher Erfolgsmeldung zu melden

7.1 Vollständige Bereinigung alter Referenzen

  • apple-mail-mcp-Skill deaktiviert (skills.entries.apple-mail-mcp.enabled: false)
  • apple-mail-mcp-Eintrag aus beiden aktiven mcporter.json-Configs entfernt
  • AGENTS.md: Mail-Instruktion auf Himalaya umgeschrieben, mcporter/apple-mail-mcp für Mail explizit verboten
  • MCP-SYNTAX.md: Enthielt noch die generell falsche mcporter-Syntax (Doppelpunkt-Stil, Ursache des ursprünglichen zsh-Bugs) — korrigiert auf key=value; Mail-Beispiel durch Himalaya-Verweis ersetzt
  • MEMORY.md: Komplette alte apple-mail-mcp-Befehlsreferenz durch Himalaya-Referenz ersetzt
  • Sieben veraltete, seit Monaten ungenutzte Einzel-Skripte gelöscht (send_event_email.py/.sh, email_reader.py, tmp_send_email.py, email_venues_2026_04_30.py, daily/newsletter_email.py, tmp/send_email.py)

8 Inbox-Schutz gegen Prompt Injection (Himalaya-Äquivalent zur Mail.app-Regel)

Ersetzt/ergänzt die bestehende Mail.app-Regel (client-seitig, nur aktiv wenn Mail.app läuft) durch einen Himalaya-nativen, deterministischen Mechanismus.

  • Neues Skript: ~/.openclaw/workspace/scripts/inbox_allowlist_filter.py
    • Prüft ausschließlich den Absender (From-Header über envelope list --json), liest niemals den Mail-Body
    • Verschiebt alle Nachrichten von nicht erlaubten Absendern nach “Deleted Messages”
    • Allowlist: …
  • Als Cron-Job vom Typ “command” eingerichtet (Inbox Allowlist Filter, alle 10 Minuten) — bewusst kein LLM-Turn, rein deterministisch, dadurch von Natur aus immun gegen Prompt-Injection-Versuche im Mail-Inhalt
  • Benachrichtigungen deaktiviert (würde sonst alle 10 Minuten auch “nichts gefunden” melden); Verlauf über openclaw cron runs einsehbar
  • Getestet mit simulierten Absendern außerhalb der Allowlist (inkl. eines Prompt-Injection-Textbeispiels) — korrekt erkannt und in den Papierkorb verschoben

9 Ollama / Performance

  • keep_alive: "24h" für das aktive Modell (qwen3.6:35b-a3b-q4_K_M) gesetzt — Standard war 5 Minuten, danach musste das Modell bei jeder Anfrage neu geladen werden (gemessen: 7,2s Kaltstart vs. 132ms warm)
  • temperature: 0.7, top_p: 0.9 gesetzt (Standard war temperature=1, top_p=0.95) — Milderung des gelegentlichen Einstreuens chinesischer Schriftzeichen (bekanntes Qwen-Phänomen, keine 100%ige Garantie)
  • Geprüft, aber unverändert gelassen (Nutzer-Entscheidung): OLLAMA_NUM_PARALLEL=1, OLLAMA_KV_CACHE_TYPE(Standard) — beides bräuchte einen Ollama-Neustart mit geänderten Server-Umgebungsvariablen
  • web_search-Tool wieder aktiviert (tools.web.search.provider: "brave") — Brave-API-Key war bereits als Plugin-Credential vorhanden, aber nicht mit dem web_search-Tool verknüpft

10 Aktueller Stand (Zusammenfassung)

  • Mail: läuft vollständig über Himalaya/SMTP/IMAP, keine Mail.app-Automatisierung mehr für Senden/Empfangen durch Max; Passwort sicher in der Keychain
  • Cron-Jobs: alle mail-versendenden Jobs auf Himalaya umgestellt, Timeouts und Formatierung korrigiert, Memory-Sync-Job liest zuverlässig alle 4 Kanäle
  • Fernzugriff: Tailscale eingerichtet und aktiv; iOS-App-Nachrichtenversand mit Bildern bleibt ein offener, nicht abschließend gelöster Punkt
  • Gruppen: Max reagiert nur noch auf direkte Ansprache (Name/Mention/Reply), nicht mehr auf jede Nachricht
  • Sicherheit: Absender-Allowlist-Filter als eigenständige, KI-freie Schutzschicht gegen Prompt Injection über Mail aktiv
  • Performance: Modell bleibt 24h warm geladen, Sampling leicht konservativer eingestellt

Posted on

Presence Detection with RFID: Frient/Develco KEPZB-110 RFID Integration in Home Assistant (ZHA)

Initial Situation

In our Home Assistant-based setup we do presence detection with device trackers of the mobile Home Assistant app on our mobiles, i.e. our iPhone is our presence locator and Home Assistant (HA) knows if we are at home or not. This is fine for family members, but what to do if we have a longer absence from home and there is some family-external who takes care of the cats?

I didn’t want to have them installing the Home Assistant app on their devices for tracking their location or scanning a NFC tag to indicate, that they are at our home. I was looking from something less intrusive. My idea was to give them a physical key and a RFID tag so that they can unlock the door and once they are in they could check-in by scanning their RFID tag. By that our Home Assistant would know, that someone arrived at home who is authorized to be there and would turn on all required automations, e.g. motion-based lighting.

Since it was quite hard to find information on RFID readers, integrating them with Home Assistant ZHA and using RFID tags practically in Home Assistant, I decided to write down my experience for others and give some instructions so that they can save time.

Hardware

From my time with Z‑Wave on openHAB [1] I still have a RFID scanner from Zipato [2], but I couldn’t get it to work with my Thinka Z‑Wave hub [3]. And if it doesn’t work with Thinka, it doesn’t work with Home Assistant, since I have integrated Thinka in there as an HomeKit device.

So, what to do? I was doing some research on battery-powered RFID-scanners, which integrate with Home Assistant. Actually I was wondering, that I couldn’t find that many. At the end I was looking a bit deeper into the KEPZB-110 Intelligent Keypad from Frient [4]. It is a Zigbee-based battery-powered RFID reader, for which users confirmed to have it successfully integrated into HA.

Integration

I am using Zigbee since the first Philips Hue bridge [5] and I have two of them to manage the majority of our lights at home. But it was quite clear that even if Hue is a Zigbee-based system, it is not the way how to connect an RFID reader. So I was extending my research into Zigbee and Home Assistant and found out that there are two ways to do it, either by Zigbee2MQTT (Z2M, [6]) or by Zigbee Home Assistant (ZHA, [7]). Because I didn’t want to have another component to be setup (MQTT) and because ZHA is natively supported by my Home Assistant Yellow [7], I decided to go for ZHA.

I was a bit concerned to bring up the third Zigbee bridge in our home because I feared interferences. At the end it turned out that all is working fine. I put the three bridges each on their own channel and by that lighting and the RFID reader work fine beside each other.

Preparation

Activation of ZHA on Home Assistant Yellow

ZHA come with Home Assistant Yellow. Activating it is quite easy.

Instructions

  1. Select Configure in System/Hardware
  1. Select Switch between Zigbee or Thread firmware and the Zigbee and follow the instructions

Pairing the KEPZB-110 Keypad with ZHA

When ZHA is running in Home Assistant the new integration Zigbee Home Automation should show up. From there it is easy to start pairing.

Instructions

  1. Select Configure and then Add Device.
  1. Follow the Frient instructions [9] for setting the device into pairing mode.

Once the device has been included into the Zigbee network, it should be available in Home Assistant.

Testing the Keypad with a Numeric Code

For test the keypad it is required to define a numeric code. Interestingly, this is not being done at the KEPZB-110 device in Home Assistant, but at the level of the Zigbee Home Automation integration.

Instructions for Defining a Master Code

  1. Open Devices & Services
  2. Select Zigbee Home Automation
  3. Click on Configure
  4. Find the section Alarm Control Panel Options 
  5. Define your Master Code

Instructions for Testing

Once the code has been defined, test it as follows:

  1. Press Lock on the physical Frient keypad
  2. Punch your Master code into the keypad followed by the Unlock key.

If successful, the Alarm Control Panel in Home Assistant should switch to Disarmed.

RFID Tags and the ID in RFID

Choosing the Right RFID Tags for KEPZB-110

From my time with the Zipato RFID reader I had three RFID tags. It turned out they don’t work with the Frient keypad. The KEPZB-110 requires a RFID chip based on ISO14443 Type A (MIFARE Classic) [10].

Getting the ID of an RFID Tag

While it is easy to get the keypad into Home Assistant, it seemed to me quite more complicated to get it working with more than one key (master key) or even RFID. I was looking into various Blueprints [12, 13] tried them without success before I finally found a french website [13], which explained how to find out the actual ID of an RFID tag and how to use it in further automations.

Instructions

  1. Head to Developer tools in Home Assistant
  2. Select Events, enter “zha_event” into Listen to events and press Start Listening
  1. Scan the RFID tag (hold close to the middle of the keypad) and press the Unlockbutton
  2. Look into the captured events. You find the ID of the RFID tag in the argument “code” of the payload

Presence Detection Based on RFID

Defining Persons for RFID Tags

Automations in Home Assistant can be either triggered or conditionally executed based on the presence of persons (people). If RFID tags shall be used to support this functionality it is required to define people and “attach” the RFID tags as Track Deviceto them, so that the presence of the respective person can be determined.

Instructions

  1. Head to the People section in Home Assistant
  2. Create a person, e.g. “Green RFID”. Leave the field Track device blank for the time being

Defining Device Trackers for RFID Tags

In former times Device Trackers in Home Assistant were created by the file known_devices.yaml. This is not supported any longer. It took me a while to understand, how these devices are created now.

It is quite easy. They are simply created with an action called Device Trackers: See. As soon as this action is being executed (e.g. in an automation), an entity is being automatically created for the device tracker.

Instructions

Execute the action Device Trackers: See with the attributes DeviceID and Location (either “home” or “not_home”).

Building an Automation for Using RFID for Presence Detection

Once the before-mentioned action has been executed, the device tracker Green_RFID_tracker can be linked to the person Green RFID in the People section of Home Assistant.

The use case for tracking a person at home with an RFID tag is as follows.

Precondition: Nobody at home. Alarm panel of the Frient Keypad is in mode Away

  1. The person enters the home and scans their RFID tag followed by pressing the Unlock button: Alarm panel switches to Disarmed. The person is being checked-into the Home zone.
  2. The person leaves and press the Lock button: Alarm panel switches to Away. The person is being checked-out of the Home zone.

Building an automation is quite easy. 

Instructions 

  1. When: Add a trigger for zha_event event is fired. Use the before captured ID of the RFID tags as code
  2. Then Do: Disarm the keypad and perform the action Device tracker: See

An automation for checking out is more or less the opposite of those before. The only difference is, that the RFID tag is not required to be presented. It is sufficient to simply press the Lock button on the keypad.

This behavior can be changed by enforcing the option Code required for arming actions in the Alarm Control Panel Options of the Zigbee Home Automation integration.

References