Android Edge bridge & SmartThings AI Agent App

Hi @TAustin

I’ve wanted to write this message for a while. I’ve been using EdgeBridge for a long time, and I just wanted to say — thank you. Really. It’s been such a great service, and it genuinely changed how I thought about what Edge Drivers could do. I should also mention: the Korean SmartThings community absolutely loves EdgeBridge. So many Korean ST users rely on it daily, and it’s become a cornerstone of how a lot of us build our setups here.

The one thing I kept bumping into was that most of my friends in the community didn’t have a server at home, and running one just for EdgeBridge was too much of a hurdle for them. I kept thinking about how to make this kind of capability reachable for regular SmartThings users who don’t have that setup.

That’s how AEB (Android EdgeBridge) came about. It turns an Android phone into a SmartThings agent and local bridge, so Edge Drivers can reach external services without any dedicated hardware. On top of the bridge role, I also packed in some AI features and SmartThings Agent capabilities. A few quick examples of what you can do:

- Control devices with natural language (e.g., “dim the bedroom lights and play some relaxing music”)

- Dynamic, context-aware TTS announcements generated by an LLM

- Agent Chat — a conversational way to interact with your home

- The same local bridge functionality EdgeBridge provides, for Edge Drivers reaching external services

There’s more detail and additional examples on the intro page, so it’d be great if you could take a look there too. The app has finally reached a point where it feels stable enough to share, and honestly, you were one of the first people I wanted to show it to — because the whole idea grew out of using your work and wishing more people could experience it.

Here’s the intro page: https://aeb.dothesmartthings.com

(The Android app link is in there too.)

If you get a chance to take a look, try it out, and share any thoughts or feedback, I’d really appreciate it. No pressure at all — but any reaction from you would mean a lot.

And one more time — from me, and from so many Korean ST users who’ve quietly relied on your work for years — thank you. Truly. EdgeBridge has meant a lot to us.

All the best,

Booung

Hello Booung -

Thanks so much for the post! It’s great to know that people found edgebridge useful, and that you’ve been able to get an analogous app running on Android. I recall someone asking about this a while ago but I’m personally on iOS, so had no skills to make it happen. I did check out your website and it looks great. The additional features you included sound pretty cool. And thank-you for the acknowledgements on your page.

A couple questions just out of curiosity:

  1. Would existing drivers that used edgebridge be able to use your app unchanged? Is it just a matter of changing the IP address?

  2. What happens when the Android device leaves the home? Is it meant for smartphones or more for other, always-present devices?

Also thanks so much for the Buy-me-a-Coffee’s !! Much appreciated.

p.s. I added a link to your page from my edgebridge github readme.

Hi @TAustin

Thank you so much for taking the time to check out the site and reply — honestly, getting a response from the creator himself made my day. Thank you for putting such a great solution out into the world in the first place!

To your questions:

1. Yes! Existing EdgeBridge drivers work with AEB just by changing the IP address. I’ve implemented the full API, though to be upfront — some of the endpoints I don’t personally use haven’t been fully tested end-to-end. The implementation is all there, but real-world coverage on those specific paths is still a bit limited.

2. Good question. AEB is really designed for devices that stay at home — things like Android TVs, set-top boxes, or that old Android phone sitting in a drawer. The idea is more “give your old/idle Android a second life as a simple home server” rather than running it on your daily smartphone. So leaving the home isn’t really a concern in the intended setup.

Also, thank you again for the GitHub shout-out — that genuinely means a lot, especially coming from you.

Thanks again for everything,

Booung

That was me who asked.

I set it up on an Android TV box. That went smoothly. The EdgeBridge Agent automatically found the server.

In the SmartThings app it say: “OAuth Disconnected”. Is that normal, or a problem?

Thanks for the update — glad to hear the install went smoothly and the Agent found the server on its own!

“OAuth Disconnected” is normal, not a problem. The short version:

- For classic EdgeBridge functionality (drivers using the local bridge to reach external services), OAuth is not required — you’re good to go.

- OAuth is only needed if you want to use the LLM-powered features. Specifically, when you install my EdgeBridge Agent Edge Driver, an OAuth connection lets you use the “Command via LLM” feature — you can trigger LLM commands from SmartThings automations.

If you’d like to give that a try, here’s the quickstart that walks through it:

Installing the EdgeBridge Agent Edge Driver is what unlocks the automation-driven LLM commanding — that’s the part I’m most excited about.

Thanks again for taking the time to actually set it up and try it!

Booung

Thanks for getting back to me, and thanks for sharing this project with the SmartThings community.

It is really nice that no new hardware was needed. I already had 3 Android TV boxes plugged in and ready to use.

For anyone like me who doesn’t know what Edgebridge is it’s here,

@WooBooung and @TAustin I got Todd’s weather driver up and running with the Android Edge Bridge.

@WooBooung and @TAustin , I wan’t to bring this topic here to share my experience:

