- name
- smart-home-setup
- description
- Plans a smart home system covering device compatibility frameworks, hub versus hub-free architectures, network requirements, and privacy considerations. Produces a phased implementation plan with device categories, protocol selection, and network preparation steps.
Use when the user asks about setting up smart home devices, choosing a smart home platform, connecting devices together, home automation planning, or smart home privacy and security.
Do NOT use for specific device configuration or troubleshooting, home network infrastructure design (routers, switches, cabling), or commercial building automation systems.
- license
- Apache-2.0
- metadata
- {"author":"foundry-skills","version":"1.0.0","tags":"home-maintenance planning automation","category":"home-household","subcategory":"home-maintenance","depends":"","disclaimer":"none","difficulty":"intermediate"}
# Smart Home Setup
## When to Use
**Use this skill when:**
- A user wants to start building a smart home from scratch and needs a platform, protocol, and phasing strategy -- not just a device list
- A user has a mix of existing smart devices and wants to unify them under one platform or expand their setup coherently
- A user is comparing smart home platforms or ecosystems and needs a structured decision framework (hub-based vs. voice-centric vs. open-source local)
- A user asks whether specific device types will work together -- compatibility questions rooted in protocol and platform architecture
- A user wants to automate routines (lighting schedules, thermostat geofencing, door-triggered scenes, motion-activated sequences) and needs to understand what automation engines can do this
- A user has privacy or data sovereignty concerns about smart home devices and wants to understand the trade-offs before committing
- A user wants to prioritize smart home investments within a budget and needs a phased rollout plan
- A user is moving into a new home and wants to plan infrastructure for smart home readiness before walls are finished or painted
**Do NOT use when:**
- A user needs step-by-step configuration of a specific device model (Wi-Fi credentials, app pairing flow, firmware update) -- this is device-specific troubleshooting, not architecture planning
- A user needs to design or upgrade physical network infrastructure -- router selection, access point placement calculations, Ethernet cabling runs, or switch port planning (use a home networking skill)
- A user is asking about commercial or industrial building automation (HVAC control systems, BACnet, Modbus, KNX bus wiring) -- these are entirely different standards and engineering domains
- A user wants detailed comparisons of professional home security monitoring services (contract terms, central station response times, false alarm policies)
- A user needs to assess whether a specific electrical modification requires a licensed electrician -- use a DIY-vs-hire assessment skill instead
- A user wants to evaluate solar, battery backup, or whole-home energy management systems -- these overlap with smart home but require separate electrical engineering scope
---
## Process
### Step 1: Diagnose the User's Starting Point and Constraints
Before recommending anything, gather the parameters that drive every subsequent decision. Missing even one of these frequently causes incompatible device purchases.
- **Current devices:** Ask what smart devices are already in the home and what platform or app manages them. A home already invested in one ecosystem changes recommendations entirely -- switching costs are real.
- **Home ownership and type:** Renter vs. owner determines whether hardwired devices (smart switches, hardwired cameras, deadbolt-replacing locks) are possible. Apartment renters face a fundamentally different device menu than homeowners.
- **Electrical vintage:** Homes built before approximately 1985 frequently lack neutral wires at switch boxes. This eliminates most standard smart dimmer and switch options. Ask directly if the user knows their home's age.
- **Primary goals, ranked:** Convenience, energy savings, security/monitoring, accessibility, or privacy. The ranked order changes phase sequencing -- a user who ranks energy savings first should get a smart thermostat in Phase 1, not Phase 2.
- **Technical comfort level:** There are three meaningful tiers: (1) plug-and-play only -- no hubs, no YAML, no router login; (2) app-comfortable -- willing to create automations in a graphical interface, set up a hub; (3) technically advanced -- willing to run local software, write automation scripts, manage a home server.
- **Budget and timeline:** Distinguish between "starting budget" (Phase 1 only) and "total intended budget." A $300 start with $1,500 total changes the hub recommendation vs. a $300 total ceiling.
- **Home size:** Square footage and floor count directly affect hub placement, mesh network needs, and Zigbee/Z-Wave relay device planning. Under 1,500 sqft is straightforward. Over 3,000 sqft requires explicit signal coverage planning.
- **Internet reliability:** Frequent outages shift recommendations strongly toward local-processing platforms. Cloud-only devices become liabilities in areas with unstable ISP service.
---
### Step 2: Explain the Protocol Landscape with Decision Clarity
Users frequently buy incompatible devices because they do not understand that "smart" devices speak different radio languages. This step prevents regret-purchases.
**The six protocols that matter in residential smart home:**
| Protocol | Radio Frequency | Typical Indoor Range | Self-Powered Devices? | Mesh Network | Hub Required | Primary Strength |
|---|---|---|---|---|---|---|
| Wi-Fi (2.4 GHz) | 2.4 GHz | 100-150 ft | No -- line powered only | No | No (uses router) | High bandwidth -- cameras, displays, video doorbells |
| Zigbee | 2.4 GHz | 30-60 ft per hop | Yes -- batteries viable | Yes -- each mains device repeats | Yes | Low power sensors, bulbs, buttons; large mesh ecosystems |
| Z-Wave | 908.42 MHz (US) | 30-100 ft per hop | Yes -- batteries viable | Yes | Yes | Interference-resistant; hard cap of 232 devices per network; locks, sensors |
| Thread | 2.4 GHz | 30-60 ft per hop | Yes -- batteries viable | Yes -- IPv6 mesh | Border router needed | Modern IP-based sensor mesh; foundation of Matter on Thread |
| Bluetooth Low Energy (BLE) | 2.4 GHz | 30-50 ft | Yes -- batteries viable | Limited (Bluetooth mesh exists but uncommon in consumer devices) | Phone or hub | Short-range controls, presence detection, device config |
| Matter (over Wi-Fi or Thread) | Varies by transport | Varies | Varies by transport | Depends on transport | No -- interoperability layer, not a radio | Cross-platform compatibility standard |
**Critical protocol decision rules:**
- Z-Wave operates at 908.42 MHz in North America, completely avoiding the congested 2.4 GHz band that Wi-Fi, Zigbee, Thread, and Bluetooth all share. In apartment buildings or dense neighborhoods with heavy 2.4 GHz congestion, Z-Wave sensors and locks are more reliable.
- A Zigbee mesh requires at least 3 mains-powered devices (not battery devices) to be robust. Battery-only Zigbee devices do NOT repeat signals. If a user buys only battery sensors, there is no mesh -- each device communicates directly to the hub.
- Thread requires a Thread Border Router, which is built into some smart speakers and hubs. A device supporting Thread but without a border router on the network cannot connect.
- Matter is an application-layer standard, not a physical radio. A Matter device still uses Wi-Fi or Thread to transmit. Matter certification means any certified app or controller can operate it -- it does not eliminate protocol considerations.
- Wi-Fi devices each maintain a persistent TCP connection to either a cloud server or local hub. At 30+ Wi-Fi smart devices, a consumer router's connection table can become saturated, causing instability. This threshold is why separating IoT devices matters at scale.
---
### Step 3: Select the Platform Architecture
The platform is the decision with the longest lock-in consequence. Help the user understand the real trade-offs before committing.
**Architecture Type 1 -- Voice-Centric (No Dedicated Hub)**
- Lowest setup friction. Devices connect to Wi-Fi directly and are managed through a single vendor's app and voice assistant.
- Automation capability is moderate -- if/then rules, time-based schedules, basic presence detection. Cannot do multi-condition logic like "if door opens AND time is between sunset and 10 PM AND motion sensor is inactive, then trigger alarm sequence."
- Cloud dependency is high. If the vendor's servers go down or the company discontinues the product, automations stop working. This is not hypothetical -- multiple major smart home cloud services have been discontinued with little warning.
- Best for: users with low technical comfort, renters, or anyone wanting to start and learn before committing deeper.
**Architecture Type 2 -- Dedicated Hub (Local Processing)**
- A dedicated hub runs locally. Automations execute in milliseconds even without internet because logic runs on the hub, not in the cloud.
- Hub supports multiple protocols simultaneously -- typically Zigbee, Z-Wave, and Wi-Fi. This is the only single-controller approach that spans all three major low-power protocols.
- Automation power is substantially higher -- multi-condition rules, time windows, delay sequences, state machines, and integration with external data sources (weather APIs for irrigation, calendar data for presence).
- Setup requires more learning. Hub configuration involves creating devices, rooms, automation rules, and understanding the hub's logic engine.
- Best for: users comfortable with technology who want long-term reliability and deep automation.
**Architecture Type 3 -- Open-Source Local Platform**
- Runs on local hardware (a dedicated low-power computer or network-attached storage device). The software is community-maintained and free.
- Maximum device compatibility -- integrations with thousands of device types, cloud services, and local protocols.
- Maximum automation power -- full scripting capability, custom dashboards, integration with external APIs, complex state machines.
- Requires willingness to maintain software -- updates, occasional breaking changes, troubleshooting. Not suitable for users who want a finished product.
- Privacy maximum -- nothing leaves the local network unless the user deliberately adds a cloud integration.
- Best for: technically advanced users, privacy-focused users, or users who want a long-term platform with no commercial lock-in.
**Architecture Type 4 -- Hybrid (Recommended for Most Users)**
- Combine a dedicated hub for local device management and automation logic with a voice assistant for daily interaction and quick commands.
- The voice assistant sends commands to the hub, not directly to devices. The hub executes locally.
- Add Matter devices going forward to maintain cross-platform flexibility.
- This approach retains local reliability while providing the convenient voice interface most users expect.
**Protocol-to-Platform alignment:**
| Platform Type | Zigbee Support | Z-Wave Support | Thread/Matter | Best Protocol Focus |
|---|---|---|---|---|
| Voice-centric only | Sometimes (via add-on) | Rarely | Yes (newer models) | Wi-Fi + Matter |
| Dedicated hub | Yes (native) | Yes (native or add-on) | Growing | Zigbee + Z-Wave + Matter |
| Open-source local | Yes (via USB radio) | Yes (via USB radio) | Yes (via border router) | All protocols |
---
### Step 4: Plan Device Categories by Priority and Impact
Sequence device categories by the ratio of impact to complexity, not by what is most impressive. Phase 1 must always create visible, immediate value to build confidence and ensure the platform choice is validated before significant money is spent.
**Phase 1 -- Quick Wins (Day 1, under $200 typically)**
| Device Category | What It Actually Does | Key Feature to Require | Typical Cost Range |
|---|---|---|---|
| Smart plugs | Switch any corded lamp, fan, or small appliance on/off by schedule, voice, or remote | Energy monitoring (measures wattage of the connected device -- worth paying extra for) | $12-$30 each |
| Smart bulbs | Replace any bulb with one that dims, changes color temperature (warm to cool white), and responds to schedules | Color temperature range: look for 2700K (warm white) to 6500K (daylight); this range covers all lighting moods | $10-$35 each |
| Voice assistant speaker | Central voice interface for the whole system | Far-field microphone pickup distance; local voice processing option if privacy matters | $30-$110 |
Phase 1 validation checklist before moving to Phase 2:
- All Phase 1 devices connect reliably without frequent dropouts
- At least one automation is working (e.g., sunset schedule for lamps)
- User is comfortable with the app and voice commands
- Network performance has not degraded (check that other household devices still stream video without buffering)
**Phase 2 -- Core Automation (Week 1-2, $130-$300)**
| Device Category | Impact Specifics | Installation Notes | Typical Cost Range |
|---|---|---|---|
| Smart thermostat | Documented average energy savings of 8-15% annually on HVAC costs through scheduling and geofencing. Needs C-wire (common wire) for most models -- verify before purchasing. | Requires HVAC compatibility check -- multi-stage systems, heat pumps, and steam boilers may require specific models. | $100-$250 |
| Motion sensors | Trigger lights, sound automations, and security notifications. Passive infrared (PIR) sensors are standard; look for adjustable sensitivity and a configurable timeout (how long after last motion detection before returning to "clear" state). | Battery-powered, no wiring needed. Placement: 6-7 ft height, corner position for maximum coverage angle. | $15-$40 |
| Door and window sensors | Binary open/closed state. Use cases: HVAC automation (turn off when window opens), security awareness, automation triggers, pet door monitoring. | Adhesive or screw mount. Verify gap distance spec -- most require less than 0.5 in gap between magnet and sensor body. | $12-$30 each |
**Phase 3 -- Security and Access (Week 2-4, $200-$800 depending on scope)**
| Device Category | What to Evaluate | Installation Complexity | Typical Cost Range |
|---|---|---|---|
| Smart lock | Evaluate auto-lock timer, guest code management (create/expire codes without being home), activity log, and whether it integrates with the home's automation platform. Most retrofit over existing deadbolt hardware without changing the door face. | Moderate -- deadbolt replacement; no electrical wiring but needs Bluetooth or Z-Wave/Zigbee pairing. | $150-$350 |
| Video doorbell | Key specs: resolution (1080p minimum), field of view (160° or wider is better for covering porch approaches), night vision method (infrared vs. color night vision), local storage option. Wired models (replacing existing doorbell wiring) are more reliable than battery models for high-traffic doors. | Wired: low voltage (16-24V AC from existing doorbell transformer). Battery: adhesive or screw mount. | $100-$280 |
| Indoor/outdoor cameras | Distinguish between indoor (stationary, lower weather protection) and outdoor (IP65 or IP66 rated minimum). Pan/tilt indoor cameras offer wider coverage per device. Local storage via SD card or NVR eliminates ongoing cloud subscription costs. | Outdoor: requires weatherproof mounting location and power source (wired or solar-assisted battery). | $50-$200 each |
| Smart garage door controller | Adds open/close command, status monitoring, and auto-close automation to an existing garage door opener. Most use a tilt sensor on the door plus a button relay connected to the opener's wall button terminals. | Low -- no new wiring; clips to existing opener. Verify compatibility with opener model before purchasing. | $25-$80 |
**Phase 4 -- Advanced Automation (Month 2+, highly variable cost)**
| Device Category | Impact Specifics | Complexity Notes | Typical Cost Range |
|---|---|---|---|
| Motorized blinds/shades | Automate to track sun position (close south-facing windows during peak afternoon heat), schedule for privacy, or integrate with lighting scenes. | Battery-powered retrofit motors exist for existing blinds. Hardwired motors require electrician for dedicated circuits per motor bank. | $100-$500 per window |
| Leak/flood sensors | Early detection prevents catastrophic water damage. Priority placement: under kitchen sink, under all bathroom vanities, near water heater, near washing machine, in basement (especially near sump pump). | Battery-powered, no wiring. Most have very loud local alarm plus app notification. | $15-$40 each |
| Smart smoke and CO detectors | Interconnected alarms (when one sounds, all sound) and phone notification when away. Key requirement: verify they are UL217 and UL2034 listed for smoke and CO respectively. Replace all detectors in the home simultaneously for interconnect compatibility. | Replaces existing battery or hardwired detectors. Hardwired models have battery backup and connect to existing wiring. | $80-$150 each |
| Smart irrigation controller | Zone-by-zone scheduling with weather intelligence (skips watering if rain is forecast or recent ET data suggests soil moisture is sufficient). Retrofit replaces existing timer panel. | Moderate -- needs zone wire count to match controller channel count. Most controllers handle 8-16 zones. | $80-$250 |
| Whole-home energy monitor | Clamp-on sensors attach to main electrical panel conductors and measure whole-home and per-circuit energy consumption in real time. | Requires panel access -- hire an electrician if not comfortable with panel work. | $300-$500 |
---
### Step 5: Address Network Requirements with Specific Thresholds
Network preparation is the most commonly skipped step and the most common cause of smart home unreliability. Give the user concrete thresholds, not vague guidance.
**Device count and network capacity:**
- 1-15 Wi-Fi smart devices: most dual-band consumer routers handle this without issue, provided the router was manufactured after 2018.
- 15-40 Wi-Fi smart devices: a mesh Wi-Fi system with 2-3 nodes is strongly recommended. The goal is not speed -- it is reliable association and a larger connection table.
- 40+ Wi-Fi smart devices: a dedicated IoT VLAN or isolated Wi-Fi network (separate SSID broadcasting only 2.4 GHz) is recommended. Many consumer routers support this via the guest network feature.
**The 2.4 GHz vs. 5 GHz critical detail:** The vast majority of smart home Wi-Fi devices support only 2.4 GHz. A router that automatically combines 2.4 GHz and 5 GHz into a single "smart connect" SSID can cause setup failures because the phone pairs to 5 GHz while the device needs 2.4 GHz. During smart device setup, temporarily disable the 5 GHz band or use a dedicated 2.4 GHz SSID for IoT devices.
**IoT network isolation rationale:** Isolating smart devices on a separate network segment does two things simultaneously: (1) a compromised IoT device cannot reach computers, phones, or NAS devices on the main network, and (2) IoT device broadcast traffic does not compete with high-priority traffic like video calls and game streaming.
**Upload bandwidth for cameras:** Each camera uploading to cloud storage consumes approximately 1-4 Mbps of upload bandwidth continuously during recording. A home with 4 outdoor cameras could consume 16 Mbps of upload continuously. Check the ISP plan's upload limit before adding cameras -- residential plans often have asymmetric upload speeds of 10-20 Mbps on cable or DSL connections.
**Zigbee mesh planning specifics:**
- Hub placement should be within 30 ft of at least 3-4 mains-powered Zigbee devices (bulbs, plugs, switches).
- Battery-powered devices (sensors, buttons, locks) do not repeat -- they are leaves on the mesh tree, not branches.
- Each Zigbee mesh hop degrades signal reliability by approximately 10-15%. Keep sensor-to-hub path length to 3 hops or fewer.
- Zigbee at 2.4 GHz can experience interference from Wi-Fi. Zigbee channels 15, 20, 25, and 26 avoid overlap with the most common Wi-Fi channels (1, 6, 11). Configure the Zigbee hub to use channel 25 or 26 as a default starting point.
**Z-Wave mesh planning specifics:**
- Z-Wave's 908.42 MHz frequency does not share spectrum with Wi-Fi, making it inherently more interference-resistant.
- Z-Wave has a hard maximum of 232 devices per controller network -- a ceiling almost no home approaches, but worth knowing.
- Z-Wave mesh hops have a maximum of 4 hops from device to controller. For large homes, plan the distribution of mains-powered Z-Wave devices (plugs, switches) to ensure no device is more than 4 hops away.
---
### Step 6: Address Privacy and Security with Concrete Actions
Do not treat this as a checkbox -- smart home devices introduce meaningful and specific privacy risks that the user deserves to understand before purchase. Frame the trade-offs honestly.
**Data collection categories and their specific risks:**
| Data Type | Which Devices Collect It | Risk If Exposed | Mitigation |
|---|---|---|---|
| Voice audio | Voice assistant speakers | Continuous recording clips uploaded to cloud; reviewed by vendor employees in some documented cases | Enable mute switch when not needed; select a device with local voice processing (the phrase "works locally" in specs); regularly delete voice history via the vendor app |
| Video footage | Indoor cameras, doorbells | Raw video streams or clips stored on vendor servers; potential subpoena access by law enforcement | Use local storage (SD card or NVR); set privacy zones to exclude neighbor property and public spaces; understand that wired local NVR keeps footage entirely off-cloud |
| Location data | Any device using geofencing | Precise home arrival/departure times create a behavioral profile | Geofencing requires an explicit decision -- the convenience of auto-unlocking or temperature changes trades against continuous location tracking |
| Device usage patterns | Smart plugs with energy monitoring, locks | When you wake up, sleep, leave, and return; appliance use patterns | Prefer devices that process usage data locally; some hubs aggregate this data locally without ever sending it to the vendor |
| Network traffic metadata | All Wi-Fi devices | Even encrypted traffic reveals connection timing and frequency | IoT network isolation limits damage from a compromised device; consider a local hub that eliminates device-to-cloud connections entirely |
**Minimum security actions -- non-negotiable:**
1. Change default credentials on every device and every hub during initial setup. Default passwords are publicly documented and actively exploited.
2. Enable two-factor authentication on every smart home account (platform app, camera account, hub web interface).
3. Keep firmware updated on all devices. Smart home devices have had documented vulnerabilities exploited through outdated firmware, including camera feeds accessed by third parties.
4. Audit third-party integrations quarterly. Revoke access for any service no longer actively used.
5. Never expose a hub's local web interface directly to the internet via port forwarding. Use a VPN or the hub vendor's secure remote access feature instead.
---
### Step 7: Produce the Implementation Plan
Assemble all information gathered in Steps 1-6 into the structured output format below. Every field must contain specific, user-appropriate content -- not generic placeholders.
When writing the automation ideas section, think in terms of trigger-condition-action logic, not just "if X then Y." The most useful automations are those with time or state conditions that prevent unwanted triggering (e.g., the motion light automation should include a "only during nighttime hours" condition, or it will turn lights on unnecessarily during the day).
---
## Output Format
```
## Smart Home Plan: [Home Type] -- [Primary Goal Focus]
### Situation Summary
| Parameter | Value |
|--------------------|------------------------------|
| Home type | [owned/rented; house/apartment/condo] |
| Size | [sqft or bedroom count] |
| Existing devices | [list or "none"] |
| Technical comfort | [plug-and-play / app-level / advanced] |
| Primary goals | [ranked: e.g., energy savings > convenience > security] |
| Budget | [Phase 1 budget / total intended] |
| Electrical notes | [neutral wire status if relevant; home age] |
### Platform Selection
| Decision | Recommendation | Rationale |
|-----------------------|------------------------------|-----------------------------------------------------|
| Architecture type | [voice-centric / hub-based / open-source / hybrid] | [specific reason based on goals and comfort level] |
| Primary protocol | [Wi-Fi / Zigbee / Z-Wave / Thread / mixed] | [why this protocol fits this home and use case] |
| Hub recommendation | [none / dedicated hub type] | [why or why not based on device count and goals] |
| Voice assistant | [choice or "not required"] | [rationale for inclusion or exclusion] |
| Matter strategy | [prefer Matter devices / add later / not relevant] | [how this affects buying decisions] |
GitHubで見る