Non-local control of lights

[dudeofawesome]

One way to go about this would be to retrieve the user's external IP address when they attempt to control the light, and store that address. Then, when the user is not connected to their home wifi network, we could switch the app to sending the UDP packets to the external IP address, assuming the user has forwarded the correct port to the bridge.

[wjbeckett]

What about checking the network at app launch to minimize delay?

Could also prompt the user at setup to enter the SSID of their home WiFi network. Then could just do a lookup and if the SSID isn't the same or isn't connected at all, then send the command to the external address?

[dudeofawesome]

The problem is, external IP addresses for nearly all homes are dynamic, and the user is unlikely to realize when their external IP changes, so it would be best to figure out a way to detect that change and save the new external IP.

[eliotstocker]

the problem is that the user would still have to setup port forwarding etc on the router, so we cant make it just work :( i have tried it with port forwarding and it does seem to work (not very well, but ok) just think we need to look into a good solution.

perhaps UPNP fort forwarding rules

[dudeofawesome]

I'm not certain that this is a good analogous example, but in Modern Warfare 2 multiplayer, all servers are actually hosted by the players, and assuming they have a supporting router, they don't need to do anything special. (my router doesn't seem to support this though, so I have to forward a ton of ports to get multiplayer to work properly)

I don't know what technology this uses, but it seems that we should be able to use it for Light Controller

[eliotstocker]

yeah thats UPNP

[dudeofawesome]

Ah. perfect. Wouldn't that require the bridge to set itself up for UPNP though?

[eliotstocker]

yeah that might be the case, cant say i know a whole lot about it, lets look into what we might be able to do.

[dudeofawesome]

Actually, IIRC, back when I was using the official app (MiLight), it was sometimes able to connect to the bridge when I wasn't connected to WiFi, and this image on the LimitlessLED site would lead me to believe this is correct.

[eliotstocker]

hmmmm, interesting i cant say i have seen that work but i haven't used the MiLight app much at all as i created this app pretty much strait away after i got the bulbs. i wonder if it is doing the upnp stuff itself.

[wjbeckett]

Well the bridge uses 8899 right? Is that the port for all communication between the bridge and router?

If so, it should be as simple as port forwarding 8899. Right?

On Tue, 4 Nov 2014 7:40 pm Eliot Stocker notifications@github.com wrote:

hmmmm, interesting i cant say i have seen that work but i haven't used the MiLight app much at all as i created this app pretty much strait away after i got the bulbs. i wonder if it is doing the upnp stuff itself.

— Reply to this email directly or view it on GitHub https://github.com/eliotstocker/Light-Controller/issues/7#issuecomment-61614727 .

[dudeofawesome]

Some people don't have access or knowledge to forward ports though, so it would be good to have UPNP.

[sanzoghenzo]

Hi all, first, thanks a lot for this app. It would be great to have the requested feature, so I could completely ditch the original, app. I tried the "out of home" thing simply disabling the wifi of my smartphone, and my router doesn't have uPNP on. still, the milight app successfully connected and sent the commands to the wifi box. the only information that mi-light app shows is the MAC address of the wifi box... is there some magic involved? :) I'll try to investigate further

[mrwhale]

So here is documented proof that the milight app does do some magic upnp stuff http://www.milight.com/support/#A6 But can't find any code snippets on how.. :/

[eliotstocker]

interesting, perhaps the box itself is doing the UPNP in which case we just need to work out, the best way to access it from outside of the home.

[mrwhale]

Alright, just done a brief check on my router. I'm thinking it must be the box that does the upnp, this was in my NAT table (10.1.1.23 is the internal IP of my box). So I'm going to go with what @dudeofawesome said originally and just keep a record of the users external IP when on wifi so it can be used later. But also said, this could get tricky as most peoples internet is on dynamic (I know mine is) and it changes every week or 2 for me, but no doubt if you have flakey internet this will become a problem.

Could we just have this as an "Advanced" feature, so users that know how to use/and have ddns/portforwarding setup can use it. Would be the quickest and easiest to setup for now, and implement the automatic stuff later

Also just checked out that IP that its connecting to, not quite sure what it is, or what it does

http://208.113.204.254/

I'll do some more investigation tomorrow

[dudeofawesome]

What I was thinking was that when a user arrives at home and connects to their WiFi, we could detect their external IP, and save it. That way, it would automatically update the external IP, should theirs change. On a side note, I don't pay for a fixed IP, but mine has stayed the same for a few months now. The only times that it changes for me is when the modem loses power.

On Wed Nov 12 2014 at 2:30:44 AM mrwhale notifications@github.com wrote:

Alright, just done a brief check on my router. I'm thinking it must be the box that does the upnp, this was in my NAT table (10.1.1.23 is the internal IP of my box). So I'm going to go with what @dudeofawesome https://github.com/dudeofawesome said originally and just keep a record of the users external IP when on wifi so it can be used later. But also said, this could get tricky as most peoples internet is on dynamic (I know mine is) and it changes every week or 2 for me, but no doubt if you have flakey internet this will become a problem.

Could we just have this as an "Advanced" feature, so users that know how to use/and have ddns/portforwarding setup can use it. Would be the quickest and easiest to setup for now, and implement the automatic stuff later

[image: milight] https://cloud.githubusercontent.com/assets/7307429/5008621/527a8ca8-6ab2-11e4-89a9-f82e2cb16fbc.png

— Reply to this email directly or view it on GitHub https://github.com/eliotstocker/Light-Controller/issues/7#issuecomment-62698469 .

[eliotstocker]

good sleuthing guys! :)

do we have a handle if we are still sending UDP Packets when outside of the house or something else?

[mrwhale]

Yeah agree with @dudeofawesome. This is probably how the milight app does it. I'll do some wireshark captures tonight after work (I'm on Australia time)