Yesterday, while browsing one Korean Smartthings community, I stumbled upon a thread about integrating the LG ThinQ API using an edge driver + EdgeBridge (https://gall.dcinside.com/mgallery/board/view/?id=smartthings&no=14539).

I immediately remembered this topic and an old Huawei MatePad T8 (EMUI 10.1 - Android 10) that was lying unused and decided to give this solution a try. Since this tablet doesn’t have native support for Google Play Services, I was able to install and Run Android EdgeBridge using GBox.

But what about the edge driver? I also found an excellent search engine for Edge Drivers (something Samsung could have made available officially a long time ago): ST Edge Driver Search & Finder | 스마트싱스 엣지 드라이버 검색기. Using this search engine, I was able to find the “LG ThinQ Bridge” driver developed by someone called “Lucentis”. This is the channel’s invite link: SmartThings. Add a little smartness to your things.

The LG ThinQ Bridge device automatically found the AEB server (mDNS). In the device settings, you need to enter the LG ThinQ PAT, generated at https://connect-pat.lgthinq.com/login, the region of your LG account, and enable the creation of child devices according to the type of LG device you want to control (air conditioner in my case).

After that, child devices were automatically created for each of the 3 air conditioners I have in my ThinQ app with a nice interface. The controls work correctly for most functions (except for the energy saving mode control and vertical oscillation) and several automation options are available for routines.

Now i will also transform the MatePad T8 in a nice dashboard with sharptools :joy:

@TAustin Thank you for EdgeBridge

@WooBooung Thank you for AEB

And thanks to Lucentis!!

Good stuff. Thanks for sharing.

Thank you for sharing such a great review.

Please help us spread the word about the Edge Driver Search Tool, LG Edge Driver, and AEB!

I have also shared this news with the creators of the search tool and the LG Edge Driver.

@TAustin A special thanks for opening up this whole new world for us!

Security concerns here: since EdgeBridge/AEB is just a call forwarder, the edge device that i am using to generate the calls can make calls to any external url.

A malicious developer could potentially exploit this to hide calls to harmful APIs, opening a bridge to the internal LAN.

Is there a way to configure a “whitelist” in EdgeBridge, so that it only forwards calls to specific/desired URLs?

Thank you for raising this important security concern. You make a very valid point. Currently, AEB does not have a feature to restrict target URLs. However, I completely agree that adding a whitelist feature is necessary to prevent potential LAN exploits. I will look into implementing a whitelist configuration in a future update so that users can control and restrict the allowed URLs. Thank you for the great feedback!

Can you please suggest to Lucentis to fully localize the interfaces/configurations of his driver?

I’m adding a whitelist for outbound forwarding URLs in AEB (Android EdgeBridge).

I’ll pre-load some well-known open APIs as defaults. Here’s the default-allow list I’m currently considering:

SmartThings : api.smartthings.com

LG ThinQ : *.lgthinq.com (login: *.lgeapi.com)

Tesla Fleet API : fleet-api.prd.*.vn.cloud.tesla.com, auth.tesla.com

Tesla legacy Owner API : owner-api.teslamotors.com (China: owner-api.vn.cloud.tesla.cn)

Tessie : api.tessie.com

Tuya / Smart Life : openapi.tuyaus.com / tuyaeu / tuyacn / tuyain

Philips Hue (remote) : api.meethue.com, discovery.meethue.com

Google Nest : smartdevicemanagement.googleapis.com

OpenAI : api.openai.com

Anthropic (Claude) : api.anthropic.com

Google Gemini : generativelanguage.googleapis.com

OpenWeatherMap : api.openweathermap.org

Telegram : api.telegram.org

Korea Public Data Portal : apis.data.go.kr

NEIS Education Open Portal : open.neis.go.kr

If there’s another service you use often, or a URL your driver needs to reach, please drop it in the comments and I’ll add it to the defaults.

(Later, you’ll also be able to add URLs yourself by tapping “Allow” in the blocked-domains menu.)

Currently, the Preference section does not support localization. I have informed the developer about this and suggested adding Korean alongside the English text.

Don’t know if leaving AI APIs whitelisted by default a good idea cause they also potentially can be used to generate some kind of malicious response. But, AI security isn’t a subject that I am knowledgeable about.

Perhaps you could consider a “zero trust” approach where no forwarding is allowed by default and only URLs that are added to the whitelist are forwarded. To make it easier, you could then provide this pre-loaded blacklist of well-known APIs, so the user can just click “allow” on what they really will need, also be able to add custom URLs manually.

New URLs sent by the drivers can be added automatically to the blacklist so the user can review and enable on his own risk.

I agree, I’ll remove the AI-related APIs from the default list.

​If I used a strict “zero trust” approach right away, all active services would suddenly stop working for users who don’t know about the update. To prevent this disruption, the default list will only include known URLs used by current edge drivers.

​For anything else, the app will show a list of blocked URLs, and I’ll build an intuitive UI so users can easily approve and add them to the whitelist as needed.