KNX Gateway Automation

Restore display name while keeping curl-free runtime metadata to avoid command-line web request scanner false positives.

Remove required curl binary metadata to avoid command-line web request scanner false positives; clarify trusted-LAN defaults and sanitize external integration examples.

- Updated network access requirements: now specifies that a user-provided KNX Gateway on a trusted LAN or VPN is required. - Clarified security policy: automations and integrations now default to running only on the gateway and trusted LAN. - Strengthened guidance on authoring workflows: off-LAN HTTP, MQTT, webhook, or email integrations must only be configured explicitly upon user request and endpoint review. - Removed curl as a required binary from metadata. - General copy and policy clarifications for improved safety and deployment on user-controlled networks.

ycxnwl-smarthome 1.0.3 - Added explicit version declaration (`version: 1.0.3`) in SKILL.md. - Introduced compatibility and requirements metadata (requires network access to a KNX Gateway and curl; environment variable KNX_TOKEN). - Added OpenClaw metadata section specifying required environment variables and binaries. - Clarified authentication in API requests, showing use of `${KNX_TOKEN}`. - Stated that only KNX_TOKEN is required for normal operation; external workflow node credentials must not be hardcoded. - No functional/API changes. Documentation and metadata improvements only.

# ycznwl-smarthome changelog (v1.0.2) - Added explicit UTF-8 encoding requirements, including instructions to send JSON with `charset=utf-8` and to handle Chinese characters in all user-facing fields. - Updated scene authoring guidance: clarified that for dimmable lights, sending `set_brightness` with `brightness>0` implicitly turns on the device (no need for separate `turn_on`); added notes on preferred device naming for multi-room scenes. - Expanded documentation for color temperature values and recommended passing user-configured (realistic) values. - Documented sun-event and sunrise/sunset offset support in triggers and nodes. - Added instructions for directly listing and resolving device `room_id` via `GET /rooms` for accurate scene action naming. - Clarified automation manual trigger requirements for API-based execution.

Version 1.0.1 - Skill renamed from "automation-agent" to "ycznwl-smarthome". - Security best practices expanded: emphasizes never pasting tokens into chat and reviewing imported workflow JSON for external connections or exposure. - Auth token storage guidance updated: recommends storing in environment variables or secret stores, not pasting in chat or hardcoding. - More detailed security disclaimers added for webhook, HTTP request, and MQTT nodes. - No functional API changes; documentation and naming improvements only

Control devices, create scenes, and build automations on your KNX Gateway via REST API. Covers the full workflow lifecycle: discover devices (lights, curtains, AC, sensors, locks, media players), create and execute scenes, build automation workflows with triggers (schedule, device event, KNX bus telegram, sunrise/sunset, webhook), configure condition/logic/delay/transform nodes, and manage workflow state (import, validate, enable, monitor executions). Use when asked to automate smart home behavior, control a device, create or run a scene, set up a schedule, or build a KNX Gateway workflow programmatically. __Requires a running YCZNWL KNX Gateway instance and an API token.__