[eliotstocker]

sounds like an easy enough setup. ill see if i can get anything working on that front

[mrwhale]

Alright, so I did some packet captures from my phone this morning over 3g network, and it seems they are utilizing another server to do its magic. From my above NAT table the box is making a connection to the server 208.113.204.254, (I'm going to go out on a limb here and say that all boxes will try and make the same connection)

And in the packet capture, I find that when I do some command from the milight app its sending those to that same server. Attached is the pcap of the transaction between my phone and that server

So in light of that find, I'm going to say that

1. box makes connection to 3rd party server - is persistant a. sends server mac address for use in identification
2. when your phone goes offline, milight app then sends commands to this server instead, identifying your box via mac address
3. 3rd party server then forwards command to box via that connection is already has with it

Okay so git doesnt attach files so here's the screen shot of the capture and a link to the file :)

https://drive.google.com/file/d/0B17OVOitwz3QUm1zR2N3WGlZQk0/view?usp=sharing

[dudeofawesome]

So does that mean we can use that same server too? If so, this seems like a really simple set up!

On Thu, Nov 13, 2014, 14:46 mrwhale notifications@github.com wrote:

Alright, so I did some packet captures from my phone this morning over 3g network, and it seems they are utilizing another server to do its magic. From my above NAT table the box is making a connection to the server 208.113.204.254, (I'm going to go out on a limb here and say that all boxes will try and make the same connection)

And in the packet capture, I find that when I do some command from the milight app its sending those to that same server. Attached is the pcap of the transaction between my phone and that server

So in light of that find, I'm going to say that

1. box makes connection to 3rd party server - is persistant a. sends server mac address for use in identification
2. when your phone goes offline, milight app then sends commands to this server instead, identifying your box via mac address
3. 3rd party server then forwards command to box via that connection is already has with it

Okay so git doesnt attach files so here's the screen shot of the capture and a link to the file :)

https://drive.google.com/file/d/0B17OVOitwz3QSEpTeUFiMDBGRVk/view?usp=sharing

[image: capture] https://cloud.githubusercontent.com/assets/7307429/5038285/0455faf8-6be3-11e4-9de0-1ec6c04c5f23.PNG

— Reply to this email directly or view it on GitHub https://github.com/eliotstocker/Light-Controller/issues/7#issuecomment-62980762 .

[mrwhale]

Yep! Don't see why not, although security is a concern here. Seems like all you need to do is construct a packet that includes the MAC address and the command you want to send and it will do it.

Guess this will tie in with service discovery too, if we can discover the box when on wifi, we can save MAC address details etc

Also, the server sends back a reply to tell you whether the command was sent or not, so we can include some user feedback too if using this method

I'll have a go this arvo at work, see if I can get my lights turned on by sending a custom packet to the server

[dudeofawesome]

I don't think that security is, in this case, a concern, as we don't add any extra vulnerability by simply taking advantage of a previously existing one.

On Thu Nov 13 2014 at 4:39:51 PM mrwhale notifications@github.com wrote:

Yep! Don't see why not, although security is a concern here. Seems like all you need to do is construct a packet that includes the MAC address and the command you want to send and it will do it.

Guess this will tie in with service discovery too, if we can discover the box when on wifi, we can save MAC address details etc

Also, the server sends back a reply to tell you whether the command was sent or not, so we can include some user feedback too if using this method

— Reply to this email directly or view it on GitHub https://github.com/eliotstocker/Light-Controller/issues/7#issuecomment-62992919 .

[mrwhale]

Yeah I'm just stating that that setup is not very secure, not complaining that we can piggy back off it :)

[eliotstocker]

@dudeofawesome @mrwhale i agree, it is pretty unsecure as if i had either of your Mac addresses i could control your lights, as we say for now it will do.

the next question is how do we differentiate from one place to another to save the IP, i think we need to think about adding the network discoverability as well so we can see that the box is on the wifi, and only then save the external IP

[dudeofawesome]

We only need to save the MAC address of the box, right?

On Fri Nov 14 2014 at 1:48:59 AM Eliot Stocker notifications@github.com wrote:

@dudeofawesome https://github.com/dudeofawesome @mrwhale https://github.com/mrwhale i agree, it is pretty unsecure as if i had either of your Mac addresses i could control your lights, as we say for now it will do.

the next question is how do we differentiate from one place to another to save the IP, i think we need to think about adding the network discoverability as well so we can see that the box is on the wifi, and only then save the external IP

— Reply to this email directly or view it on GitHub https://github.com/eliotstocker/Light-Controller/issues/7#issuecomment-63034026 .

[eliotstocker]

ahh yeah, true, but still need to find it some how

[eliotstocker]

right i have made some headway on https://github.com/eliotstocker/Light-Controller/issues/11 so that gets us a lot closer to this working

[eliotstocker]

I think i have a pretty good handle on this now, however i dont seem to have the ability to control the lights outside of my home at all, it would seem the ports arent getting automagically setup, can a couple of different people give me what theya re seeing in the upnp port forwarding? as im not sure how the port is setup etc.

[mrwhale]

Yeah had the same issue. I hadn't used the milight app for a whole, but tried to get some commands working from CLI from work. The server does give you some feedback though, which is good. Eg error:device unknown, or #oksent

It must register the bridge and after no activity remove it from its list because I kept getting device unknown errors. I'll have a play around again when I get home, do some packet captures to see where the upnp gets initiated from

[nagelm]

Capture file linked. Switched from wifi to 3G mid capture.

https://drive.google.com/file/d/0B4HemJ2lTjOHbVdDSXlFc0g4b0k/view?usp=sharing

[mrwhale]

Awww shit! good work @nagelm! thats the part I missed in previous packet captures. Looks like the command

APP#MACADDRESS#ST

Sets up the UPnP connection magically. After running that command twice (for good luck) I was then able to manually send a tcp command

APP#MACADDRESS#CMD#4700

to turn on my lights from command line (Using netcat you can craft a packet)

pi@raspberrypi ~ $ echo "APP#MA:CA:DD:RE:SS#CMD#4800" | nc -4 208.113.204.254 38899
unknown device: MA:CA:DD:RE:SS

pi@raspberrypi ~ $ echo "APP#MA:CA:DD:RE:SS#ST" | nc -4 208.113.204.254 38899
ok#SV#AC:CF:23:24:83:E6#ST#0

pi@raspberrypi ~ $ echo "APP#MA:CA:DD:RE:SS#CMD#4800" | nc -4 208.113.204.254 38899
ok#sent

After doing that command it works! Would have to figure out (Or guess) how long that 3rd party server keeps that connection open for though

That's my input for tonight, I'll have a play around again tomorrow and give feedback

[eliotstocker]

Sweeeeet I'll check that out soon and see what I can work out :) On 22 Dec 2014 09:35, "mrwhale" notifications@github.com wrote:

Awww shit! good work @nagelm https://github.com/nagelm! thats the part I missed in previous packet captures. Looks like the command

APP#MACADDRESS#ST

Sets up the UPnP connection magically. After running that command twice (for good luck) I was then able to manually send a tcp command

APP#MACADDRESS#CMD#4700

to turn on my lights from command line (Using netcat you can craft a packet)

pi@raspberrypi ~ $ echo "APP#MA:CA:DD:RE:SS#CMD#4800" | nc -4 208.113.204.254 38899 unknown device: MA:CA:DD:RE:SS

pi@raspberrypi ~ $ echo "APP#MA:CA:DD:RE:SS#ST" | nc -4 208.113.204.254 38899 ok#SV#AC:CF:23:24:83:E6#ST#0

pi@raspberrypi ~ $ echo "APP#MA:CA:DD:RE:SS#CMD#4800" | nc -4 208.113.204.254 38899 ok#sent

After doing that command it works! Would have to figure out (Or guess) how long that 3rd party server keeps that connection open for though

That's my input for tonight, I'll have a play around again tomorrow and give feedback

— Reply to this email directly or view it on GitHub https://github.com/eliotstocker/Light-Controller/issues/7#issuecomment-67817884 .

[khromov]

Hey everyone,

Very interesting topic. I have been looking into the remote access feature on Milight / LimitlessLED / Easybulb these past days and this thread was of great help.

The IP mentioned (208.113.204.254) is resolved from the domain www.anymilight.com if you look inside the Android app. (MiLight 2.0)

I haven't been able to capture the DNS packet from the Wifi box itself, it is likely cached locally. The box appears to run a small linux distro.

As a side note, you can reach the management page for the box by: http:///EN/management.html

@mrwhale and @nagelm have done great work. There are some pretty major security implications with the protocol. I'm going to be sending out a responsible disclosure to the affected resellers in the coming days. If you want to know more feel free to send over an email.

Here's a link to the Android app. https://play.google.com/store/apps/details?id=com.lierda.wifi&hl=en

[gdbgeek]

Great thread guys. Keep up the good work.

[mrwhale]

@LimitessLED Hey Hamish, You've implemented this into your version of the android app? Could you comment on this, see if we are on the right track with this feature?

Obviously we have just tried to reverse engineer the commands etc but if we can have comments from someone who has actually implemented this, that would be awesome!

[TameOfGroans]

Is this not an ideal use case for VPN?

Root not-required

https://code.google.com/p/ics-openvpn/

pfSense openvpn (for example)

[TameOfGroans]

please not upnp. instead how about dnssd or mdns? [zeroconf]

rfc linkage

http://www.zeroconf.org/

[TameOfGroans]

Ugh a pox upon www, http://no-www.org , I intended to http://zeroconf.org/

[LimitlessLED]

Installing vpn software is too annoying. I would not recommend using it. And does vpn software support UDP broadcast? Not normally.

[LimitlessLED]

Interesting concept, dnssd or mdns. Do you have more details on how this could be implemented. I could look at adding it to the wifi controller v5

-Hamish

LimitlessLED.

[mrwhale]

I don't think any of these are worth implementing. To much overhead, protocols involved. Creating and maintaining a server in the middle (like what is currently implemented) or like what easy bulb is doing with their ones (http://easybulb.com/api/, but add more security) would be the most stable, user friendly. Make the wifi box have a persistant connection to this server, so when you are out and about, you can control the lights by sending commands to this server. If you have a sign up section, so people have to login this would keep it secure.

I will assume this is how most of the other major smart lights do it too (Phillips hue, belkin) as you have to sign up/login to the apps etc. Could always make it optional too so its not necessary to login (if you don't want this feature)

Anyways, just my 2 cents on the matter

[eliotstocker]

It seems to me were still best trying to implement the built in global control solution, the problem I have is that for whatever reason it doesn't appear to be ring itself up properly at my house, other upnp devices are fine but the box doesn't seem to be opening any ports or anything. And isn't control able from outside the house with the original app.

So of course with that in mind I'm not quite sure how to go forward with the development on this, maybe I'll put together a quick test that someone can try and we can go from there?

[mrwhale]

Sounds good! The upnp works fine in my setup with the original app, so happy to try and tests you have

[mnwalker]

Hi, This is a task I was planning to achieve for my lightbulbs but thinking its probably best to collaborate than compete.

My plan had been to introduce a bunch of additional functionality on a raspberry pi based server. I know it isn't an out of the box solution, but I simply can't think of any alternative to deliver the feature set I am after.

1) Remote access API (Pi can control DDNS and UPNP, or even initiate a socket connection to central server) 2) IFTTT support (proper channel would be amazing, but until then have workarounds using wordpress calls) 3) Timers and schedules that don't depend on the phone being on the network. (Security lights, Nasa style sleep patterns etc)

