Improving smarthome response time by utilizing sockets

Previously, blocks used HTTP GET requests in order to get their data to the server. It works well and is easily implemented, but it’s slow as hell. A second, give or take, is a loooong time for timing critical applications. Let’s assume just for the sake of it (and definitely not because I’m doing exactly that) that I’m developing a network-controlled flamethrower.

Utilizing HTTP requests, it’d need to pull the desired setting (on / off) from the server. Where does that setting come from? Well, it’s set by another device which needs to first use a HTTP request in order to push the setting to the server.

At worst, that’s more than two seconds to change the state of the flamethrower. You definitely don’t want to wait two seconds for it to turn off.

Let’s assume pure TCP sockets: The whole startup time of handshaking and what not is already done. The only thing you have to wait for is sending the data from controlling device to server (a handful of bytes), check events on the server (a few milliseconds) and finally sending the data from server to flamethrower.

That’s what I implemented the last weeks. There’s currently running two PHP daemons on my server: The first one handles plain TCP sockets, the second one Websockets. By setting an identifier, devices can be adressed and receive messages. A controlling device for example could tell the server to send a message “turn off” to a connected socket with identifier “flamethrower”, which in turn turns off the flamethrower.

Adding sockets to my ESP_Basic framework wasn’t that hard, though I still had to fiddle a bit here and there. But now I can easily add timing critical devices (like flamethrowers, though I would never do that) to my system, which makes the whole thing definitely worth it.