Sonoff RF Bridge R2 Fixed-Code Actions

Sonoff RF Bridge R2: Fixed-Code Capture and Transmit

Use this skill when fresh discovery identifies a compatible stock Sonoff RF Bridge R2 and the user requests an approved fixed-code RF action.

Humans to Know editorial context

Use the pinned Muse Gadget SDK repository for runtime setup. Existing LAN-device clients run on its Linux Home Link through system.run; the Muse app, SDK token and VM connection remain required.

Community-sourced instructions, not an official integration. Read repository-context.md before using this standalone package; it identifies the exact upstream repository, runtime dependencies and evidence to hand back. The original workflow and device limits below are retained.

Modified-file notice: Humans to Know added the editorial context and standalone reference links to this upstream skill.

Identify the Device

• Match _ewelink._tcp, exact bridge model and firmware. The HTTP zeroconf service commonly uses 8081; use the discovered endpoint.
• Firmware 3.x HTTP zeroconf is distinct from older WebSocket recipes. Do not infer compatibility from the radio frequency or brand alone.

Prerequisites

Read the Humans to Know editorial repository context for the pinned SDK, Linux execution boundary and task-specific verification. This supplement resolves the missing public home_link.md reference.

• The bridge must already have LAN operation configured and its device ID/devicekey supplied through approved credential storage; no cloud key retrieval is part of this procedure.
• Maintain a private, user-confirmed channel-to-action mapping. Use channels 0–15; the bridge does not provide a reliable local learned-channel inventory.
• Confirm the physical target, channel and effect before capture or transmission, particularly doors, alarms and power outlets.

Workflow

1. Build a fresh request envelope for each command. Derive the 16-byte AES key as the raw MD5 digest of the devicekey; use a fresh random 16-byte IV, AES-128-CBC, PKCS#7 padding and base64 ciphertext/IV.
2. Encrypt the UTF-8 JSON command payload, then POST to the corresponding /zeroconf/<command> endpoint with sequence (millisecond string), deviceid, literal selfApikey:"123", encrypted data, encrypt:true and iv. Keep all key material out of commands and logs.
3. For user-requested learning on a confirmed free channel N, send {"cmd":"capture","rfChl":N} to /zeroconf/capture, then ask the user to press the intended remote near the bridge. Do not overwrite an existing mapping without explicit authorization.
4. For a known learned action, send {"cmd":"transmit","rfChl":N} to /zeroconf/transmit once. Inspect the application response, including any device error, and decode an encrypted response according to its envelope.
5. Record a confirmed channel assignment privately after successful learning. Do not infer RF device state from the channel map or an uncertain transmit response.

Verify the Result

• HTTP 200 is not physical proof. Confirm the intended device actually acted, using independent state feedback or the user.
• A parseable /zeroconf/getState response is not guaranteed; an unsupported-command error does not by itself mean the key is wrong.
• Do not automatically repeat an uncertain RF transmission: some learned actions toggle state or move a device.

Limits

• Fixed-code 433 MHz only in this scope; no rolling-code replay, infrared or universal remote support.
• No companion client is required; the agent may implement the documented envelope. Do not install replacement firmware, extract keys from accounts or create a cloud fallback.

Sources

• cryptography symmetric encryption