Events

Sure we can explain the application. We are a now, small charity that provides at no cost custom-made voice activated bed controllers for people with limited mobility. Essentially the 8266 becomes a remote device. You can check out the charity at http://limitedmobility.solutions .

From either an Alexa SmartHome or Google SmartHome device, our clients can voice activate their beds, sometimes doors, etc. If we can buy it off the shelf we do and our goal is to encourage bed manufacturers to provide a solution. However we estimate that there are at least 100,000 older beds that are not voice activated in use by people with severe limitations to mobility. Each bed model seems to require a custom solution. The 8266 is used to activate servos, sometimes RF, whatever it takes to operate the bed. My partner does the hardware.

We designed this application as a prototype two years ago using the most expedient approach. It has worked so well that we have not made any basic changes to design but are always open to changes. I have always been concerned about the polling aspect which I will address later.

So basically 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.

This particular POST was in response to the need to clean out the LIFO queue when the 8266 starts up. If the controller goes offline for some reason, a client may issue multiple voice requests before the unit comes back online. We do not what any unexpected bed movements because of residual requests in the queue.

Needless to say, the setup of a bed controller has to be super easy. We rely on caregivers to do the installation. Almost always these are remote installations with us providing phone support, videos and hard copy documentation.

One of our early decisions was to not require any router firewall changes. https outbound always works.

The reason we are experimenting with a javaScript solution is because Google is announcing a Google Mini solution where the local "device" can talk directly to the Mini by-passing the need for a persistent internet connection. The only time the current solution fails is when we lose internet connectivity to the web servers. The Google solution is based on a provided javaScript library.

Polling could eventually have some performance issues for us. But at 20 clients currently, it is really not an issue. I issue a http keep-alive to the servers which greatly reduces any certificate processing.

I am looking at some IoT technologies but so far everything that is "push" would require firewall changes. It may come to that eventually.