-
Perfect, thanks @Gordon... it looks like it'll do what I want as long as I'm careful. I had an inkling it'd have something to do with Loopback!
-
I've been running an ESP8266 on a Pico to control a servo (venetian blind tilt), using HTTP. However, I'm switching to a TCP socket instead to control via
nc
, so that I can do immediate variable control from a remote rotary encoder rather than the slow open-request-response-close HTTP method.That seems to be working, but I was wondering if it was possible to effectively do
socket.setConsole();
I know it's not that straightforward, as it would be if it were acting as a serial port, but is there some way of passing incoming data fromsocket.on('data', function () { /* pass to console */ })
? It'd be nice to just sendservo.set(...)
commands vianc
rather than making up a new protocol.Incidentally, I was having trouble running the HTTP server and the TCP socket server running at the same time, even though from what I can see
AT+CIPMUX=1
is set. Code:var ESP8266 = require("ESP8266WiFi_0v25"); var Net = require('net'); var HTTP = require('http'); // ... wifi.connect(..., ..., function (err) { // ... http = HTTP.createServer(onRequest); http.listen(80); ssock = Net.createServer(onConnect); ssock.listen(3000); });
Error is:
>Uncaught Error: CIPSERVER failed (no change) at line 2 col 20 (a?a:"Timeout")+")");}
If either the
http
pair or thessock
pair are commented, no problem. Before I spend too much time fiddling, has anyone managed to do two separate servers at the same time, or is this a known limitation?Thanks, as ever :)
-
I've updated all of them successfully now via the Raspberry Pi. The first one was a KS module using the shim included with the KS five-pack, but still needed to be via Raspbian rather than Mac. The next three were from Amazon, done using the veroboard jig. This one I just successfully tested on the Mac (albeit just
read_mac
rather thanwrite_flash
) was already upgraded to 0.25.0.0 using the jig on Raspbian.So, basically no useful information there at all :) However, if someone is having trouble using
esptool
on Mac, it might be worth trying a Pi or similar.Oh, one thing I forgot to mention... I didn't have any luck flashing it on Mac using an FTDI232 USB/TTL board instead of the Pico either.
EDIT: Ah, just noticed that the ESP8266 (actually ESP-01) modules didn't come with the KS Picos after all. I got the five-pack, Dad got another reward, and gave me one of his shims and an ESP8266. I hadn't realised he'd bought the ESP8266s elsewhere. So, basically even less useful information to deduce a pattern! I'll shut up now.
-
-
I've given my best mate a spare Espruino Pico to play with. He's a FreeBSD user.
Anyway, apparently, in the Web IDE the popup to select serial port is just stuck there saying "Loading..." (or similar; not sure) and not displaying a list of choices. I tried doing the symlink trick of
cd /dev; sudo ln -s ttyU0 ttyACM0
just in case it was a pattern recognition thing, but no luck.Connecting via
screen /dev/ttyU0 9600
works to some extent, but the most recent character is not echoed; if you were to typehello
,hell
would appear. If you then typed!
, theo
would appear, but not the!
.I expect this is more to do with issues with FreeBSD's serial driver, the version of
screen
installed, and Chrome's serial code, than it is to do with Espruino per se, but on the off-chance that someone's used FreeBSD with the standard Espruino setup, I thought I'd ask on his behalf before we investigate much further. -
I was just about to put it all away in the loft when I got this message notification. Lucky!
I'm fairly sure it was a
Exception: Failed to connect
error, and this was definitely on 1v80 with tweakedesptool
. The script's on an NFS mount shared with both Mac and Pi, so I'm sure both the espruinojs
and the tweakedesptool
were the same.Of course, typically now I try a
read_mac
call and it works just fine! That was with one of the ESP8266 you supplied with the Kickstarter, whereas the ones I were programming are visually identical but from Amazon. -
For what it's worth, I failed to get
esptool
on OS X to connect via the Espruino proxy; OS X is my main programming platform so I do know it quite well. I ended up connecting the Espruino to a Raspberry Pi and did it from there: much easier.Getting the shimmed ESP8266 from the Pico Kickstarter flashed was a bit of a chore, but after some tweaking, I managed it.
Getting three more ESPs I bought from Amazon was another matter: it turned out two of them had dud firmware anyway, so getting a version string was impossible; however, they did go into Flash mode automatically, so once I realised that, I managed to flash them. The third had 0.21.0.0 on it and required some baud rate tweaking before I could flash that.
I also had quite a bit of trouble with the reset line floating and so forth, so used a pull-up 10K, and ended up building a jig on veroboard. Finally, shortening the wires between Espruino and the ESP8266 helped, I think... by that time I was trying just about anything.
-
-
I found a 0.1µF ceramic and put it in place, but it didn't help. I also tried a 1µF.. no luck. However, I did notice something interesting...
Uncaught SyntaxError: Got ?[219] expected EOF at line 1 col 13 {var a=this;Ûf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[224] expected EOF at line 1 col 13 {var a=this;àf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[229] expected EOF at line 1 col 13 {var a=this;åf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[234] expected EOF at line 1 col 13 {var a=this;êf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[239] expected EOF at line 1 col 13 {var a=this;ïf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[244] expected EOF at line 1 col 13 {var a=this;ôf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[249] expected EOF at line 1 col 13 {var a=this;ùf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[254] expected EOF at line 1 col 13 {var a=this;þf(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^ Uncaught SyntaxError: Got ?[3] expected EOF at line 1 col 13 {var a=this;g(a._tto)return console.log("HTU21D COLLISION")... ^ in function "getTemperature" called from line 2 col 60 ...re(function (x) { T2 = x; }); ^
Notice that the bad character code is increasing by 5 on each error. Once it reaches 255, it loops around and increments the next character (f to g) and carries on. Weird. This is with stock 1v70.
-
I haven't found an appropriate capacitor for the NRF24 yet, but since disconnecting it and commenting out the init code two days ago, errors have ceased. Now, that might mean that the NRF24 noise hypothesis is correct, but it could be down to a few other reasons too, involving hardware and/or software. I'll update when I manage to sort out the capacitor thing.
-
-
Yeah, the errors are different each time and they don't happen on every hit. This script runs on a 1 second setInterval. It's difficult to qualitatively judge the frequency of the errors because it's uneven, but it fails more often than not. Sometimes it's enough to stop the script running altogether, requiring a RST.
This is on one of the original Kickstarter boards. I haven't noticed it getting warm, but I'll keep an eye on that though.
I've been running this from an external USB power supply primarily (Anker 40W 5-port) powered from a UPS (just because it's there). Right now, however, it's running from a powered hub (D-Link) so I can keep an eye on what the console's saying.
I'll hunt down a capacitor for the NRF24, but in the meantime I've set it to run without the NRF24 to see if it still happens.
Thanks @Gordon!
-
Hey,
I've been running an indoor temperature/humidity/pressure sensor for a month or so, logging to an SD card and also sending via NRF24 to a Raspberry Pi for logging in a database.
Recently, it's started glitching, with errors like:
Uncaught Error: Function "gunction" not found! at line 1 col 73 ...21D COLLISION"),setTimeout(gunction(){b-null)},0),a._tto=!1,... Uncaught Error: Function "kunction" not found! at line 1 col 73 ...21D COLLISION")-setTimeout(kunction(){b-null)},0),a._tto=!1,... Uncaught Error: Function "console3log" not found! at line 1 col 30 {var a=this;if(a._tto)reuurn console3log("HTU21D COLLISION")...
with single character "typoes" appearing, disappearing, changing.
It started off absolutely fine for a few weeks, and then an occasional failure every few days (requiring a simple reboot with the RST button), but now it starts glitching as soon as it's connected. This is while running from a PC, but also while running off a known-good power supply, or even a LiPo.
Is it possible that the Espruino's flash is wearing out, or is something else going on?
-
IIRC, the BLE exploit is to do with a particularly weak pairing procedure: if paired in a secure environment -- you do all have a Faraday cage at home, right? -- I assume it's moderately secure... 128-bit AES, I think.
Security on BLE is designed so the host (a.k.a. client, ie. the smartphone) does the vast majority of the work, and the peripheral (a.k.a. server, ie. the widget) just has to do very basic symmetric ciphering. This is to reduce power consumption, offloading all CPU work to the (presumably) more powerful host.
Saying that, I would agree with Gordon's assessment in terms of risk. Most BLE usage seems to be predominantly read-only with most of the security features ignored. Saying that, many do have a DFU mode for OTA updates, and there's little to stop NSA/GCHQ/[A-Z56]{3,} using that to surreptitiously turn your fitness band into a rudimentary espionage device.
Anyway, I apologise for taking this thread so far off-topic!
-
Agreed, but I'd still prefer having to get a modern Mac, iPhone, developer subscription and programming a little Javascript than having to get a modern Mac, iPhone, developer subscription, Nordic Eval Kit, a copy of Windows to be able to run Keil OR lose a good deal of hair trying to get GCC configured, and then have to spend tonnes of time trying to decipher the nrf51 SDK.
Unusually in this case, writing the phone app is probably one of the easier and better-documented parts of the process!
-
Different thing altogether... for the kind of thing I'd be using BLE on Espruino for, I wouldn't want "proper" Wifi anyway. The desire for BLE is about having a lightweight connection from a smartphone or tablet to control and query one or more Espruinos. Classic Bluetooth would do the trick, but would drink far too much. The ultra-low-power nature of BLE coupled with Espruino's economical usage through an event-driven model would be a perfect match.
It's a pity BLE included the word "Bluetooth", as it's just not the same thing at all. Rather than internet, serial and all the other things, BLE is mainly used (and apparently intended) for the typical sensor and accessory role, such as heart rate monitors and so forth. Trying to get it to establish a serial connection or any kind of constant stream (eg. audio) is just counter to the design. Additionally, controlling something like an HM-10 via serial and AT commands is a bit nutty, IMHO... it'd almost be more suitable to do it over I2C than serial.
Gordon's right that the app development side is required to use it properly, though: most projects seem to offer this with a fairly weak sample app for iOS and Android. It's a shame because BLE has all the elements to be really great, but the sample code and tools on both sides of the connection are just a bit lame. It'd be very interesting to see a Javascript remote procedure call mechanism from smartphone to Espruino across BLE like the NRF24 implementation.
-
Yeah, I thought perforation might be a step too far. However, if there was a clear line then the instruction could be to cut the tracks with a scalpel first (probably slightly back from the line) and then use whatever means necessary (Dremel; Hacksaw; persevering with a Stanley knife) to separate the board itself.
As far as the micro- is concerned, if refactored as though-hole (or easily surface-mountable) the carrier board could be in kit form, as you say, or a hand-assembled board offered at a higher tier pledge. Other boards could be offered as downloadable designs, one-off orders, or small runs based purely on demand and cost... perhaps even as separate mini-Kickstarters themselves.
If you could get the business aspect just right and find a few good customers, bulk sales of the core module for integration might subsidise the hobbyist and developer boards. I've seen a few successful Kickstarters for IoT modules designed for production use (eg. RFduino, MetaWear... admittedly both BLE + ARM), and none of them are anywhere close to being as easy to develop as Espruino.
For that matter, if anyone produces an ARM package specced to run Espruino well enough and integrate BLE into the package itself, I reckon it'd be worth dropping everything and getting a Kickstarter out there ASAP. The barrier to entry for BLE for unfunded startups (eg. wearables) is too high at the moment: complicated dev tools and environment, bad example code and documentation, and so forth. Javascript would be a perfect host for an integrated (ie. not serial-driven) BLE component.
Anyway, I digress. :)
-
Whoa. Just saw this thread. Please take my money as soon as humanly possible.
With regards to the dilemma of extra pins, could a possible compromise be to have them on some sort of breakaway section? I'm not a hardware guy, but could the board be perforated or at least have some sort of safe cutting line over which the traces are just straight lines? I was wondering about doing the same for the USB connector. That way, the board could be programmed and developed full size and then snapped down to minimal size for use in production.
This brings up another related thought... what about constructing a "micro"-Espruino module with no buttons, connectors, etc. and 0.05" pads, of similar size and form to the HC-05.
It would be mounted on a breakout board with all the pins and connectors for development (and for hobbyist use), but could be used on its own in production. I could imagine that would improve the practicality of Espruino hardware beyond simple one-off use. I could also see both the mini- and normal boards being refactored as simple breakout boards for the micro-.I know it's not what you're planning with this new release, but I for one would be very interested in, say, four micro-Espruino modules and a single Development Kit (ie. the breakout board).
(It goes without saying that I'll also pledge for the mini- on Kickstarter as planned ;) )
-
Hi Alex,
I think that's just in relation to Bluetooth Classic, isn't it?
For BLE operation, I think the HM-10 only offers a single preset service and characteristic, along with preset support for internal temperature and possibly battery. I spent a few hours going through that datasheet and having a go, but other than rudimentary read and write of the single characteristic, I couldn't build anything more complicated (such as a set of multi-value characteristics within a single service, each with their own authorisation thingies)
I'm not surprised, to be honest, as the actual API for doing BLE on either the Nordic or TI chips is complex... I can't see how it would be sensibly mapped to a simplistic serial profile like the AT command set.
Tom
-
Hi Alex,
Well, both HM-10 (and RFduino, incidentally) seem to be well set-up to do iBeacon functionality. However, if you actually want to use BLE for something more useful (such as a sensor, like a heart rate monitor, temperature reporting, etc.) then you need to be able to construct services, characteristics, and so forth.
I can't see any documented way of doing this with HM-10, at least consistently. The furthest the datasheet goes is about major and minor numbers, which are part of the iBeacon functionality.
...unless I'm missing something.
Put simply, with an HM-10, how would you configure it to advertise a sensor service and equip a smartphone app to connect and collect that sensor data? I can't see any way to do that with the HM-10, and it seems to be the primary use-case for BLE (not, as many think, the iBeacon capability)
Any insights you have would be appreciated.
(I'm still knee-deep in the NRF51822 SDK, which is a major chore: rather than being undocumented and possibly impossible like the HM-10, it's definitely possible, but even a basic sensor app is hundreds of lines of code for all the advertising, asynchronous connection/disconnection handling, service delivery, etc.)
Tom
-
It might just be that I'm missing something. I've got about five HM-10's still in their bags for the same reason.
If you do manage to get the HM-10 doing more than basic iBeacon-type advertising, please do write it up. I'm sure it's possible to get it acting somewhat like an HC-05 as far as the serial port's concerned, but I didn't have much luck there either.
I was specifically wanting proper service/characteristic BLE functionality (for constructing, say, a heart-rate monitor), which neither the HM-10 or the RFduino seem to do very well. The 51822 is far more capable, but it's a much bigger job as you're writing a proper application with no Arduino/Espruino-like abstractions.
Getting the NRF51822 to run Espruino code directly is well outside my capabilities, to be honest. Instead, I'm looking at using the 51822 as a peripheral for just doing the BLE work, while the Espruino board does the proper intelligent stuff.
-
@Alex: yeah, slight digression, but I've considered putting an NRF51822 on an Espruino too.
Thing is, the HM-10 Bluetooth Low Energy thing is a pig to deal with: it's all through undocumented (or rapidly shifting documents, at best) AT commands and can't do custom characteristics worth a damn. So, basically it's an iBeacon, and that's about it.
On the other hand, the NRF51822 is a lovely little chip, but needs to be programmed in C. Even a fairly simple thing is a chore to do. It also has I/O limitations that aren't surprising considering the size/cost.
So, I was thinking of using the Espruino as the master, and an NRF51822 flashed with a fairly simple program so it can act as a more-capable BLE dongle.
The project I'm toying with right now requires a board with a much smaller footprint than the Espruino, but I'd far prefer to be uploading .js files rather than .hex.
-
Hey,
I'm using the HID Keyboard example - https://www.espruino.com/Puck.js+Keyboard plus simple LED on/off with button press/release - to try to send a single keypress to an iPad.
While it sometimes works, once it's cut off it does nothing: the LED still lights when pressed so the code's still working, but there's no effect on the iPad. The Puck is still paired and connected with the iPad.
Now, I've noticed https://github.com/espruino/Espruino/issues/1101 and some other ideas, but what's really tricky is the limitation that the Puck must be disconnected from the IDE to pair it with the iPad: only one connection at a time. It means I have no error messages visible to debug the problem.
My NoName™ FT232 USB-to-serial board is not working for some reason - probably lack of flow control - and the wiring is unwieldy, so I was thinking the other Puck I got from Kickstarter might be an easy way to do it. Failing that, I might rope a spare Pico in to act as a dumb serial converter.
So, I guess my question is, what's a straightforward way to cross-connect the serials of one Puck with another Puck, so the IDE (or at least the command-line errors) can be viewed while still connected as a HID device? Or, any other approaches to try?
Thanks,
Tom