For simplest usage this would need a communal plug and play central server, but if you can put a custom address into the app and Pi then those with the knowledge and desire could run their own.

Whats all of your thoughts on this?

Mark

[mrwhale]

Hey Mark, Great idea's you have, I also have a raspberry pi, and do similar things to get around the shortfalls of the wifi lights design

1) Remote access API would be awesome, you could set one up yourself on the pi using (https://github.com/mrwhale/LimitlessLED) this PHP API. Create a php page that is remotely accessible from your phone etc The remote access server that the wifi box currently uses doesn't have a documented API (apart from what we have found in this thread) so unless someone here can create/maintain a central server, like what easybulb do, everyone is on their own :( (I would be more then happy to maintain such a thing, but this would require someone to find/modify the current firmware to change where the wifibox makes the connection to) You could definitely use the RP to keep initiating the socket request to the current server using cron to periodically contact the server to make sure the connection is still alive

2) I have yet to try out the IFTTT wordpress hack, I am secretly waiting/hoping someone creates an official channel. But unless a proper remote accss API is set up, I don't see this happening

3) you can use this bash script I wrote to control the lights on the raspberry pi (https://github.com/mrwhale/limitlessled-bash) to create timers and schedules with cron. I currently use this in my home setup. i.e. cron will turn the lights on at 6am duing the working week (which is the time i wake up) and it will turn the lights off again at 7am (when I leave) You could also use this and create schedules. i.e. create a script that checks to see if you phone is on the wifi (is at home) and when you arrive home, turn the lights on ( I would recommend you use Tasker on your phone for this though) But possibilities are there. Let me know what else you are thinking, as I have created a few hacks of my own to use on my pi at home - be happy to share with you

[LimitlessLED]

Thanks I have taken those ideas on board, and may look to include all of them into the limitlessled wifi bridge v5.0 firmware.

•    Cloud service address setting via API

•    IFTTT support

•    Timers and Scheduler built into the wifi bridge firmware – settings pushed out to the wifi bridge via API

[mnwalker]

Ah great news, having it natively on the controller would be the ideal solution. Would eliminate my need for a Pi in the middle and bring costs down. I can do web and mobile but wouldn't know where to start on the controllers firmware so glad you are able to help on that side.

On a related note, is the wifi controller for the LimitlessLED much different compared to the generic milight controllers? And if different is it in the hardware or just firmware.

Also, IFTTT support may be overkill for the actual controller since it would need inbuilt DDNS to make that work. But if you can build Cloud service address setting via API into the controller then IFTTT can easily be provided. I would be happy to build the open source cloud service part and host a communal server for people wanting plug and play ability - could be cross compatible across the various different apps. But will need some agreement on the best route and how/where to implement the IP updates and server calls.

Regards,

Mark Walker

T: +66 (0) 815 884 380 E: m@awcode.com W: http://awcode.com

On 3 March 2015 at 17:28, LimitlessLED notifications@github.com wrote:

Thanks I have taken those ideas on board, and may look to include all of them into the limitlessled wifi bridge v5.0 firmware.

• Cloud service address setting via API
• IFTTT support
• Timers and Scheduler built into the wifi bridge firmware – settings pushed out to the wifi bridge via API

— Reply to this email directly or view it on GitHub https://github.com/eliotstocker/Light-Controller/issues/7#issuecomment-76921422 .

[eliotstocker]

@LimitlessLED Statefullness would be a great idea also, so we could ask the bridge what the last recorded state was :D

[LimitlessLED]

That still would not cover the fact that remotes can alter the state of the light too. And resetting the wifi bridge would lose the state.. it is not possible sorry. They are more like remote command operated only, you just set the light to what you like.

-Hamish. LimitlessLED.