Alexa/Google sends a turnOn request to our backend. We pretend to be be a switch. The request goes into a LIFO queue via a https GET. The 8266 bed controller polls using a https GET. The remote web site returns the latest request and deletes any older ones. The 8266 does what it needs to do to operate the bed.
The terms our backend, We pretend, FIFO, ...this is all a site that is available for all the registered HW control devices to pull from? Neat solution.
To overcome the issues of polling can be overcome by NIOB - non io blocking http(s) application server and long lasting http(s) GET requests.
How did it go:
- The client / browser / your remote controller would send a GET to the hub server.
- If an entry is waiting on the hub server, it would return immediately with the response.
- If no entry is waiting, the request would eventually timeout, but triggered just the next one.
This technology is against the initial idea of http protocol: request comes, gets served, and is stateless, resources are freed to serve next request / requestor. These long running request tied the resources - sessions - quite quickly: too many pending requests. That is when NIOB implemented: a pending request can be suspended in the the server, the thread is freed and handle other request, either incoming, or, when response is ready, pickup a suspended request and complete it. See http://tutorials.jenkov.com/java-nio/non-blocking-server.html - which describes this... kind-a.
Most application servers have this NIO technology implemented. At that time - quite a while ago - there was even a protocol developed and implemented in many language bindings. Using just two outbound http(s) connections provided the overall application with bidirectional push functionality.
...'found'/recalled the technologies: CometD, Bayeaux Protocol, (AJAX) Long Polling, Pub-Sub. Found also the CometD site and the salesforce developer site talking about.
Today, as @Ollie mentions, Web sockets & MQTT is the way to go... but it was not (yet reliably) available then and may still today require more sophisticated setups.
To make things simple, I would quench older - not picked up messages - on the server level rather than in the client level... messages arrived on the hub and not picked up within threshold just 'evaporate' connection is not present (goes absent for too long, no long poll request is waiting or showing up).
After all, quite an interesting project...
If the controller software is simple enough and https communication software still fits on a ESP8266 (see #232 How to secure our devices using SSL (ESP8266, ESP32, Tutorial) - Andreas Spiess, youtube
), it may still work. Espruino is then sadly out of the pic... To start prototyping: yes, Espruino-Wifi is a good platform. Could you also consider using BLE for communication between HW controlling devices and local hub? - then Espruino Puck/Pixl/MDBT42Q breakout board/module are viable options too with a local hub. And for the local hub: some RaspiPi... w/ Espruino or nodeJS. With a powerful enough platform the logic - FIFO/LIFO - can reside on it and the global hub works only as a "comm switch".