Most recent activity
-
As weekend is approaching, you might fancy going down the rabbit hole :)
Have a look at Cloudflare workers, you need a domain on their nameservers, but then you can configure a route - http allowed - and set up a worker (function) that responds on that route, and proxying requests can be done in the worker.
Really, just a foward proxy as suggested above, when all said and done, but quite interesting.
I had a look at IFTTT again (first time in a while) does not seem as flexible as it was, and the hooks piece now seems to default to https too, so not an option.
-
Not me, but you might look first at IFTTT. There could be something you could set up there which would take care of the heavy lifting, so you can focus on just the call/data.
-
Would you personally buy a pre-flashed ESP8266 though?
I might :)
Something pitched between price of the Espruino Wifi and the ESP8266 (unflashed), "could" make people think twice.
-
An idea which has occurred to me a few times - what about a bundle?
You bundle an Epruino Wifi (or maybe a couple) with say 3 or 5 ESP8266 boards with Espruino installed on them.
The pitch is that you prototype on an official board, but ultimately stick an ESP8266 into the final application. I've done this and I imagine others have too. It's cost prohibitive to lose my Espruino Wifi in say a remote control car for the kids, but it's nice to get things working on your breadboard with the Espruino Wifi.
With a bundle you sell more official boards, and support that board but make some margin on the ESP8266 as users don't have to faff with flashing it. Makers might go for the convenience of a bundle?
I think regardless of whether you support ESP8226/ESp32 you could make some margin off pre-installed boards? Is a £3 board worth £7, £8 or £10 with Espruino installed on it. For some users I think the answer is definitely yes.
-
I test for an IP address. This could probably be refined, but generally the ESP8266 connects to wifi quickly or not at all, say if the config is wrong:
if (wifi.getIP().ip != "0.0.0.0") { // rest of your code } else { console.log("not connected to wifi"); } -
The ESP8266 does SSL just fine like the ESP32 does.
It doesn't. The request is going over http / port 80. I'm pretty certain.
The ESP8266 http implementation would be better not sending the request at all IMO, because it's easy to think you've got a secured connection and if the server listens on 443 and 80 then you'd be none the wiser.
If you take it down a level into
http.request(), you can see what's what in terms of available protocols.let wifi = require("Wifi"); let http = require("http"); if (wifi.getIP().ip != "0.0.0.0") { let options = { host: 'http://www.google.co.uk', // note the editor has added http:// port: 443, path: '/', method: 'GET', protocol: 'https:' }; let req = http.request(options, function(res) { res.on('data', function(data) { console.log(data); }); res.on('close', function(data) { console.log("Connection closed"); }); }); req.on('error', function(err) { console.log(err); }); req.end(); }Note the port and the protocol/schema:
port: 443, ... protocol: 'https:'Responds with:
{ "code": -15, "message": "no response" }Change the port to 80 and you get your response, but the protocol is still
https:.When using
http.getall of this is obfuscated so it is easy to think you've got an encrypted connection.Fact of the matter is that ESP8266 is unfortunately too limited in terms of flash/ram to handle the certificate management required for HTTPS
-
You could get a lot of mileage from the Espruino Wifi maybe speak with @Gordon (Espruino creator and Official board supplier) before you write it off - but as you say Rasp Pi, particularly Zero W, is the other option.
One question if I may, how do you get on with approval/certification. The benefits of your solution are very clear - I checked your website - but the insurers always seem to be about risk assessment and ass-covering. If you would share how you approach this it could help others with your skills, put them to equally good use.
-
Looks like a great project.
A couple of gotchas to watch for, some might be problematic.
ESP8266 build of Espruino doesn't support TLS so you won't be able to call HTTPS endpoints. If you are having success it "might" be that ESP8266 is using the HTTP schema and the endpoint you are using is available on both. One to check.
Both ESP32 and Espruino Wifi have the resources needed to support TLS.
Another potential problem is available space. ESP8266 is quite constrained you can run out of both flash and sometimes RAM when handling your http response data if the pages are large.
Websocket & MQTT are other communication options supported in Espruino (above caveats re TLS still apply) and which would seem to fit your use case. The former works with Firewalls because it's using the same ports as HTTP/S and the latter usually works unless outbound connections are blocked, which isn't usually the default.
-
Edit: this (my suggestion) is not going to work for you. The callback fires immediately on upload, no connection required.
Send some dummy data? This method offers a callback on send. But I don't know if this guarantees data is received, and by extension a connection. Suspect not.
NRF.sendHIDReport(data, callback)https://www.espruino.com/Reference#l_NRF_sendHIDReport
The ble_hid_keyboard module uses it: https://www.espruino.com/modules/ble_hid_keyboard.js
My Github
My Blog