Can AI build a smart home automation app like SmartThings?

Build a personal smart home dashboard web app that talks to my existing SmartThings Hub through the SmartThings public REST API, for my own use only. I already own a paired Hub and a SmartThings developer account with an OAuth2 token.

Tech rules:
- Plain HTML, CSS, and vanilla JavaScript in one file. No framework or build step.
- Store my OAuth2 token and device list in localStorage under one key, with a version number. Never send the token anywhere except SmartThings' own API.
- Poll the SmartThings API for device state on an interval I can configure, respecting documented rate limits.

Data model:
- Device: id, name, type (switch | light | sensor | lock | other), currentState, lastPolledAt, lastChangedAt.
- StateEvent: deviceId, state, timestamp.
- Rule: id, name, triggerDeviceId, triggerCondition, actionDeviceId, action, enabled.

Features:
- Device list pulled from the SmartThings API, showing name, type, and current state.
- Toggle a switch or light directly from the dashboard, calling the API's device command endpoint.
- A simple rules builder: "when [device] is [state], set [device] to [state]", saved and sent to the API's Rules endpoint.
- A log of state changes for devices I mark as "watched", stored locally as I poll.
- A settings screen for my OAuth2 token and polling interval.

Edge cases the build must handle correctly:
1. Zigbee/Z-Wave devices need the paired Hub bridging to the cloud API; the app must show a clear error if a device isn't reachable rather than silently showing stale state.
2. Some "Works With SmartThings" cloud-to-cloud devices only expose a subset of commands through the public API; disable controls the API doesn't support for a given device instead of showing a button that silently fails.
3. Device state can drift from real hardware; show the last-polled timestamp next to every device so I know how fresh the state is.
4. Battery sensors and asleep devices report stale state; flag devices that haven't reported in longer than expected instead of treating old data as current.
5. Matter devices paired to Apple Home or Google Home instead of SmartThings never appear in the SmartThings API; the device list should only ever show what the API actually returns, with no assumption that it's my whole home.
6. Starting October 2026, API access requires the paid Personal developer plan; if a request fails with an auth or billing error, show that clearly instead of a generic connection error.
7. Routines built in the SmartThings app itself have no documented export; the rules builder here only manages rules created through this app, and should say so.

Backup:
- One-click "Export JSON" of devices, watched history, and rules (not the OAuth2 token).
- "Import JSON" restores after confirmation.

Layout:
- Mobile-first, readable at 375px wide, with a device list and a simple rules list.

Exclusions:
- No publishing, App Store submission, accounts beyond my own SmartThings developer login, payments, or support for protocols the SmartThings API doesn't expose.

Write a short README explaining where the token and device data are stored, how to export and restore, and that this requires an already-paired SmartThings Hub plus a registered developer account.

Keep it under 700 lines. This is a personal tool, not a product.

What is the short answer?

ADVANCED. There’s an odd twist here: the SmartThings consumer app itself is free, with no per-user subscription, so there’s nothing to “cancel” in the usual sense. What a DIY builder actually needs is the SmartThings public developer API, and starting October 2026, that requires a $4.99/month Personal developer plan for individual, non-commercial use, on top of a SmartThings Hub you already own and paired.

That fee is the real story. AI can absolutely build a dashboard or a custom routine on top of the API, but it’s building on paid infrastructure launching days after this research, not replacing a subscription for free. This is a real ADVANCED build for someone comfortable with OAuth2 and an already-paired Hub, not a beginner weekend project.

Option	Best for	Upfront cost	Ongoing cost	Main limitation
Build a rough prototype	Someone who already owns a paired Hub and wants a dashboard of current device state	$0–$20 and 5–8 hours	$4.99/month from October 2026 for API access	No custom routines yet, just read-only state
Build a daily-use personal version	Someone comfortable maintaining an OAuth2 integration who wants custom routines beyond the SmartThings app’s own	$0–$20 and 25–35 hours	$4.99/month from October 2026 for API access	Still depends entirely on an already-paired Hub
Keep paying for nothing, and just use SmartThings as-is	Anyone happy with the built-in app’s routines and scenes	$0	$0	None of the API’s paid tier applies if you never build against it

The ready-to-paste starter prompt at the end of this page builds the daily-use version.

What should the first version include?

The first version should prove the API connection works against your real, already-paired Hub before you build anything fancier.

• Device list pulled from the SmartThings API with live state
• Toggle a switch or light from the dashboard
• A last-polled timestamp per device
• A basic settings screen for the OAuth2 token
• Deliberate exclusion: no custom routines yet, no history logging. Confirm the connection is reliable first.

What can AI build reliably?

ChatGPT and Claude write the OAuth2 request code, the device-list fetch, and the toggle commands against the SmartThings REST API reliably, since it’s a documented, typed API.

Concrete things AI gets right:

• Authenticating against the SmartThings API with an OAuth2 token and fetching device state
• Sending on/off or set-level commands to a device the API exposes
• A simple rules builder that posts a trigger-and-action pair to the API’s Rules endpoint
• A local log of state changes for devices you mark as watched

Where will AI need human help?

The Hub is not optional, and no prompt can substitute for it. Zigbee and Z-Wave devices need a physical SmartThings Hub bridging to the cloud API; a browser can’t reach them directly. If you don’t already own a paired Hub, this build has nothing to control.

Some devices only offer partial control. Cloud-to-cloud “Works With SmartThings” devices sometimes expose only a subset of commands through the public API, not full control, so you’ll need to test each device and disable buttons the API doesn’t actually support.

State freshness is a decision you make, not a bug AI fixes. Device state can drift from real hardware unless the app polls or subscribes to SmartThings’ webhook or event stream, and battery sensors or asleep devices report stale state. You decide how often to poll within the rate limits of the now-paid API tier, and how to show staleness honestly rather than hiding it.

