Search results for:

Ah, ok got it. The placement confused me and will others. @Gordon will move it for you.

If I had access to my Espruino Wifi I'd gladly test that for you, but I don't at moment. I can maybe test tomorrow for you.

Hi. ESP8266 is any incarnation isn't an Espruino board. They comprise "original", "Pico" and the latest "Wifi" boards. Anything else is unofficial including your ESP13.

TLS is available on the Wifi board as well as Pico. I think that's just a matter of the docs lagging behind the development.

I don't think the ESP8266/ESp13 will have enough room to store (1700 JSVars) the certs and keys to get you a TLS connection, but Espruino Wifi is a good bet.

@Wilberforce at 7000 that's comparable to Espruino Wifi, but i imagine there is a lot of work to do yet, before can know if that's realistically attainable. Anyway thanks for the update :)

Don't have a number in mind. I'm just intrigued at what applications might be possible on ESP32 given there's so many GPIO pins. My inference is that programs which orchestrate all of those pins will need more memory to run and flash in which to save the code. I recall the ESP8266 port moving up/down a few times as things progressed through the porting process, and finally exceeding all (certainly my own) expectations at 1700 JSvars.

So just interested to know if the upper memory (and save) space limits of ESp32 have been "prodded " yet and how realistic those limits might be.

Some great progress here. Has anyone make and arbitrary tests with > 5000 JSvars, to get a feel for what might be possible whilst keeping everything stable?

I came across this. It seems there are some hardware issues that cannot be bypassed by firmware, and another revision of the board will be released next year. Maybe nothing that will impact the ESP32 port, but maybe worth bearing in mind if trying to get hold of an ESP32 now.

http://espressif.com/sites/default/files/documentation/eco_and_workarounds_for_bugs_in_esp32_en.pdf

Have you tried it with a lower strength key? Maybe use 2048 bit. This worked for me using Espruino Wifi. Maybe it is same issue. See this thread: http://forum.espruino.com/conversations/293351/#comment13233636

Re first point - if I'm honest I can't give you a definitive answer. I think it's down to what save() actually does combined with the MQTT modules design. Someone more expert than me will tell you, and I think there are some good threads in the forum which explain, but I always try ensure that anything which does more than a simple require of a module is part of the code I explicitly run again at start up through an init function. Obviously the MQTT module calls create on the back of the require piece.

Re your last point, you can see this for a number of reasons. The IDE will look for an indication that the board is ready by looking for a console prompt. You may not have that perhaps because your first version saved code had started and already crashed the board? I am only guessing but it would seem likely.

I would bring the var mqtt= line, into the server>setTimeout callback, so that mqtt.create() happens in E.on("init", ...) too? Does that help?

Sounds like you need to use save() to persist your code to flash. It's not the default behaviour, what you load to the board over the IDE exists until powered off or reset.

Maybe a lack of memory to run, or free space in which to save your program. There is quite a lot going on.

I would start by removing the save() instruction and seeing if I can upload the sketch. Then I'd try to save the sketch by keying save() in the console on left of Wen IDE, and if both ok, try run the sketch - and for this it is useful to wrap all your init code in a named function you can specify as the E.on("init", ...) callback, instead of using anonymous function. You can them comment out, and call your init function from the console.

Worked well enough for me too. I haven't had any chance to look at Espruino this week yet, but certainly everything I did last week worked as expected. Ship it!

Pulled again, yes - that's better - now all the : and > stripped when copy/pasting. Will get hold of v1.88 soon.

Also you probably know git clone --recursive takes care of the submodule dependency so that git pull is sufficient to update that too (certainly in 2.7.4) which is much easier than cloning separately and pulling separately, but the README on the IDE repo does not reflect this. Maybe I will update, if ok?

It was a fresh clone this morning, didn't have it on this Mac previously.
No echo(0) on cursor up and has the green unpacked stripe. Maybe I copied as you said. No big deal though.

One idea for future development maybe? As I found recently minifying and concatenating the html for a webpage into a variable is a considerable pain in the backside, especially when you have to subsequently edit it. Could you support heredocs in the IDE - even though JS does not? And strip all the whitespace at upload?

