You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.
  • 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.

    Quite a while back when it was still just HTTP(S) available, push was not really possible... but there was a startup that built a instant messaging hub and a browser client - html and JavaScript - with the setup and the technology that could serve you very well... the startup go bought by google... of course... about and the domain disappeared... it was noob.com or something like that. Cannot find things on the Web anymore... The key function was that you could have this one instant messaging client and on the hub you would subscribe to all this plethora of instant messaging sites... like a federated instant messaging.

    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.

    In a stealth org I had this running for an app I can understandably not talk about in detail... but what I can say is that two html / js apps in two browsers on different machines could talk to each other / control each other using the JavaScript language binding of the Bayeux protocol via a Java Web app using CometD implementation approach on jetty on a 'private server at a home' at a third location - securely and authenticated - after signing into the app server. To our surprise, the latency was in the range of 250...400 ms only... out of the box, no tuning applied. We also had a 'local hub' in mind that would either forward to the 'global hub' if the 'other party' is not local to the same 'local hub'. Today I would go for a nodeJS server and hub implementation in JavaScript rather than a jetty and java setup (assuming nodeJS Web (App) server offers NIO - looks like it is possible reading this (old but still younger) article on DZone from 11'.

    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".

About

Avatar for allObjects @allObjects started