Posted at 2015-08-26 by DrAzzy

My first thoughts would be to look at the apis for the wiznet and cc3k

But there should probably be some thought given to whether that's what we want long term.

I mean, it certainly needs to support the existing http system...

But beyond that... What are the sorts of functionality to be exposed? Beyond simply making http requests, and acting as an http server, I mean

Posted at 2015-08-26 by Kolban

@drazzy,
This is good ... so let's follow this through ... and thanks for the names of wiznet and cc3k, I didn't know where to start. If we look here: http://www.espruino.com/WIZnet

We find a bootstrapping of:

var eth = require("WIZnet").connect();

Now ... for an ESP8266 (or a board with native WiFi), I would not imagine we need to require a module ... I would imagine it would "just be present". So I'm imagining an object called "WIFI" being already present in the JS context.

So where in the example for WIZnet we next do things like "eth.getIP()" we might do things like "WIFI.getIP()".

Looking at the CC3000 this looks close to a WiFi story. See:
http://www.espruino.com/CC3000

there we have

var wlan = require("CC3000").connect();

and I imagine that the ESP8266 WIFI object would be a predefined instance of something like that.

But then we get into interesting notions such as the ESP8266 not only being able to be a station ... but also be able to be an access point that other WiFi stations can connect to.

... and all of a sudden ... we start entering the world of "architecture" and "specifications". What I would like to avoid is the notion that ESP8266 does it one way, CC3000 does it another way and un-named devices yet to come do it other ways. Ideally we define the capabilities of an abstract WiFi device and then define the functions on a representative class such that a concrete implementation can "just be" dropped in... where boards such as the ESP8266 already have concrete implementations already present for use without any require() statements.

And this is where we as a community and project owners need to come together and put our heads together. I think progress on ESP8266 networking will have to be suspended until we can figure this one out as the decisions made here will reverberate down the line. Ive internally tested WiFi and TCP/IP working concurrently on the ESP8266 with Espruino and no issues ... so we are literally at the stage now of deciding how to externalize for consumption.

Neil

Posted at 2015-08-27 by RandyHarmon

Neil, I'd figure there'd be a driver, at least architecturally. It sort of sounds like you might be wishing for wifiDriverX, Y and Z to each provide a standard wifi interface, so that you don't have to care what driver is in play - just call wifi.connectAP() or some such. You could write such a driver layer, with each function implemented in terms of the respective wifi libs, but more layers don't come for free.

Speaking of native ESP8266 coding, I've been playing with Lua on the ESP8266, which is interesting, but it's not Javascript. The especially interesting part for me is how the ESP8266 SDK (which enables application code to run on the same hardware being used for networking) is mapped onto the Lua runtime: C functions, registered with the SDK for specific events, calling into the Lua code through the standard Lua C API.

Within this SDK framework, the SDK (not an OS) takes a turn processing network traffic, then calls into your application, where you take a turn doing stuff with pins and lights, say. 6 alarms are built in at some level, though I'd expect you only need two and a setTimeout data structure (that's the purpose of the alarms). Pin-triggered interrupt(s), etc... All analogous to how we arrange event-oriented programs on Espruino.

All very encouraging in terms of making Espruino run there. Yielding to the SDK in the JS event loop is key.

One downside of the CPU-sharing for the developer is that if your event-handler does very much work, you run the risk of interfering with network operation. That's where I'm actually quite keen on Espruino, in that you can easily optimize those particular time-sensitive functions with pre-compilation. Maybe nodemcu has an option for that too, but I haven't found such a thing.

Posted at 2015-08-27 by @gfwilliams

I'd look at the existing ESP8266 module. Down the bottom there are a list of functions... createAP, getAPs, connect, etc. It'd be nice to make those consistent - whether we're running on the ESP8266 or just using it as a separate module.

I've tried to arrange that the calls are at least named the same in ESP8266 and CC3000 (and WIZnet where functions are shared), although in the ESP8266 module everything uses callbacks, which is something I think we should stick with.

As far as a built-in variable for ESP8266, I'd say don't do this. I tried it for the LCD on the 'HY' boards that have built in LCDs, and it was actually really ugly. Using require would definitely be a way to make the ESP8266 support fit in with everything else, and still having the connect() function could be useful - for instance it could actually initialise the WiFi adaptor (which you might not want to initialise by default). In the future it could take an object where you could specify things such as transmit power - so if you were doing a project where you knew you couldn't supply the full 400mA, you could specify that even before WiFi booted up.

