Project
- Stars
- Started
- Issues
- License
Local Kettle Connector
Recipe · PromptBuild a local kettle connector with confirmed heating
Investigate an owned kettle’s official software interfaces and, only if a legitimate control path is proven, build a local connector with verified state and individually confirmed heating.
The prompt
Written for Claude Code · 920 wordsYou are Claude Opus 5.5 acting as an evidence-first interoperability engineer. I own this electric kettle and authorize you to inspect only its software interfaces and user-supplied artifacts. Target Device: [brand and exact model] Firmware version: [version if known] Companion app: [app name and version, if any] Connection: [Wi-Fi, Bluetooth, USB or none] Device address: [exact IP, Bluetooth ID or none] Available artifacts: [APK, app folder, firmware file, manual or logs] Goal Determine how this kettle communicates with its official application and whether it provides a legitimate, local and safely testable control interface. If such an interface is proven, create a minimal local connector that can: 1. Read the kettle status. 2. Read the current water temperature. 3. Read whether heating is active. 4. Set a target temperature within documented limits. 5. Start heating only after explicit human confirmation. 6. Stop heating immediately. 7. Verify the real device state after every command. Do not assume that remote control is possible. Do not invent APIs, commands, capabilities or successful tests. Safety boundaries - Inspect only the exact device and artifacts listed above. - Begin with read-only analysis. - Do not scan other devices or addresses. - Do not open the kettle, power base or mains-powered components. - Do not test exposed electrical components. - Do not modify or flash firmware. - Do not patch the original app or binary. - Do not extract passwords, account tokens or personal data. - Do not bypass pairing, authentication or authorization. - Do not bypass the thermostat, lid sensor, water sensor, boil-dry protection, automatic shutoff or thermal fuse. - Do not increase temperature beyond manufacturer limits. - Do not start heating unless I am physically present. - Require a new confirmation for every heating action. - Never run physical tests unattended. - Stop immediately if the device state cannot be verified. - If safe control cannot be proven, return a blocked result. Phase 1 - Preflight 1. Verify that REA is connected and report its version. 2. List the relevant REA tools and analysis providers. 3. Record the exact kettle, app and firmware versions. 4. Confirm the precise authorized target. 5. Review the manufacturer manual and documented safety limits. 6. Create an investigation plan before performing analysis. Return the plan and wait for my approval. Phase 2 - Collect evidence After approval: 1. Inspect only the official companion app, official firmware or artifacts I provide. 2. Determine whether communication is local, cloud-based or both. 3. Identify the transport protocol, pairing flow and message format. 4. Map only the functions related to: - device status - current temperature - target temperature - heating state - start - stop 5. Record every finding as: - Fact - Observation - Inference - Unknown - Next test 6. Attach a file path, symbol, log, trace or screenshot to every important claim. 7. Preserve the authentication and safety checks used by the official app. Do not send control commands during this phase. Phase 3 - Prove the control path Evaluate possible integrations in this order: 1. Official documented API. 2. Matter, HomeKit, MQTT or another supported standard. 3. An authorized local interface used by the official companion app. 4. A manufacturer-supported automation interface. For each candidate: - Show the supporting evidence. - Explain how pairing and authentication work. - Test the smallest read-only request first. - Compare the returned state with the physical kettle. - Reject the candidate if the evidence is incomplete. If no safe software interface exists, stop. Do not invent a workaround. Do not recommend bypassing the kettle controller. Do not propose directly switching mains power with an unsafe relay. Phase 4 - Build a minimal connector Only after I approve the proven control path, create a separate local project. Provide only these functions: - get_status - get_temperature - set_target_temperature - start_heating - stop_heating Requirements: - Enable dry-run mode by default. - Allowlist only the exact authorized kettle. - Derive temperature limits from official documentation. - Reject unsupported temperatures and durations. - Preserve all built-in safety mechanisms. - Require confirmation immediately before start_heating. - Make stop_heating available without additional confirmation. - Never report success until the kettle confirms its new state. - Add timeouts and fail safely if the connection is lost. - Prevent automatic retries of heating commands. - Keep the connector local and do not expose it to the public internet. - Keep credentials outside source files. - Record an audit log for every proposed and executed command. - Include unit tests, integration tests and a README. Phase 5 - Optional voice control Convert a voice request such as: "Heat the kettle to 80 degrees." into this proposal: { "device": "[exact kettle]", "action": "start_heating", "target_temperature_c": 80, "requires_confirmation": true } Before execution, say: "Confirm that the kettle contains enough water, the lid is closed, and you are physically present. Start heating [device] to [temperature] degrees Celsius?" Only an explicit yes authorizes that single action. Silence, ambiguity, an expired confirmation or an unverified device state means cancel. Final report Return: Status: Proven, blocked or needs approval. Target: Exact kettle, app and firmware versions. Evidence: Every important claim with its supporting artifact. Control path: How the official app communicates with the kettle. Files created: Paths and purposes. Tests: What was tested, what passed and what remains unverified. Safety: Temperature limits, confirmation gates, timeouts and emergency-stop behavior. Unknowns: Anything that still lacks evidence. Next step: The smallest safe action for me to approve. Do not start the kettle yet. Begin with the preflight plan and wait for my approval.
What it lets your agent do
- Read status, temperature and heating state
- Set temperature within documented limits
- Start confirmed heating and stop immediately
- Verify device state after commands
- Do not modify or flash firmware.
- Do not bypass pairing, authentication or authorization.
- Do not increase temperature beyond manufacturer limits.
- Never run physical tests unattended.
Project
- Stars
- Started
- Issues
- License
Built by
Intended for
kettle
Compatibility with specific models is unverified.
You'll need
- Claude Code with Claude Opus 5.5
- Connected REA tools and analysis providers
- Owned kettle with exact model, connection and address details
- Official manual and available app, firmware or log artifacts
- Owner physically present for heating and physical tests
The prompt
Written for Claude Code · 920 wordsYou are Claude Opus 5.5 acting as an evidence-first interoperability engineer. I own this electric kettle and authorize you to inspect only its software interfaces and user-supplied artifacts. Target Device: [brand and exact model] Firmware version: [version if known] Companion app: [app name and version, if any] Connection: [Wi-Fi, Bluetooth, USB or none] Device address: [exact IP, Bluetooth ID or none] Available artifacts: [APK, app folder, firmware file, manual or logs] Goal Determine how this kettle communicates with its official application and whether it provides a legitimate, local and safely testable control interface. If such an interface is proven, create a minimal local connector that can: 1. Read the kettle status. 2. Read the current water temperature. 3. Read whether heating is active. 4. Set a target temperature within documented limits. 5. Start heating only after explicit human confirmation. 6. Stop heating immediately. 7. Verify the real device state after every command. Do not assume that remote control is possible. Do not invent APIs, commands, capabilities or successful tests. Safety boundaries - Inspect only the exact device and artifacts listed above. - Begin with read-only analysis. - Do not scan other devices or addresses. - Do not open the kettle, power base or mains-powered components. - Do not test exposed electrical components. - Do not modify or flash firmware. - Do not patch the original app or binary. - Do not extract passwords, account tokens or personal data. - Do not bypass pairing, authentication or authorization. - Do not bypass the thermostat, lid sensor, water sensor, boil-dry protection, automatic shutoff or thermal fuse. - Do not increase temperature beyond manufacturer limits. - Do not start heating unless I am physically present. - Require a new confirmation for every heating action. - Never run physical tests unattended. - Stop immediately if the device state cannot be verified. - If safe control cannot be proven, return a blocked result. Phase 1 - Preflight 1. Verify that REA is connected and report its version. 2. List the relevant REA tools and analysis providers. 3. Record the exact kettle, app and firmware versions. 4. Confirm the precise authorized target. 5. Review the manufacturer manual and documented safety limits. 6. Create an investigation plan before performing analysis. Return the plan and wait for my approval. Phase 2 - Collect evidence After approval: 1. Inspect only the official companion app, official firmware or artifacts I provide. 2. Determine whether communication is local, cloud-based or both. 3. Identify the transport protocol, pairing flow and message format. 4. Map only the functions related to: - device status - current temperature - target temperature - heating state - start - stop 5. Record every finding as: - Fact - Observation - Inference - Unknown - Next test 6. Attach a file path, symbol, log, trace or screenshot to every important claim. 7. Preserve the authentication and safety checks used by the official app. Do not send control commands during this phase. Phase 3 - Prove the control path Evaluate possible integrations in this order: 1. Official documented API. 2. Matter, HomeKit, MQTT or another supported standard. 3. An authorized local interface used by the official companion app. 4. A manufacturer-supported automation interface. For each candidate: - Show the supporting evidence. - Explain how pairing and authentication work. - Test the smallest read-only request first. - Compare the returned state with the physical kettle. - Reject the candidate if the evidence is incomplete. If no safe software interface exists, stop. Do not invent a workaround. Do not recommend bypassing the kettle controller. Do not propose directly switching mains power with an unsafe relay. Phase 4 - Build a minimal connector Only after I approve the proven control path, create a separate local project. Provide only these functions: - get_status - get_temperature - set_target_temperature - start_heating - stop_heating Requirements: - Enable dry-run mode by default. - Allowlist only the exact authorized kettle. - Derive temperature limits from official documentation. - Reject unsupported temperatures and durations. - Preserve all built-in safety mechanisms. - Require confirmation immediately before start_heating. - Make stop_heating available without additional confirmation. - Never report success until the kettle confirms its new state. - Add timeouts and fail safely if the connection is lost. - Prevent automatic retries of heating commands. - Keep the connector local and do not expose it to the public internet. - Keep credentials outside source files. - Record an audit log for every proposed and executed command. - Include unit tests, integration tests and a README. Phase 5 - Optional voice control Convert a voice request such as: "Heat the kettle to 80 degrees." into this proposal: { "device": "[exact kettle]", "action": "start_heating", "target_temperature_c": 80, "requires_confirmation": true } Before execution, say: "Confirm that the kettle contains enough water, the lid is closed, and you are physically present. Start heating [device] to [temperature] degrees Celsius?" Only an explicit yes authorizes that single action. Silence, ambiguity, an expired confirmation or an unverified device state means cancel. Final report Return: Status: Proven, blocked or needs approval. Target: Exact kettle, app and firmware versions. Evidence: Every important claim with its supporting artifact. Control path: How the official app communicates with the kettle. Files created: Paths and purposes. Tests: What was tested, what passed and what remains unverified. Safety: Temperature limits, confirmation gates, timeouts and emergency-stop behavior. Unknowns: Anything that still lacks evidence. Next step: The smallest safe action for me to approve. Do not start the kettle yet. Begin with the preflight plan and wait for my approval.
What it lets your agent do
- Read status, temperature and heating state
- Set temperature within documented limits
- Start confirmed heating and stop immediately
- Verify device state after commands
- Do not modify or flash firmware.
- Do not bypass pairing, authentication or authorization.
- Do not increase temperature beyond manufacturer limits.
- Never run physical tests unattended.
Feedback
How did it go? Tips, problems, questions…
Feedback
How did it go? Tips, problems, questions…