Search results for:

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.get all 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

Might be worth elaborating on what you are trying to achieve in your code. And if you can provide the full sketch it's more likely people can advise on your approach.

But, if it works, it is often good enough - at least for me ;)

You want to look into using promises if you're working on Espruino and using Javascript but I don't know if they're in ESP8266 as it's fairly constrained. If not you might be able to include the class with a custom build.

Did you try Flasher.js? It's been quite bomb proof for me

...a bit unfair to this little, cute guy

Absolutely. ESP8266 was a game changer. It's almost a pity that TLS is the norm nowadays - for that is its Achilles heel.

I can see both sides of the argument for support and not supporting ESP more. I think I've argued that more mainstream support for ESP would help the Espruino cause myself, but I totally get that Gordon makes a living from this, so he will channel effort into what pays his wages, and he will know best what those channels are :)

@pankleks I can promise nothing but you might have a look at this, which does this same thing as the espruino cli:

https://github.com/olliephillips/espruin­go

It's not been maintained recently, nor used much by me, so I don't know how it copes with modern Espruino, but it used to work very well. Maybe if there are issues it would be worth getting it back into shape.

Thanks @allObjects. Totally missed it. You've saved me, and no doubt the OP, some time for sure. Appreciated:)

You could connect up an ESP8266 to provide the Wifi/Internet. You could then run a server on the puck with the http module I think

See this post: http://forum.espruino.com/comments/14113­989/

Alternatively, if you don't need Bluetooth - just Wifi, then Espruino Wifi, ESP32 and ESP8266 will all allow you to run webservers on them - you don't need to go the RPi route.

You should expand on what you want to do here, and maybe why.

You "could", write a html/css/js page that talks to puck over web bluetooth. With some kind of application server, you could also get that to open in its own chrome window - or you might go the Electron route. This would not run on the Puck however, that isn't possible.

Here's an example of web bluetooth interaction with Puck, you can view the source js and that could give you a steer.

https://olliephillips.github.io/areyoupu­cker/

Hello! For me, if it was a specific room and I was not trying to track movement internally, I'd use a single puck outside the room - sort of like an alarm - especially if there's a defined route in/out.

Do you mean write code for the MDBT42Q in Python? If so, this is probably not the forum for you. Check out micropython which will run on similar devices to Espruino, though I don't know about MDBT42Q.

What I would say is you can accomplish the same objectives using Espruino & Javascript which is arguably a more useful learning curve, and you'll get plenty of help in this forum so stick around :)

It is probably just a case of modifying the codebase you are using. Here is some code that runs ESP8266 as station and access point.

let ap_ssid="test";
let ap_authMode="wpa_wpa2";
let ap_pwd="testtest";

let st_ssid="ssid";
let st_pwd="pwd";

let port=8080;

let http = require('http');
let wifi = require("Wifi");

let startServer = function(port){
  let server = http.createServer(function (req, res) {
      res.writeHead(200, {'Content-Type': 'text/html'});
      res.end(`AP IP: ${wifi.getAPIP().ip}</br>STA IP: ${wifi.getIP().ip}`);
  });
  console.log("server started");
  server.listen(port);
};

console.log("disconnecting all..");
wifi.disconnect();

// start ap
wifi.startAP(ap_ssid,{
  "authMode" : ap_authMode,
  "password" : ap_pwd
},(err)=>{
  if (!err) {
    console.log("AP started");
  } else {
    console.log("could not start AP"); 
  }
  
  // conect as station
  wifi.connect(st_ssid, {password:st_pwd}, (err) => {
    if (!err){
      console.log("station connected");
      startServer(port);
    }else{
      console.log("could not connect as station");
    }
  });
});

The server/page can be connected to on AP IP: 192.168.4.1 (port 8080) and the router allocated IP of 192.168.1.34 in this example.

Both the AP IP and station IP are displayed in the page.

AP IP: 192.168.4.1
STA IP: 192.168.1.34

Perhaps you can modify from here to suit your needs.

I'm pretty sure ESP8266 can function simultaneously in both station and access point mode?
Indeed I think that may be the default mode. Use wifi.getStatus and check mode. You are looking for sta+ap.

Your readings will be impacted by the environment, and will fluctuate, so the first thing you want to do is zero/rebase your readings. I don't think you can get a heading, but not withstanding that, once rebased you should be able to detect incremental changes. Obviously moving the puck (to another location) or introducing magnetic things near to the Puck will impact the reading again, so you'd need to beware of this.

There's also this proxy which may work for you. http://httptohttps.mrtimcakes.com/ by espruino forum member @MrTimcakes

Ok, glad sorted. Re https, there's not enough memory on the device for the certificate management. You can use official Espruino Wifi board, and I think also supported on ESP32.

I think ESP8226 build does not support encodeURIComponent(). See the docs - not available on devices with low flash memory. Try it without.