Implementing the actual API shouldn't be too hard. I've already split everything out in this directory so it'll just be a matter of making your own ESP8266 directory and filling in the relevant bits.

Posted at 2015-08-27 by @gfwilliams

The wiznet implementation is probably the cleanest one to look at. Basically just 4 files:

• jswrap_X.c/h the implementation of connect/getIP/etc
• network_X.c/h the implementation of the socket API that's used

If yours can fit in the same kind of style it opens a lot of possibilities - for instance it would be relatively easy to modify the existing code such that multiple network adaptors could coexist. You could have GSM and ESP8266, and could be using both at the same time.

Just to add, we also have GSM, so:

• SIMcom GSM (in JS)
• ESP8266 module (in JS)
• CC3000 (built in)
• WIZnet W5500/550io (built in)

And they all use the same form of instantiation and have the API functions named the same where possible. It would be a big help to everyone if this one worked the same way as well.

Posted at 2015-08-27 by profra

If I understand the contents of discussion I would recommend to look at nodeMCU

https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en

There is a complete set of network functions defined that could be an inspiration for you.
This should have some advantages:
a/ Gordon could probably implement all by using "require" if ESP modul with AT commnads is used with Espruino,
b/ Neil could implement these functions direct in JS for ESP (the functions are already written by creators of nodeMCU),
c/ the users of both HW solutions will use the same language and interface.

P.S. Sorry, English is not my mother language.

Attachments:

• nodeMCU_INDEX.png

Posted at 2015-08-27 by Kolban

@profra
Good post. I am not familiar with Lua which I think is the language that I think is used in this binding. NodeMCU has two stories ... one is an ESP8266 board (which should be able to run the Espruino port) and the other is their IDE/Lua language. The APIs that you listed match almost exactly the "C" language bindings supplied by the ESP8266 SDK. (The ESP8266 is made by a company called Espressif ... this is the raw IC that IS the ESP8266 which board makers then include in their boards. Espressif provides a C language set of libraries that can be linked with a C application to achieve WiFi, network, GPIO, timers etc etc ... it is this SDK API that is being leveraged by the Espruino support for the board specific capabilities).

I had assumed that we had walked this space before and there would have been a prescribed strategy that the ESP8266 support would simply "follow" ... however, I'm starting to get the impression that this may be "relatively" new ground. What I think I'll do is do the deep research and make up a "report" on the different APIs that are being used now for networking in Espruino today as well as the APIs being used by ESP8266. However, I believe I want to stay away from anything that would smell of ESP8266 specific ... the goal should be that the ESP8266 should be "just another board" and even if I arrive at Espruino as a skilled ESP8266 kind of guy ... the story should be that this is an Espruino story. To make progress and allow testing, I'm thinking of continuing design and implementation with a class name that may be "EXPRIMENTAL_ESP8266.". Obviously that will not be the final method name or structure but changing names and parameters will be simple once we figure out the API structure we want while at the same time not blocking anyone who wants to continue with the board support. I don't want to stall through analysis paralysis and as long as the method names have no ambiguity that they have not been finalized, we should be ok and not accidentally make something that would lock us in ...

Posted at 2015-08-27 by DrAzzy

Yeah - we already do require() for built-in modules, for WizNET/CC3k, http...

For the ESP8266, though, there are some extra functionality - you mention getting a console through telnet. That's a really cool functionality, and it'd be great if that was exposed - but I'm not quite sure what the right API for that is. We'd probably want it to act like a serial port, but we'd have to deal with the possibility of there not being anything connected to telnet.

Posted at 2015-08-28 by @gfwilliams

I'm starting to get the impression that this may be "relatively" new ground

There are 4 different ways to connect Espruino to the internet right now, and they all use the same basic API. I don't see there's any reason why the 5th way of connecting Espruino should magically have a different one.

Sure there are some extra functions you'll want to expose, but it should be possible to do those in a similar way to the existing ones - and maybe we could tweak some of the existing ones such that they match up better (for instance making the functions appear async on CC3000/WIZnet, and making getIP on the ESP8266 return an object).

It's useful to try and make each single function as extensible as possible. For instance on WIZnet/CC3000, the setIP function lets you set the IP, but also the Mac address (on WIZnet where it's possible), dns, subnet and gateway.

you mention getting a console through telnet. That's a really cool functionality, and it'd be great if that was exposed

... but that should be something that was available for all network adaptor types. As there is already an abstraction layer for the socket API it seems completely nuts to implement the telnet functionality at a lower level so it only works on one device.

Posted at 2015-08-28 by Kolban

