-
-
Check out the Flash EEPROM module here https://www.espruino.com/FlashEEPROM
-
Yes. On the Wifi NodeM there's a tiny hole in antenna which is embedded in the PCB. I don't know whether I grounded it, or powered it, but one of the two massively improved the reception. Without that, a scan of APs returned 1, or 2 at best, when a NodeMCU would return all in range.
Odd though, you say Micropython Wifi runs fine on yours, and others seem to have also had success with the Wifi-NodeM running Arduino, so maybe there is an Espruino related quirk on the Robodyn boards.
-
I had their Wifi-NodeM board. It detected virtually no Access Points. I concluded the radio was very poor, maybe since it was embedded in the board on the Wifi-NodeM.
There was an odd trick that got it to work - which I don't fully remember but - it involved shorting a a pin to the hole in the antenna. Do that and reception good.
This workaround, worked very well, but I felt the chips got very hot. Again, because the chipset is uncovered I couldn't tell you if this is hotter than a nodeMCU board would run.
Tried to return and get money back, which seller agreed to, but postage terms and costs made it infeasible.
-
So firstly - the terminal keeps throwing back "undefined" when entering perfectly valid Javascript
Are you certain? The code you specified should echo 1 on the console.
the manual refers to the default speed being 9600. Well, either I'm going blind or mine is defaulting to 115k.
115200 baud rate. Probably info refers to AT commands to ESP8266-12*.
Thirdly the first examples you see relate to LED1 - but mine knows nothing about LED1.
No onboard LEDs that you are intended to control on ESP8266-12*. You can control the Wifi light. Pin varies from board to board. D2 from memory on the NodeMCU, which uses ESP8266-12E
Also - this - in the docs - is unrecognised. ESP8266.getFreeFlash()
You need to require the module.
var esp = require("ESP8266"); esp.getFreeFlash(); // returns the info you wanted
-
-
-
Thanks for that. I thought it was a big ask.
It's not exactly as I had hoped, but the good news is your board looks fine. Next step is to get yourself on a network.
Something like this, but checkout the documentation for all the detail
wifi.connect(ssid, {password:pw}, function(err){ if (!err) {console.log("Connected");} });
-
This is most odd. We should use the Web IDE though - we have a good starting point for debugging and a common understanding of the interface.
Please can you post the output/screen grabs of these actions.
1) Immediately after you connect via the Web IDE.
2) After you typereset()
in console on left hand side of IDE, and hit return
3) After you typesave()
in the console, and have hit return
4) After you key thevar wifi= require("Wifi")
and hit return
5) After you key thewifi.getStatus()
and hit return -
Where is that function call to
main()
coming from? Do you have code saved that is loaded at boot?You should get this, or similar, this is the output of a connection with screen:
| __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v91.122 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate Flash map 4MB:512/512, manuf 0xef chip 0x4016 >var wifi=require("Wifi") =function () { [native code] } >wifi.getStatus() ={ "mode": "sta", "station": "connected", "ap": "disabled", "phy": "11n", "powersave": "ps-poll", "savedMode": "off" }
In the terminal try issue a
reset()
first, this will clear saved code, then issue asave()
then try again. -
@oesterle has suggested 3 things I'd like to 'plus 1'
1) Fun program onboard when you receive it - might defer "my puck is not working" type support
2) Yes, my thoughts too. It's clearly 3 LEDs - the light doesn't diffuse well.
4) The battery insulator tab. I've raised this too. Clear or not, add a bit more on it - so it can be pulled out using fingers, not pincers.A couple of other minor annoyances
The fingernail lift on battery trick is fantastic to reset - once you know about it. Access to battery could be easier - or a reset button.
Top cover material. It's hard to keep clean. I'm not sure if this is static or what, but it attracts dust. No big deal, but are there other options, that might not?
-
When you wrote this
http.createServer(pageHandler).listen(8080);
You're setting up the server to listen on port 8080 i.e
http://ip address :8080
. It is distinct from port 80. 80 is the default for http - so the only one you don't have to explicitly call in the URI if your server is listening on port 80. Similarly 443 is the default for a server offering SSL/TLS via HTTPSYou need to contact the server using the port it is listening on - if that is port 80 you can omit it.
Beyond that you need to have a response handler - your
pageHandler
function that can output the correct response that a browser can use/understand. The Espruino page on Internet has numerous examples that will help you write the handler function.Edit:
Re Telnet. Once you have Wifi setup and you are connected. If you know the IP address of your board, and set that up on the communications page asx.x.x.x:23
, you should be able to establish a Telnet connection - unless the build of Espruino you are using has had Telnet option turned off. Standard builds should have Telnet enabled. -
-
Your average person can't build C binaries and benefits enormously from being able to run interpreted languages where they have prior experience, or which are easy to pick up from scratch if they don't. Otherwise the ESP8266/32 boards are useless to them and they're not able to join in the fun.
ESP8266/ESP32 are capable micro controllers which, given their price, are difficult to complete with. That battle might not be worth fighting.
So, looking at software side, strategically, I think you're in the middle of a land-grab. In the long term, is it better that Espruino is the goto solution for coding on ESP8266/32, or that one of the alternatives like MicroPython, Lua or, ESP8266 Basic, has become it?
One could see more opportunity to earn revenue from initiatives like paid support or premium access channels in the above scenario, than if Espruino was used only by folk who bought an official Espruino board, while the ESP crowd ran something else.
Of course, many won't subscribe, and will get more value than they give - as is the case now - but with scale/volume it doesn't matter as much, or feel quite as personal :)
I don't think you even need to understand how to monetise in the short term (providing you can support yourself) if you get the distribution and Espruino becomes a/the standard, these things should fall into place.
If nobody is using Espruino, but the owners of official boards, you don't have quite the same opportunity, if any.
-
but I'd be earning a lot more and working less if I got a normal job.
My wife has often said "why can't you just get a normal job?"
For me, running a business is a "random walk" - the trick seems to be to keep at it. This random walk can meander upwards with care and/or effort.
Couple of ideas:
1) Paid support for non-espruino boards - ESP8266/32 in particular. Proliferation will lead to more support calls, so monetise it?
2) Actively engage with, and market to, ESP8266/32 users. It's going that way, the stats suggest it. Your main product is software. So feed the proliferation required for 1) above?
-
-
Someone was attempting it on here. The approach seemed to be to run the ESP8266 as an Access Point and Station (the default).
In AP mode the IP address is a known
192.168.4.1
.A simple webserver hosts a form to accept SSID and password credentials, which can be used as an input to connect to the main Wifi network as a station, if I can find the thread I'll update here.
Edit: Nothing jumps out in the forum, it might have been a discussion on gitter. But that was the approach taken
-
-
-
-
See edit at foot of this post... not sure if this is a bug but same in 1.87 when I replicate the process.
There is a regression in that build, a memory leak, maybe Wifi or socket related? I don't know at what point it may have been introduced, since I'm on 1.87, but there's a steady reduction in
process.memory().free
when I review. Reverting to 1.87 and stable again.The sample code I tried.
var wifi = require("Wifi"); var mqtt = require("https://github.com/olliephillips/tinyMQTT/blob/master/tinyMQTT.min.js").create("iot.eclipse.org"); var topic = "/op/test"; var message = 0; mqtt.on("connected", function(){ setInterval('mqtt.publish(topic, "test" + message);', 2000); }); mqtt.on("published", function(){ console.log("message sent"); }); mqtt.on("disconnected", function(){ console.log("disconnected"); mqtt.connect(); }); wifi.connect("SSID", {"password":"password"}, function(err){ if(!err){ console.log("Connected"); mqtt.connect(); } else { console.log(err); } });
Edit: Actually, you only get this on saving code, and in 1.87 too. Upload the code, let it start running,
save()
in the console on left, and then free starts to decline. Maybe this is not an issue since I only did this for the purpose of the test above.Normally, code will be wrapped by
E.on("init", ...)
at upload beforesave()
.Am interested to know what could be happening here though
-
I've flashed @MaBe link 1v91.122 and can send code and save. I was going to suggest try a smaller file to you, since my code is small enough not to need the command history deleting but looks like you have tried that.
Hi I can't replicate this. I have 34 APs available in my location. Following a
reset()
andwifi.scan()
,process.memory().free
reports 1649 jsvars.Maybe the issue is what you are doing with the data post-scan? Can you provide more info on what your code is doing?