Routines built in the SmartThings app itself have no documented export and must be recreated by hand via the Rules API. If you’ve already built routines in the app, budget time to rewrite them, not migrate them. And SmartThings Edge Lua drivers that run locally on the Hub are invisible to the cloud REST API entirely, so anything built on those drivers stays out of reach of a web app.

The decision only you can make is whether the $4.99 monthly developer fee, arriving right as you’d start this project, is worth it for routines the SmartThings app might already offer for free.

Can I get my data out of SmartThings?

Partly, through the developer side, not a consumer export button. There’s no one-click export for end users. A developer can register a SmartApp on developer.smartthings.com, get an OAuth2 token, and pull device lists, current device state, and Rules or Scenes as JSON via the SmartThings public REST API.

The trap: there’s no consumer-facing backup of routines or automation history, so recreating a routine means hand-writing it in the API’s JSON Rules syntax from scratch. Edge Lua drivers that run locally on the physical Hub aren’t visible or exportable through the cloud API at all [VERIFY].

SmartThings the app is free, but the thing a DIYer would actually need to build routines for their own plugs, the public API, starts costing Samsung’s users $4.99 a month for individual developers in October 2026, days after this research, which undercuts the entire cancel-your-subscription pitch.

How long will it take and what will it cost?

Rough prototype: 5–8 hours and $0–$20 in AI tool usage. A device list with live state and basic toggling against your already-paired Hub.

Dependable daily-use version: 25–35 hours, including a working rules builder, state-change logging, and handling for stale or partial device data.

The ongoing cost isn’t hosting, it’s the $4.99/month developer API plan starting October 2026, which you’ll pay for as long as your app keeps calling the API. That’s a real recurring cost for something that used to be free, and it applies whether your build takes 5 hours or 50.

These are estimates from reviewing the feature set, not measurements from a completed build.

Which AI tool or approach should I use?

Claude or ChatGPT on a paid plan handles the OAuth2 flow and REST API calls well, and this build spans enough sessions that losing context on a free plan will slow you down.

Cursor is a reasonable fit if you want to iterate on the rules builder across many small changes, since debugging against real hardware state usually means several rounds of trial and error.

Lovable can host a backend, useful if you want to hold a webhook subscription open to get real-time device events instead of polling, which is a meaningfully better architecture but adds hosting to maintain on top of the Hub and the API fee.

What will I need to maintain?

More than most personal builds here, because of the Hub, the OAuth2 token, and the new paid API tier.

Recurring work:

• Renew or monitor the $4.99/month developer API plan starting October 2026
• Refresh your OAuth2 token when it expires
• Watch for Samsung changing rate limits or API structure with little notice
• Re-pair or troubleshoot the Hub itself if a device drops off

Should I build it, buy it, or reduce scope?

Build it if you already own a paired SmartThings Hub, are comfortable with OAuth2 and REST APIs, and want routines beyond what the built-in app offers.

Buy it, meaning stick with the SmartThings app’s own free routines and scenes, if you don’t need anything the app doesn’t already do. There’s no subscription to cancel here, so “buying” simply means not building.

Reduce scope if you just want a status page for a couple of devices. A simple read-only dashboard pulling device state, without a custom rules engine, is a smaller build and a smaller ongoing API load.

Recommendation: only build this if you already own a paired Hub and specifically want automations the SmartThings app can’t do. The $4.99/month developer fee starting October 2026 means you’re not saving money by building, you’re paying a new cost to get more control. If you want habit-style routines without any hardware dependency, see the habit tracker build, and for plant care reminders that don’t need a Hub at all, see the Planta build.

What if I wanted to ship this to other people?

Shipping this to other people means every user needs their own paired SmartThings Hub and their own developer API access, which most people don’t have and won’t set up. You’d also be responsible for handling other people’s OAuth2 tokens securely and absorbing or passing on the per-developer API fee, a much bigger undertaking than a personal dashboard.

Starter build specification

• User: You, for your own use, controlling devices on your own already-paired SmartThings Hub.
• Problem: Wanting automations beyond what the SmartThings app offers, while accepting the new $4.99/month developer API fee starting October 2026.
• Core workflow: View device state, toggle devices, build simple trigger-and-action rules, review a log of state changes.
• Required features: Device list with live state, toggle controls, a rules builder against the API’s Rules endpoint, a state-change log.
• Deliberate exclusions: No support for protocols the API doesn’t expose, no migration of existing SmartThings-app routines, no accounts beyond your own developer login.
• Data ownership: Device and rule data stored in localStorage, exported as JSON, imported from JSON. The OAuth2 token never leaves your device except to call SmartThings’ own API.
• Definition of done: The dashboard shows live state for every device on your Hub, toggling a device from the dashboard changes its real-world state within your polling interval, and a saved rule fires correctly at least once.

For scoping help, read can AI build an app for me.

Sources and verification

• A new, enhanced SmartThings API experience (SmartThings blog): the $4.99/month Personal developer plan starting October 2026 and the Q3 2026 end of free API access.
• Samsung will start charging for SmartThings API access (Engadget): third-party coverage of the pricing change.
• Architecture of SmartThings (SmartThings developer docs): how the Hub bridges Zigbee, Z-Wave, and cloud-to-cloud devices to the API.
• SmartThings public API reference: device, state, and Rules endpoints; OAuth2 requirements.

This app was not built and tested for this page. The verdict is based on SmartThings’ own developer blog and documentation plus third-party reporting on the October 2026 API pricing change. SmartThings’ pricing was checked on September 24, 2026.

Reviewed on September 24, 2026.