Howdy @gfwilliams,
Completely with you. What I am going to do is study all the APIs ... and see if I can't get close to what the community wants. I'm a huge fan of written stuff and plan to document the hell out of the work I do ... Open Source if fantastic ... but no-one wants to write stuff up. This post was to see if anyone wanted to "help" do some of the research and say "this is the API you should use" ...

As for the Telnet, I agree 100%. When I started the project, I couldn't get the serial stuff working but because the ESP8266 is a WiFi device, I could telnet into it and drive the JavaScript exactly that way. Now that I am starting to get something working, I am thinking that I can see that ESP8266 support can supply a Telnet story via JS level ... and hence NOTHING is likely to be needed at the board/code level.

Neil

Posted at 2015-08-28 by @gfwilliams

Great!

I guess at some point we could write a Telnet module in JS that handled telnet - it might be it needs some firmware tweaks to work properly, but it would be a good start. Something very useful would be at minimum a password on the telnet connection ;)

Posted at 2015-09-04 by DrAzzy

A Telnet module that would give you something that looked like a serial port so you could put the console on it when someone connected would be very useful. I'm not sure where my reply here went, I remember posting here about how awesome Telnet console would be, but the post seems to have vanished. That would mean you wouldn't have to provide for easy physical access in order to make code changes....

Posted at 2015-09-04 by Kolban

Actually, the good news is that I had that working before I had serial working. The ESP8266 is great at being a network device and telnet client support was plain easy. What I'm hoping is that as part of the telnet support we can look into adding that as a supported mechanism for the IDE so Telnet would become just another "connection option".

Posted at 2015-09-07 by @gfwilliams

we can look into adding that as a supported mechanism for the IDE

Yes, there's actually something built in for that already. However because it's a web app there could maybe be some complications - I think the existing code could be node.js only...

Posted at 2015-09-21 by Kolban

Howdy Gordon, is there any basic write-up or other docs for network access as opposed to serial access for the IDE?

Posted at 2015-09-21 by @gfwilliams

Nope - however the implementation of it is here - looks like it's actually designed to work with Chrome.

To get it working, create your own local copy of the Web IDE, then change serial_chrome in main.html to serial_socket: https://github.com/espruino/EspruinoWebIDE/blob/master/main.html#L75

I have a branch where both can coexist, but I haven't merged it yet.

Posted at 2015-11-26 by tve

I took a pass at the esp8266 wifi library and reorganized Neil's code (the core of the code is largely unchanged). I'd like to discuss the result in the context of the generic wifi library. I tried to document each function as well as I can, but I'm sure there's room for improvement. The result can be seen at https://s3.amazonaws.com/s3.voneicken.com/espruino/functions.html#wifi
For reference, the wiki discussion about all this was at https://github.com/espruino/Espruino/wiki/Generic-WiFi-Design
The reorg follows much of the wiki, but isn't the same by a long shot.

One item I have not resolved is asynchronicity. It seems that all functions have to be async in order to work for wifi modules connected via serial. Is that true or does it not really matter when a high enough baud rate is used? I have to admit that I don't like the async getters because it turns simple things like finding out what the IP address is into callback hell. The best I can come up with is to add an optional callback parameter and to document that using the direct return value may not be as portable. This way the user can decide whether to use the more portable callback stuff or not. :-)

Note that what I have isn't yet working. I worked on the docs first in order to get this discussion going so I'm not changing the whole thing twice..

NB: I also tweaked the ESP8266 library to remove some overlap and there are remains of the ESP8266WiFi library in the doc file that will go away.

NNB: I find the formatting of the documentation to be really painful. Specifically, I can't figure out how to reliably get a bullet list into the description section and I find the fact that each newline starts a new paragraph (as opposed to needing an empty line) frustrating too.

Posted at 2015-11-26 by @gfwilliams

Great!

For the async stuff - yes, you definitely need it async for devices connected on serial - as the processing of serial data only happens in the idle loop. Espruino (and also the ESP8266+GSM modules) would need some pretty major mods to fix that, but your optional callback sounds like a good idea... 'Use this to be portable, or if you don't care then just use the return value'.

