How would you architect this?

For many months I’ve been working on a home automation assistant. It’s not yet ready for public consumption but I’m very proud of it. It takes a natural language input, figures out the intent of the user and executes scripts based on that. It’s written entirely in Xojo with the scripts being written in my own scripting language, Roo (itself written in Xojo).

The current architecture is that the user has a Xojo desktop app running at all times (the “server”). This takes requests from clients on the local network in the form of HTTP POST requests (the server uses Aloe Express under the hood). The server responds to the client using the Aloe Express Request object (essentially a SSLSocket). All of this works nicely.

What I want to be able to do is allow the user to send the server a request from outside their home network. Does anyone have any idea how best to architect this? Obviously the client app that is outside the user’s local network will have to somehow get a HTTP request to the server which is inside the user’s home network. I don’t mind having an intermediary Xojo web app/PHP web app that mediates the connection but I have no idea how to maintain a connection between the server on the user’s home network and this intermediary server. I really want this to be as seamless as possible without having to get the user to manually open ports, etc on their router.

For those that are familiar with Plex, I am trying to mimic their remote access approach.

Any ideas are greatly appreciated as I don’t want to start this on the wrong track.

Thanks,

Hole punching, I wrote a TCP server, it’s on beta but it works, PM if you want to test it.

What I’ve seen in my own home automation equipment is that there’s an external service and the devices themselves make an http connection periodically to send their current status and to see if any changes need to be made.

More and more this is the common behaviour. Since home internet is becoming more and more protected and closed down (for good reasons) it becomes harder to connect directly to a device inside the home (and when it’s possible, it’s usually necessary to do a lot of configuration in the Internet router).

The way services like Plex do it is they first try to use UPnP to open a “hole” in the router, telling the router allow mapping a port inside to the relevant machine. This way clients can connect directly as long as they know the IP (or the IP is mapped to a dynamic DNS so they can connect by name).

Then they connect to a central server, that is the one really handling all connections. The “home server” keeps a persistent connection to the central server, which in turn acts like a dispatcher.

All clients then connect to the dispatcher and it in turn handles the requests:

1.-If the home server was able to open a port then the dispatcher redirects the client to that direct port and removes itself from the chain.
2.-If the home server was not able to open a port then the dispatcher handles all communications as a gateway, where both client and “home server” are connected to it.

For something like home automation the second option may be feasible (perhaps under a subscription payment) and as long as video is not transferred bandwidth shouldn’t be that high.

Thanks very much for the explanation Eduardo. That’s really helped point me in the right direction. I shall look into UDP hole punching.