Just a thought.

Copying from the console will automatically remove the annoying : and > characters from the start of each line.

Tested on Mac 10.11. Both serial and telnet comms works fine for me but I couldn't see the impact/benefit of the above. It seems to leave the chars in still, and behaviour seems identical to the to released 0.62 IDE.

I've got it and will be using sometime today

Just 1.1. And it has been fine. We brought the whole rc car project together tonight (thankfully) and have been driving it from iPhone - needs a couple of tweeks - but nothing major.

Thanks for your help on the websockets piece today.

If I may, Gordon you're a genius. That was enough to bamboozle Safari! I've got data and the connection seems just as stable as desktop.

Well that's worth a shot. Thanks again.

One further issue, maybe a showstopper. I'm now testing on mobile Safari and Google Chrome - both based on Webkit - and I get this in Mobile Safari (I'm not able to debug in Chrome but infer same)

WebSocket connection to 'ws://192.168.1.17:8000/espruinocar' failed: Invalid HTTP version string: HTTP/1.0

Looking into this, I'm not sure that HTTP/1.0 websockets are supported any longer. I seem to recall reading that Espruino HTTP/Websockets is still on the 1.0 standard. Is this correct?

I am guessing I'd fare better in Android :/

That's fixed it! Have messaging both ways in Chrome. Excellent thank you @Gordon!

It's a NodeMCU. I think it may have been that I had a persistent wifi connection with wifi.save() at the time. Anyway I've stripped that out so wifi connection is established at code send, but I'm still having issues - not related to ports but with the websocket module in general.

I worked it into my code last night and found it would not work in Chrome. In Firefox, the server can send, but the client cannot send back - or at least the message is never received.

I've stripped my code back to basically just run the server example on the websockets page and still no joy.

In chrome, nothing from the server and I get this in console.

WebSocket connection to 'ws://192.168.1.16:8000/my_websocket' failed: A server must not mask any frames that it sends to the client.

And an attempt to send with ws.send("...") gets this in response:-

WebSocket is already in CLOSING or CLOSED state.

In Firefox I get the server sent message MSG:Hello from Espruino!
But nothing back from the client. Also trying ws.send("...") from console also does not get received.

The connection appears to get upgraded based on my logging, but the ws.on('message', function(){...}) event handler never fires.

This is the code, almost identical to the example

var wifi = require("Wifi");
var ap2 = {
  "ssid": "xxxx",
  "pwd": "xxxx"
};
// Wifi connection
wifi.connect(ap2.ssid, {"password": ap2.pwd}, function(err){
  if(!err){
    console.log("Connected to Wifi");
    var page = '<html><body><script>var ws;setTimeout(function(){';
    page += 'ws = new WebSocket("ws://" + location.host + "/my_websocket", "protocolOne");';
    page += 'ws.onmessage = function (event) { console.log("MSG:"+event.data); };';
    page += 'setTimeout(function() { ws.send("Hello to Espruino!"); }, 2000);';
    page += '},2000);</script></body></html>';

    var onPageRequest = function(req, res) {
      res.writeHead(200, {'Content-Type': 'text/html'});
      res.end(page);
    };

    var server = require('ws').createServer(onPageRequest);
    server.listen(8000);
    server.on("websocket", function(ws) {
      console.log("Connection upgraded");
      ws.on('message',function(msg) {
        console.log("Message received");
        print("[WS] "+JSON.stringify(msg));
      });
      ws.send("Hello from Espruino!");
    });
 }
});

Could there be a problem with the module? I'm struggling to see how I could be going wrong?

Actually, it seems the board just needed resetting. Maybe already bound to another port - I don't know. Anyway it works.

@Gordon please delete if deem appropriate.

I can't get this to work. Other ports work fine, but if I try bind the server to port 80, I get:-

ERROR: Unable to create socket

All the examples seem to use ports other than 80, so I wonder if I'm missing something?

Thanks, @ClearMemory041063 - I'll have a look at those. Appreciated!