Zigbee2MQTT Gateways

Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else. Prerequisites — Muse Home Link and a compatible physical device are required to USE this skill, not to install it: installing the skill file itself needs no account, no key and no device, and this install does NOT set up Home Link, pair anything or ask for any credential. But the skill is instructions only. To use it I must read and follow ~/docs/devices/home_link.md in my Muse environment, have the compatible physical device named below already set up on my local network, and have an existing Zigbee2MQTT installation with an authorized, reachable MQTT broker already set up in my home (existing broker address, discovered/confirmed TCP listener, TLS trust and broker credentials where required, plus the configured base topic and a compatible MQTT client such as Paho using HomeLink's TCP transport), and permission for the specific child device and action — broker access is not permission to change every device. Installing the file configures none of that. Install "Zigbee2MQTT Gateways" for me. It reads or controls supported child-device capabilities through an existing Zigbee2MQTT gateway using Muse Home Link, via its authorized MQTT broker, configured base topic and actual exposed properties; it is not gateway setup or device pairing. It is used when the home already has a Zigbee2MQTT installation and an authorized, reachable MQTT broker: the existing broker, its configured Zigbee2MQTT base topic and the intended bridge are identified (the MQTT broker's vendor or port alone does not identify a Zigbee gateway), and <base>/bridge/info and <base>/bridge/devices are read, resolving the requested child device by its stable identity and current friendly name. With a compatible MQTT client such as Paho using HomeLink's TCP transport, it subscribes to bridge/device state before requesting new data and inspects each target's definition.exposes, including nested features, property names, endpoint names, types, ranges and allowed values, interpreting an expose's access bitmask — 1 means published state, 2 permits set, and 4 permits get — without assuming every state property is writable or queryable. For a property with get support it publishes the documented payload to <base>/<friendly_name>/get and reads the matching device state topic (a retained message may predate the interaction); for an authorized change it publishes only the supported property/value to <base>/<friendly_name>/set, following device-specific documentation for composite values or endpoints, then observes the corresponding state update and bridge error responses — battery-powered devices may sleep, so pending/unconfirmed delivery is reported instead of repeating physical actions. It checks reported state and timestamps when available (an MQTT publish acknowledgment alone does not establish that a Zigbee device acted), uses existing availability reporting when enabled (missing availability is not automatically proof of failure), and for covers, locks or other physical actuators distinguishes requested target from achieved state. Limits: no new broker/gateway installation, no join-mode changes, no device removal, no arbitrary topic writes and no fixed assumptions about household devices; only devices actually supported by the installed bridge and their exposed capabilities are covered, not universal Zigbee support. Repository: https://github.com/facebookincubator/muse-gadget-sdk (the skill is the whole skills/gadget-zigbee2mqtt-gateways/ folder at the pinned commit: SKILL.md only, 1 file) Pinned version: install the code at commit e6fe5174092702ffddae6f90759a38d55a4ebae1 exactly. Do not substitute a newer version. If this commit is unreachable, stop and tell me. 1. Clone https://github.com/facebookincubator/muse-gadget-sdk into a temporary folder, check out commit e6fe5174092702ffddae6f90759a38d55a4ebae1, and copy the skills/gadget-zigbee2mqtt-gateways/ folder from that checkout. Then compare every file in the folder with the fingerprints recorded for this listing on 2026-10-22: [FINGERPRINTS] - SKILL.md: SHA-256 80a040c9424ceb97b79dc0cc7c398be6a6559d69151baff7e5c910153c2c6fab If a file does not match, it changed since the listing was prepared: do not install it yet, tell me what you found and let me decide. 2. Read SKILL.md in full, and tell me in plain words: what the skill does when used, what it connects to, whether it reads or sends any personal information or credentials, and anything that seems unusual. Stop on any red flag and tell me before going further. Confirm these points from the files: - The skill folder holds 1 file only: SKILL.md (3,071 bytes). There is no script, no code and no configuration in it; the procedure runs at use time through Muse Home Link against my own local device. It has no dependency on any other gadget skill in this lot. - Nothing is sent anywhere during installation itself; the only download at install time is the skill folder from GitHub at the pinned commit. No device is contacted, no pairing is started and no key is asked for during installation. - At use time, exchanges go only to my existing local MQTT broker for my Zigbee2MQTT installation, through a compatible MQTT client such as Paho over HomeLink's TCP transport, with TLS trust and broker credentials where required: reads of <base>/bridge/info and <base>/bridge/devices, documented get payloads to <base>/<friendly_name>/get and, for authorized changes only, supported property/value publishes to <base>/<friendly_name>/set. - The skill does not install a new broker/gateway, change join mode, remove devices, write arbitrary topics or make fixed assumptions about household devices, and it does not claim universal Zigbee support. - Do not pair any device, do not ask for or set any credential, do not run any control, print, scan or playback action, and do not use the skill in any way during this install: Home Link setup, pairing and use are my decisions, later, when I actually ask for them. 3. When I say "yes, install", install it as a skill: copy the whole gadget-zigbee2mqtt-gateways folder into the agent's skills directory, in a folder named exactly "gadget-zigbee2mqtt-gateways", keeping its 1 file (SKILL.md at its root). The exact folder name matters: relative links between sibling gadget skills depend on these exact names. 4. Verify with no network calls: frontmatter valid (name: gadget-zigbee2mqtt-gateways), the 1 file in place with matching fingerprint. Do not run anything and do not connect to any device to verify. 5. Report what was installed, where, and what I still need to do myself (for example: read ~/docs/devices/home_link.md in my Muse environment and follow its Home Link rules; have an existing Zigbee2MQTT installation with an authorized, reachable local MQTT broker already set up, with its configured base topic, TLS trust and broker credentials where required, and permission for the specific child device and action; using the skill is a separate step that only starts when I ask for it, and the use-time exchanges disclosed above happen only then). GitHub is optional: if I have a GitHub account or the gh CLI, you may use it; otherwise public access is fine. Never require it unless it's in the prerequisites above. Rules: don't touch anything outside the temp folder and the install target. If anything looks off, stop and ask me.