Most recent activity
-
I open a web server to get the SSID and password. Once the WiFi successfuly connects, I send a "connected" page and then i want to close the access point and stop listening on the web server. What is happening is the AP closes before the page is received or the event doesn't fire at all. I've tried "response.on('finish') " and as below "response.on('close') .
console.log(SSID + ' ' + password); SSID = SSID.trim(); password = password.trim(); console.log(SSID + ' ' + password); options = {password: password }; wifi.connect(SSID,options , err => { if (err !== null) { msg = err; index(response); throw err; } wifi.getIP((err, info) => { if (err !== null) { throw err; } print("ESP8266 IP: "+info.ip); connected( "response.on('close') ); response.on('close', () => { console.log('Stopping web server and AP'); server.close(); wifi.stopAP(); });Right-click seems to work. BTW, the manual control is for a caregiver or as a backup if the internet is not available.
BTW, I've order a ESP32 development kit.
-
I will not be making any decisions soon on a platform. I plan on getting an esp32 to test with. In any case, I putting this off for at least six weeks as I'm going on an extended vacation :-)
allObjects
...least because it is frugal power consumption, especially when you
go BLE for communication - battery driven / cordless...Power has never been a problem as they are always AC connected.
Bill, the founder, and primary source of funding is not too keen on changing platforms. He does the hardware builds and is pretty comfortable with the ESP8266. We will see how much he wants to do the Google Local Home.
As to the liability question, corporate insurance for sure. Bill does a pretty extensive interview with perspective clients to be sure that the would not have any problems with whatever position the controller might put them in. We have declined, unfortunately, some that might not be able to handle having the bed in any maximum or minimum position. There are waivers to sign, etc.
We do not have any way to determine starting or stopping positions on these beds as they do not have any sensors that we can interrogate. If we were shipping an entire bed, we could probably do that. But that is not the current model or would I expect it to change. The normal standard is to limit bed movement to 15 seconds for any command. That normally means the clients has to issue several commands to make the bed travel to a full up position, for example. We only support "turn On". There is no "turn Off" command.
One problem I had with node.js on the ESP8266 was the limitations to what was supported. I just needed a couple more unsupported events:
response.on('finished'); -
Thanks all. I have pretty much written off the 8266 for this effort namely Google Local home. Maybe the esp32 with WiFi but I'm thinking a Pi is in my future. I'll probably convert the existing 8266 Arduino IDE code to use MQTT just to be able to use the AWS or Azure IoT hubs. It looks like the webhook triggers there will mesh nicely with the existing webhook backend. BTW, the HTTPS issue was the final straw. Unfortunately my test back end has both HTTP and HTTPS enabled so I missed that.
"...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..."
The site is where all of the devices pickup requests. We have incorporated OTA, we can remotely reboot the device and get various status information. Given the way the 8266 handles certificates (or doesn't) we can push a new fingerprint to the device if necessary. There are also two middle-ware pieces, one each for Google and Alexa. Alexa requires an AWS lambda program for Smart Home. Google is any web endpoint will do. Everything is C#. Web sites are .Net Core. Everything is secured with JWT. Both of the middleware components handle "turnOn", "discovery/SYNC" and "QUERY" requests from Alexa/Google in conjunction with the web back end. We wrote our own lightweight oAuth server.
"...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)...." Not a bad idea and easily enough implemented. I may incorporate that in the next build. I'll try and remember to give you attribution.
In all this is a very rewarding project. You don't often have opportunities like this that really have such positive impact on these people's quality of life.
-
Thanks for the heads up on the typo. Currently we are doing just the US. If someone wanted to sponsor a non-US charity, I'm sure we would be happy to help get that started. We have an older open source version of the software and plan on making the new version available publicly on GitHub. It just takes some volunteers and a modest amount of money to have a real huge impact on people's lives.
-
I didn't explore this too much but yes the above code is what I had originally tried. When running it I got some error (can't remember exactly) like "lost prompt" and then nothing.
Having it outside fails to connect to the web site until the WiFi is connected but otherwise works.
-
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.
-
Thanks, the PROMISE is available on the 8266 and does work mostly. I would like to create the promise here:
wifi.on('connected',(details) => { var clearQueuePromise = new Promise((resolve,reject) => { --http stuff-- } });However, that blows up with nothing in the way of useful information. If I just create the promise outside of the wifi.on, and let it fail until the WiFi connection completes it does what I want although a bit messy.
var clearQueuePromise = new Promise((resolve,reject) => { idClearQueue = setInterval(() => { idClearQueue = setInterval(() => { --do http GET until successful--- clearInterval(idClearQueue); resolve("OK"); },2000); });And then
wifi.on('connected', (details) => { clearQueuePromise.then((resolve,reject) => { print('clear queue finished'); }); // This initiates the main loop idMainLoop = setInterval(mainLoop, 2000);Critical comments are welcome :-)
-
I'm in my first week on this project to rewrite an existing C++ 8266 application. Admittedly very much the novice using javaScript/node.js. I need to insure that function A runs before Function B in several different places in the code. I thought I would simply things a bit by using a node.js event from the EventEmitter class and trigger Function B from the event polling. Doesn't look like that class is supported. Any guidance on how to proceed would be greatly appreciated.
Developer for Limited Mobility Solutions, Inc.
A non-profit providing voice activated solutions for those individuals with limited mobility
http://limitedmobility.solutions