Enable public access to connected devices in your local network

Three options for public access to a Philips Hue light — go ahead, turn on the lights in my kitchen

In a recent livestream with my teammate Arlemi, we unboxed some lights and messed around with the Philips Hue Lights API. We figured out how to turn on the light and change the colors using an API.

Then Arlemi queried a weather API — he wanted to update the light based on the weather forecast.

But the light was with me in San Francisco. And Arlemi was in London. So I was the only one who could update the device during the livestream.

How can I let Arlemi, and the viewers, change the lights in my home from the comfort of their own pajamas?

Dear impatient readers : If you don’t care how I did it, skip ahead to the end, and you too can turn on the lights in my kitchen 💡

Why can’t anyone else turn on the lights?

You can log in to the Philips Hue mobile app with your Philips Hue account for remote access to your lights.

To use the Philips Hue Lights API directly, there’s a couple options. For example, if I’m sending these API calls from Postman on my laptop, there’s really only two ways to do it.

Local Area Network

I can send the request from within the same local network. Since my laptop and lights are connected to the same home WiFi, I can use Postman to hit the API. But if I go across the street and use my neighbor’s WiFi, then I’m no longer on the same local network.

Local Area Network: devices connected to the same network can access the light

So unless I’m connected to my local network, I won’t be able to reach my lights without providing additional information.

Remote access

The Philips Hue Lights API allows me to give additional information to authorize remote access, so my lights can be accessed from a different network.

Remote access: additional info required to authorize

But I don’t want to share my private account information with anyone else.

Let’s walk through a few ways to enable public access to our light, without sharing personal credentials.

• Port forwarding — the most straightforward option, but don’t do it
• Proxy in the cloud — place a proxy in front of your light, in the cloud
• Proxy in the local network   — place a proxy in front of your light, in the local network

Option 1 — port forwarding

The most straightforward option is to set up port forwarding for your connected light. Port forwarding enables external requests to your public IP on a specified port to be forwarded to a connected device.

Port forwarding: light is exposed directly to the internet

Don’t do this. Bots and malicious attackers scan IP addresses for exposed and vulnerable devices. And if my Philips Hue light has a vulnerability, an attacker can infiltrate my connected device and access other clients connected to my local network.

Also, you tell the users your public IP address for your home, which can reveal some personal details like your general location.

Next, let’s buffer against potential attacks and obscure our home IP.

Option 2 — proxy in the cloud

This option places a proxy in the cloud between users and the connected device. This buffers against some unwanted attention. By directing requests through an app, we can build custom checkpoints like validating user inputs or rate limiting into our app.

validate user inputs and rate limiting

Deploy your app on a cloud hosting provider like Digital Ocean or Heroku. This means you can invite users to send requests to the app hosted on the cloud, instead of your home IP address.

Now we control traffic from our friendly users. But we still need to set up port forwarding to route traffic from our proxy, so our light is still exposed to the internet.

Proxy in the cloud: place a proxy in front of the light

Even though you’re now handling legitimate requests from your users more cautiously, the light is still exposed. There’s nothing standing between potential attackers and the light.

Next, let’s thwart attackers by moving the proxy inside our local network.

Option 3 — proxy in the local network

The only improvement with this option is the placement of the proxy in the local network. If we move the same proxy from the cloud to the local network, we handle potential attackers more effectively.

This time we set up port forwarding to route traffic to our proxy. Attackers can still hit our public IP, but now we have a barrier between the light and the internet.

Once again, we control the data passed through and returned, but this time for every user.

Proxy in the local network: move the proxy inside

Tradeoffs and additional considerations

We talked about three options to open up your connected device to the public, and a few more considerations to further fortify connected devices. As always, the option you choose will depend on your specific situation.

pros and cons for each option to enable public access to a connected device

CDN

You can use a content delivery network (CDN) in front of any of these three options to obscure your home IP address. A CDN provider like Cloudflare also offers free protection against distributed denial of service (DDOS) attacks to throttle an intentional, or unintentional, surge in traffic.

Rate limiting : You can add rate limits at the infrastructure-level or application-level. Check out my tutorial to build application-level rate limits with Node and Redis.

NAT traversal

You can use a gateway to maintain a network address translation (NAT) connection by opening a two-way tunnel between a cloud proxy and your home server. This means you don’t need to configure your router for port forwarding and is secure from attackers who scan IPs.

Dynamic DNS

You can set up a dynamic DNS (DDNS) service for any option that requires router configuration for port forwarding. Check out my tutorial for using a free DDNS client like ddclient to automatically update your DNS record when your IP address changes, so access to your home server is maintained.

Here’s what I did

I wanted my Philips Hue light to be accessible to livestream viewers. So I ran an Express server on a Raspberry Pi in my local network (option 3). I used Cloudflare for DNS and KubeSail for NAT traversal so that I didn’t need port forwarding and could direct users to a public domain: https://light.meowsergirl.com.

here’s what I did

Go ahead, turn on the lights in my kitchen

Now, as promised, go ahead and turn on the lights in my kitchen.

• Example API calls in Postman — to update the lights in my kitchen
• Code sample in GitHub — to enable public access to your own connected devices

Turning on these lights is more de-lightful when you can see them. So follow Postman on Twitch and tune in to a livestream to see the effects of your API calls in realtime.