With the doc formatting, it's because I have a really hacky markdown parser in build_docs.py. It'd be great if there was something simple that worked properly and could be pulled in (I'm tempted to use use node.js for building the docs, and marked works really well).

Posted at 2015-11-26 by @gfwilliams

Just some thoughts here:

• Can getRSSI just be a field in getStatus? Seems odd to have a specific function for that one thing.
• Maybe onChange should be removed and wifi should just have events emitted on it, so you could do wifi.on('connected', ...)? You can document events via JSON - have a look at jswrap_http (I think).
• I know this wasn't in the Wiki version, but someone mentioned about positional parameters to connect and startAP - maybe the password/key should be in options instead, as it's not required if you connect to an insecure network?

Posted at 2015-11-26 by tve

Can getRSSI just be a field in getStatus? Seems odd to have a specific function for that one thing.

Sounds plausible. getStatus is becoming quite the monster, I hope we don't run into issues with that...

Maybe onChange should be removed and wifi should just have events emitted on it.

Makes sense.

someone mentioned about positional parameters to connect and startAP - maybe the password/key should be in options instead

Is that one comment/change or two?

Posted at 2015-11-26 by tve

Quick questions:

• should it be the "wifi" library or the "Wifi" library?
• should IP addresses be represented as integers (which endian-ness) or strings or arrays?

Posted at 2015-11-26 by tve

I made the changes suggested by Gordon above. Same file (https://s3.amazonaws.com/s3.voneicken.com/espruino/functions.html)

The two short questions are still open and the answer will cause further small changes.

Gordon, would you mind making some small fixes to the pseudo-markdown so startAP and stopAP have decent bullet lists, or just tell me how to change the formatting so it works? (https://github.com/tve/Espruino/blob/master/libs/network/esp8266/jswrap_esp8266_network.c#L710-L733 and https://github.com/tve/Espruino/blob/master/libs/network/esp8266/jswrap_esp8266_network.c#L349-L365)

Update: ooops, I forgot about the async optional parameter...
Update2: now added

Posted at 2015-11-26 by @gfwilliams

Honestly, up to you. Or WiFi. I was wondering about that but I have no real preference, just not wIfI or wIFI :)

Does ESP8266 support IPv6 at all? Currently internally Espruino uses uint32_t for IP addresses (so that's what the utility functions that do conversions expect), but if there's any chance of IPv6 that needs to change.

In terms of JS-land, strings all the way I think.

Posted at 2015-11-26 by @gfwilliams

For the bullet points, I'm a bit lost. Actual code is here:

https://github.com/espruino/Espruino/blob/master/scripts/build_docs.py#L75-L87

So from what I can see if what you're doing, it should work if (like you seem to be doing) the line starts with * . Do you want to have a poke around? I can definitely stick it on my todo list, but I won't manage it tonight I'm afraid.

Posted at 2015-11-26 by tve

WRT IPv6, no, the esp8266 doesn't, but I believe WICED does. In any case, IPv6 should become really important with IoT stuff so I'd plan for it. But I was really referring to JS-land, so strings it is.

Since the Socket library has a capital S I'll change to Wifi. WiFi is just too awkward IMHO and I've never seen it used anywhere other than trademarks.

I'm not a python wiz (never written any real python code) so if you could spare half an hour to tinker I would very much appreciate!

(I updated the doc file)

Posted at 2015-11-27 by tve

I'm having second thoughts about Wifi.getStatus (file:///H:/src/esp8266/Espruino/functions.html#l_Wifi_getStatus). It's missing a number of fields, specifically, the AP's ssid, password, and authentication mode. I suspect there will be more down the road. That makes for a very long list of things to gather and return. I wonder how long it would take with the esp8266 AT firmware at 9600 baud... I propose to split the call into getStatus (station status) and getAPStatus. Other names are OK with me, but so far we have a similar scheme for getIP and getAPIP.

Posted at 2015-11-27 by @gfwilliams

It's a good point... Yes, I think that makes a lot of sense. After all, you're going to know what information you're interested in - and on other devices that don't do AP, those functions just get left out.

Posted at 2015-11-27 by tve

Moar stuff as I continue to go through code...

Errors and callbacks: in some cases there are "expected" errors, such as a bad password in a connect call. In those cases I think the best is to pass an err param to the callback which is null on success and an error string on failure. (This is what the current spec more or less has.) But there are also other errors, such as disabling the AP mode failing (not sure what would cause that, maybe if it wasn't enabled or the new default can't be saved to flash). In those cases I think it's best to raise an exception, just like we do if the user passes a callback argument that is not a function. Otherwise everything everywhere will have err returns and err arguments, and that just clutters stuff to be ignored in 99% of cases.

Currently connect/disconnect/startAP/stopAP take an option that specifies whether the change is to be saved as boot-up default. I'm finding that this leads to lots of if statements, is not cleanly implementable on the esp8266, and I'm not sure it's all that great to use. In particular, this option kind'a suck on the connect() call because you have to commit to saving the setting before knowing whether the connection actually works. So if the user specifies a bad password and the new config is saved no-one is happy.

I'm wondering whether a separate save call that saves "everything" to flash for the next boot-up would not be better. (I'd implement the saving in Espruino as opposed to relying on the SDK, I think.)

Posted at 2015-11-28 by tve

Q: how do I implement the "on" event callbacks? The difficulty I have is that Wifi is a library. In order to queue a callback, I believe I need to use:

jsiQueueObjectCallbacks(wifi, eventName, params, 1);

where wifi is the wifi library object. But I believe there is no such thing? Suggestions for implementing the events on a global singleton?

Posted at 2015-11-28 by Kolban

Assuming what you want to do is invoke a JavaScript function next time around the idle loop AND there is no "this" JavaScript context needed, then I think the solution would be to call:

jsiQueueEvents(NULL, jsCallbackFunction, params, count)

Where jsCallbackFunction is a reference to a JsVar that is a function reference.

Posted at 2015-11-28 by tve

Ugh, all this is turning into a ton of work... I split getStatus and revamped the auto-at-boot stuff into a simple save() function. Overall, things are a lot simpler both from an interface and an implementation point of view. However, I did add a lot more functionality to the whole library. I updated the html docs: http://s3.voneicken.com/espruino/functions.html#t_Wifi

Posted at 2015-11-29 by tve

Phew, a few more changes later I have it almost all implemented. Main features missing are the "on" event handlers (I need Gordon's help for how to do that) and the save() function. Everything now has a functional test, which isn't 100% but exercises all the functions.
I updated the docs.

Posted at 2015-11-30 by @gfwilliams

Thanks - yes, I'll have a think about this and will try and come up with an example...

Posted at 2015-11-30 by tve

Lemme, know, 'cause the "on" event handlers are the only piece missing at this point.

Posted at 2015-12-01 by @gfwilliams

Yeah, I'll look today. Ended up quite bust yesterday trying to catch up after the weekend.

Posted at 2015-12-01 by @gfwilliams

Ok, so you'll need to do:

include "jswrap_modules.h" // for jswrap_require

/*JSON{
    "type": "library",
    "class" : "foo"
}*/

static JsVar *getFooModule() {
  JsVar *moduleName = jsvNewFromString("foo");
  JsVar *m = jswrap_require(moduleName);
  jsvUnLock(moduleName);
  return m;
}

/*JSON{
    "type" : "staticmethod",
    "class" : "foo",
    "name" : "bar",
    "generate" : "jswrap_foo_bar"
}*/
void jswrap_foo_bar() {
  JsVar *module = getFooModule();
  if (!module) return; // out of memory?
  jsiQueueObjectCallbacks(module, "#onbob", NULL, 0);
  jsvUnLock(module);
}

and then this works:

>require("foo").on("bob",function() { print('Hello'); });
=undefined
>require("foo").bar()  
=undefined
Hello

It's a bit nasty. With the prototype chain branch I'm hoping to tidy it up so you'll be able to do:

/*JSON{
    "type" : "method", // <----- changed
    "class" : "foo",
    "name" : "bar",
    "generate" : "jswrap_foo_bar"
}*/
void jswrap_foo_bar(JsVar *module) {
  jsiQueueObjectCallbacks(module, "#onbob", NULL, 0);
}

But right now I think the safest method is above, and should be easy enough to tweak later on.

Posted at 2015-12-01 by tve

cool, thanks!

Posted at 2015-12-02 by tve

That worked well! Next issue... do you have a pattern somewhere for using timers in native code? When a wifi connection attempt fails I'd like to schedule a reconnection attempt a few seconds out. How do I do that?
(Background is that the SDK auto reconnects, but every second, and on battery that's a total killer. So I'd like to implement my own reconnection logic with exponential back-off.)

Posted at 2015-12-02 by @gfwilliams

I haven't personally done it, but something like this should work fine:

include "jswrap_interactive.h"

void doStuff() {
}

JsVar *func = jsvNewNativeFunction(doStuff, JSWAT_VOID);
jsvUnLock(jswrap_interface_setTimeout(func, 1000/*ms*/, 0));
jsvUnLock(func);

Posted at 2015-12-03 by tve

I just created a PR with the new Wifi library. Docs can be found at https://s3.voneicken.com/espruino/functions.html and a build at http://www.espruino.com/binaries/travis/7390e23a1e475a882edc9bbc20f0893947c7b925/espruino_1v83.tve_wifi_7390e23_esp8266.tgz

Dunno whether anyone is up for giving it a test spin. This does not change any of the socket code and I broke neopixelWrite due to too little static RAM. I'll figure out how to get it back in...

I have two open items in the Wifi library: doing retries in the library instead of SDK when no association can be established and adding static IP support.

Posted at 2015-12-03 by Ollie

@tve are there particular bits to test? I think I've been using the wifi object rather than the ESP8266WiFi object for a bit now. I can flash this build tonight and test my basic apps, but if there are new/specific bits of of the module to test, happy to try help.

Posted at 2015-12-03 by @MaBecker

@tve I can run some tests as well, any specific things or the whole wifi ?

Posted at 2015-12-03 by tve

The whole wifi library/class. Connect/disconnect/AP/callbacks all the getters, save()/reboot.

I tried to document everything, but I write terse docs, kind'a "minimal but complete info" strategy, so typically there is stuff that needs to be expanded on. So don't hesitate to flag that.

Posted at 2015-12-03 by tve

Gordon, currently when loading the new Wifi library the IDE prints out a warning "Wifi module not found". How do I teach the IDE that Wifi is a built-in module? Does that happen automatically once everything gets released?

Posted at 2015-12-03 by Ollie

Limited time to test so far. Only thing that jumped out tonight is that the "got_IP" event does not seem to fire - despite fact i can connect and use the "getIP" method.

Also of interest (to me) the "probe_recv" event seems to fire (repeatedly) despite not being connected as AP or as Station - maybe this is expected behaviour? Interesting to think that other devices, simply by being, in range can trigger this event (just thinking out loud).

Re the docs, it may be worth pointing out that all the callbacks receive an object literal as a single argument. People will try to access the vars direct otherwise and then wonder why they get an object and then undefined - I did :)

Tests done so far:

var wifi = require("Wifi");

wifi.scan(function(params){
  console.log("params:" + JSON.stringify(params)); // Tested OK
});

// Connect 
wifi.connect(SSID, {password: pwd}, function(){
  // Log IP address
  wifi.getIP(function(params){
    console.log("params:" + JSON.stringify(params)); // Tested OK
  });
  
  // Get Status
  wifi.getStatus(function(params){
    console.log("params:" + JSON.stringify(params)); // Tested OK
  });
  
  // Get Details
  wifi.getDetails(function(params){
    console.log("params:" + JSON.stringify(params)); // Tested OK
  });

  // Get IP address of host
  wifi.getHostByName("bbc.co.uk", function(params){
    console.log("params:" + JSON.stringify(params)); // Tested OK
  });
  
  // Wait 60 seconds
  setTimeout(function(){
    // Disconnnect
    wifi.disconnect(); // Tested OK
  }, 60000);

});

// Event tests
wifi.on("connected", function(){
  console.log("Event fired: connected"); // Tested OK
});

wifi.on("disconnected", function(){
  console.log("Event fired: disconnected"); // Tested OK
});

wifi.on("got_ip", function(params) {
  console.log("Event fired: got_ip");
  console.log("params:" + JSON.stringify(params)); // Does not fire
});

wifi.on('probe_recv', function(params) {
  console.log("Event fired: probe_recv");
  console.log("params:" + JSON.stringify(params)); // Tested OK
});

Posted at 2015-12-03 by tve

I may have incorrect docs, will look later. I replaced the "connected" event by, what i think is a more accurate "associated" event, and the "got_ip" by "connected". Part of the reason was that once someone adds static IP support the got_ip doesn't make much sense anymore, but getting "associated" and "connected" still does. So you can trigger off "connected" whether you have a static IP or a dynamic one.

WRT probe_recv, you probably have the AP on. When you flash blank.bin the default is to have the AP on, which makes sense going forward because it will allow for serial-less operation.

I'll fix the docs WRT callbacks.

Posted at 2015-12-03 by Ollie

Retested and "associated" and "connected" events work fine for me - I get the expected IP address on the latter.

Posted at 2015-12-04 by tve

You're right that the callbacks were described in the docs as having multiple parameters. I think I'm going to keep the single object param implementation and change the docs because that is more generic. It makes it easier to have a single event handler function for different events and it make is easier to add/remove info in other implementations without upsetting the entire function signature.

Posted at 2015-12-04 by tve

I updated the docs and hope that they now match implementation: s3.voneicken.com/espruino/functi­ons.html
Thanks for pointing out the issues!!

Posted at 2015-12-04 by Ollie

Some basic tests of the AP functionality. All fine for me.

var wifi = require("Wifi");

// Start AP
wifi.startAP("My_AP", {password:"testing1"}, function(){
    console.log("Access Point created"); // Tested OK
    setTimeout(function(){
      // Stop AP
      wifi.stopAP(function(){
        console.log("Access Point stopped"); // Tested OK
      });
    }, 60000);
});

// Events
wifi.on('sta_joined', function(params) {
  console.log("Event fired: sta_joined");
  console.log("Params:" + JSON.stringify(params)); // Tested OK
});

wifi.on('sta_left', function(params) {
  console.log("Event fired: sta_left");
  console.log("Params:" + JSON.stringify(params)); // Tested OK
});

I'm not sure I grasp the signifcance of the save() and restore() methods. Do these not overlap espruino save() and onInit() functions i.e the espruino program (which includes wifi configuration) must start at boot time for ESP8266 to do anything useful?

Posted at 2015-12-04 by @MaBecker

starting some tests, hit by this: cannot change the mode... stuck in mode = ap

>var Wifi = require("Wifi");
>Wifi.getStatus();
={
  "mode": "ap",
  "station": "off",
  "ap": "enabled",
  "phy": "11n",
  "powersave": "ps-poll",
  "savedMode": "off"
 }
>Wifi.setConfig({mode : "sta+ap"});
>Wifi.getStatus();
={
  "mode": "ap",
  "station": "off",
  "ap": "enabled",
  "phy": "11n",
  "powersave": "ps-poll",
  "savedMode": "off"
 }

mode is changing when changing phy and powersave like this ?!

>var Wifi = require("Wifi");
>Wifi.setConfig( {phy : "11g",powersave : "none"} );
>Wifi.getStatus();
={
  "mode": "sta+ap",
  "station": "off",
  "ap": "enabled",
  "phy": "11g",
  "powersave": "none",
  "savedMode": "off"
 }

Posted at 2015-12-04 by @MaBecker

got further, just connected and mode switches to "sta+ap"

this works fine

Wifi.getHostByName("bbc.co.uk", function(params){
:      fn="Wifi.getHostByName()";
:      console.log(fn+" params:" + JSON.stringify(params)); // Tested OK
:    });
=undefined
Wifi.getHostByName() params:"212.58.244.22"

and this dumps

> Wifi.getHostByName("bbc.co.ukk", function(params){
:      fn="Wifi.getHostByName()";
:      console.log(fn+" params:" + JSON.stringify(params)); // Tested ERR
:    });
=undefined
>
 ets Jan  8 2013,rst cause:1, boot mode:(3,7)
load 0x40100000, len 1396, room 16
tail 4
chksum 0x89
load 0x3ffe8000, len 776, room 4
tail 4
chksum 0xe8
load 0x3ffe8308, len 540, room 4
tail 8
chksum 0xc0
csum 0xc0
2nd boot version : 1.4(b1)
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000

Posted at 2015-12-04 by @MaBecker

results of tests

// tested //
// ok Wifi.connect(ssid, options, callback)
// ok Wifi.disconnect(callback)
// ok Wifi.getAPDetails(callback)
// ok Wifi.getAPIP(callback)
// ok Wifi.getDetails(callback)
// ok Wifi.getDHCPHostname(callback)
// ok Wifi.getHostByName(hostname, callback)
// ok Wifi.getIP(callback)
// ok Wifi.getStatus(callback)
// ok Wifi.scan(callback)
// ok Wifi.setConfig(settings)
// er Wifi.setDHCPHostname(hostname) if hostname is unknown
// ok Wifi.startAP(ssid, options, callback)
// ok Wifi.stopAP(callback)
// ok event Wifi.auth_change(details)
// ok event Wifi.associated(details)
// ok event Wifi.connected(details)
// ok event Wifi.disconnected(details)
// ok event Wifi.sta_joined(details)
// ok event Wifi.sta_left(details)
// ok event Wifi.probe_recv(details)

// open //
// Wifi.restore()
// Wifi.save(what)
// event Wifi.dhcp_timeout() ? what fires that one ?

Posted at 2015-12-05 by tve

Wifi.setConfig({mode : "sta+ap"});

setConfig does not take a "mode" param, and the docs are correct. But I can see how this is confusing to an esp8266 coder. the "opmode" is only changed indirectly by connect/scan/disconnect/startAP/stopAP.

mode is changing when changing phy and powersave like this ?!

Mhh, I'll have to look into this and see whether I can repro.
Update: I cannot repro. Can you help me understand how you get there?

and this dumps

Ooops, not good. Looks like a WDT reset, so something must take too long... I'll have to try and repro...
Update: repro is easy, bad DBG printout, and clearly a gap in the test coverage...

Thanks much for testing!!!

Posted at 2015-12-05 by tve

I'm not sure I grasp the signifcance of the save() and restore() methods. Do these not overlap espruino save() and onInit() functions i.e the espruino program (which includes wifi configuration) must start at boot time for ESP8266 to do anything useful?

The Wifi.save() method saves the Wifi config independent of any JS program that may or may not be loaded. I think you should move away from configuring the wifi in each program and instead configure it on each module once. This will become more useful when the IDE connects via wifi, at that point it's nice to have a stable connection whether you have a program loaded that works or not. Also, I want to add a "failsafe" mode to the Wifi that makes it turn on AP mode if it hasn't made a STA connection a minute after power-up. This way when you take your module to a different location it doesn't become unreachable.

Posted at 2015-12-05 by @MaBecker

@tve I like the idea : start "ap" when "sta" fails by default !

ignore this, cannot produce anymore

mode is changing when changing phy and powersave like this ?!

what about

// event Wifi.dhcp_timeout() ? what fires that one ?

try to test save("clear") and restore()

Wifi.save("clear");
resert();
........
var Wifi = require("Wifi");
Wifi.restore();
Wifi.getStatus();
={
  "mode": "off",
  "station": "off",
  "ap": "disabled",
  "phy": "11g",
  "powersave": "none",
  "savedMode": "off"
 }
Wifi.getDetails();
={
  "status": "off",
  "ssid": "mySSID",
  "password": "myPassword",
  "savedSsid": null }
>Wifi.getAPDetails();
={
  "status": "disabled",
  "authMode": "wpa2",
  "hidden": false, "maxConn": 4,
  "ssid": "ESP001",
  "password": "esp00001",
  "savedSsid": null }
> 

so it clears the overall wifi configuration and keeps station and access point configuration.
Is that what you implemented for "clear" ?

Posted at 2015-12-05 by tve

Mhh, I think this is one thing I didn't test very well either. Doesn't lend itself to automated testing. Lemme look more tomorrow and make sure the docs state what it does.

Posted at 2015-12-05 by tve

FYI, I fixed all issues brought up above (except save()/restore()) except for the "ERROR: Not connected to the internet", which came up in gitter, where I know what the problem is but not how to fix it. I'll make a new build as soon as I find out from Gordon what to do.

Posted at 2015-12-07 by tve

New build ready: https://s3.voneicken.com/espruino/espruino_1v83.tve_fix-sockets_e62bff7_esp8266.tgz
Docs: http://s3.voneicken.com/espruino/functions.html#t_Wifi
Fixes all open Wifi library issues, except that getStatus() always reports savedMode: "off".
This build attempts to fix sockets issues around closing&errors and now allows DNS names in connect call. I have only done minimal testing of the sockets stuff, so I'm sure there are issues there. I do not expect that this build is ready for prime time yet, but we are getting into the home stretch, I believe!

Posted at 2015-12-07 by @gfwilliams

How do I teach the IDE that Wifi is a built-in module?

It'll 'just happen' next time I update the website with a new release (it gets listed in the json/ESP8266_BOARD.json file on espruino.com).

wrt callback parameters: It's a pretty standard JS/NodeJS thing to have:

function (err, data) {
  if (err) {
    console.log("Oh no!");
    return;
  }
  // ...
}

It's not pretty, but it's what everyone does. It'd be nice to be able to keep that kind of thing wherever possible.

Posted at 2015-12-07 by tve

Did you have specific functions in mind WRT the error callback parameter?

Posted at 2015-12-08 by tve

Yet another new build: http://s3.voneicken.com/espruino/espruino_1v84.tve_master_e56e06c_esp8266.tgz
Docs unchanged: http://s3.voneicken.com/espruino/functions.html#t_Wifi

This build improves socket error handling and adds flow control so large amounts of incoming data don't cause out of memory errors.
The issue with Wifi.getStatus() always reporting savedMode: "off" is not yet fixed.
Due to an Espressif SDK memory corruption bug I spent more time tracking down that bug and less testing the new build :-(.

Posted at 2015-12-08 by @gfwilliams

I guess things like getAPIP, getIP, getHostByName.

So they could all return null/undefined on error - maybe that's good enough? But if you want to return an error message then there really needs to be another way of doing it - and the way most NodeJS things do it (for better or worse) is function(err, data)