Search results for:

Last one, 'espruino', for me. Longest of them but semantic and your namespace so won't conflict.

@HyGy I've just confirmed on gitter that using IP address in place of hostname allows me to send data to Sparkfun using http.get(...). With hostname I was getting the out of memory issue after about 7 requests similar to what you have been seeing. @kolban gave me the heads up on that last night.

https://data.sparkfun.com/streams/6JxNaX7o06S0RxJgvRdD

Will bet that is your issue? Maybe try divorce your code from the temperature polling as that would appear to be a separate issue - maybe the probe you have? (I was able read temp using the DS18B20 module and a DS18B20 probe on ESP8266 just fine - also posted about that on gitter)

Espruino Gitter room here

https://gitter.im/espruino/Espruino

How do I know when I can remove this line from the code?

That's one for @kolban I don't know - though I don't imagine leaving the code in will do any harm even when the default is set to false.

Re your readings I got good readings on the ESP8266-1. Maybe try another temperature probe - I note you say DS18S20? I used the DS18B20. One thing I found useful was to mirror or replicate the setup on a Pico - especially since the DS18B20 wire colour coding seems to vary! Once I sussed the wiring on a Pico, I then knew what to expect on the ESP8266.

I had Onewire working fine on ESP8266 last week though I needed to add

require("ESP8266").logDebug(false);

before my code. I believe this is only while the ESP8266 port is in development, when complete this will be set off by default.

Well the Paypal fees hurt a bit - especially if you're receiving a significant amount - not referring to donations here, something else. No experience with Patreon, doesn't look very "enterprisey". Another alternative might be a do via a direct debit bureau? Gives you plenty of control should license or support contract terms need to be varied and pricing altered.

One other thought - what about commercialising ease of access/programming - a cloud based web ide - much as you have now. Your teachers will use that - just because it's plug and play and requires no set up - if you can get it to that point - think Office 365 style?

But more than that use-case, it would also allow options to restrict/open-up functionality based on the type of subscription to the online IDE.

For example:-
Free - no code minification, maybe limit access to modules to those a hobbyist might need.
Enterprise - minification, all the modules, paid for modules, maybe pre-built code solutions.

You could go further too. Perhaps allow third party developed modules and code solutions in a "marketplace" section of the IDE that could just be purchased and loaded up by anyone. Espruino takes a % of the third party developer' sales.

An online IDE could be a hub that ties the whole Espruino ecosystem together.

Bit blue sky, and certainly for the long-term, but there are plenty of ways to take the skin off a cat!

Blimey no, I wasn't suggesting you ask for a beer @Gordon! Just that you try quantify what might constitute a donation if you decide to put the button back! I think it makes it easier for people.

Re corporate, well that's a different matter - FWIW there are a lot of corporates using my script (some that are direct competitors to me) that have never donated a bean! But this is open source, where we hope the benefits of altruism outweigh the bad bits. But you can't depend on donations there.

So for corporate then:-

1. Commercial licensing
   
2. Paid support contracts
   
3. Enterprise versions
   
   

Re 3. they seem to come in two flavours - with private features that the open source community never see, or as seems to be a trend, Enterprise gets your latest version - you stay totally open source but retard the open source free version - so for Espruino "free" might be 1.75 while Enterprise "paid for" is able to access v1.81

and that shows - when you get a proper board, plug it in, and things just work.

The plug and play "ronseal" aspect of the Pico and original Espruino board is a massive plus - I guess its the price point of the cheaper boards such as the ESP8266 that attract. Your commercials are your own business but what you seem to be up against is cheap and increasingly powerful microcontrollers :/

Wonder if the MQTT module was stripped back so that it could run inline with the rest of the code rather than be loaded via require(...) if compilation might help?

http://www.espruino.com/Compilation

Shot in the dark from me but @Gordon will be able to confirm/refute. Is compilation just a speed thing or are there memory saving advantages to be had that might help here?

Back in 2011 I wrote one of the first cookies disclosure scripts. That has a "buy me a beer" button. It works reasonably well, I think partly because it sort of quantifies the amount you hope for as a donation. I don't get lots of donations these days - it's old hat and there are better solutions - but when I do I get just enough to cover a beer - maybe two. I think without that people would wonder how much to donate and would worry about it being too little/insulting. And we all know that where there's a decision to be made doing nothing is often easier!

Btw, coerced also my ESP8266-01 to be breadboard friendly.

Like that!!

Got it, thanks!

@Gordon that new module looks really good - nicely abstracted - much easier to use.

I've been following this thread as I didn't know about the compiled statement and have been trying to optimise some 433Mhz code I've been working on - when you say does not work in the Web IDE, do you mean the Chrome IDE? Though I could still could not get my code to run properly, Espruino did appear to be responding in the terminal as if it was the compiler was working, and threw errors if I tried to use "compiled" in ways it said had not been implemented? I assumed it was doing its stuff just fine?

Yes, it's available for 10.6.8 upwards and its a free upgrade (they've seen the light).

I'm using the IDE for most stuff now it's functional for me. But the Go console was a good experiment that I'll come back to with some slightly different use cases in mind.

@Gordon you mean the Go console I made? Yes that pulls the minified versions. It works really well from my use of it so far but I've not actually been using that in this process - there where too many variables as it was - so have upgraded Mac to El Capitain - now Chrome IDE working very well (lots of other stuff on my Mac now doesn't quite work at all or as it did, but hey ho)

Success. Cap was on ESP8266 already, but in a last ditch attempt I decided to reflash it, even though I had revision 0.25 it seems flashing it with the 0.25 bin on the ESP8266 page has resolved.

My serial and AT tests still behave as they did so they obviously have no bearing on the matter whatsoever, so I don't mind if you drop those posts, as I would not want to mislead others.

Is it possible for flash to be loaded improperly? Moral is - flash it - even if you think you have good firmware!

Don't think I've ever had to fight as hard for a hello world

|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v81 Copyright 2015 G.Williams
>echo(0);
=undefined
Connecting to WiFi
Connected
Response:  {
  "headers": {
    "Date": "Fri, 23 Oct 2015 12:32:39 GMT",
    "Server": "Apache/2.2.14 (Ubuntu)",
    "Last-Modified": "Fri, 15 Nov 2013 15:42:26 GMT",
    "ETag": "\"c01036-d-4eb390b8a8d18\"",
    "Accept-Ranges": "bytes",
    "Content-Length": "13",
    "Vary": "Accept-Encoding",
    "Connection": "close",
    "Content-Type": "text/plain"
   },
  "httpVersion": "1.1",
  "statusCode": "200",
  "statusMessage": "OK"
 }
--->Hello World!
> 

@Gordon, whatever I had above please ignore - I cannot reproduce on another Wifi network tonight. Beyond AT, AT+GMR, & AT+RST, nothing now works even with the serialTest function that I got results from earlier. Breadboard/hardware setup unchanged. :/

EDIT: Note all of the following actually had no bearing on issue. In end reflashing to the same firmware appears to have sorted it.

@Gordon thanks for coming back on this thread, I'll try and explain what I mean. As I understand it the AT module wraps serial. So I've got two test functions now, one that is sending AT commands directly using Serial2 and another using the AT module.

The first function (Serial2) and some calls with commented returns is/are below.

Note the return on ATE0, but that's another story, though I'm starting to disagree :D

// Serial Tests
var serialTest = function(cmd, timeout) {
  var l = "";
  Serial2.setup(115200, { rx: A3, tx : A2 });
  Serial2.on('data', function(d) {l+=d;});
  Serial2.write(cmd + "\r\n");
  setTimeout(function() {console.log(l);}, timeout);
};

serialTest("ATE0", 1000); 
// ATE0
// no this fun

serialTest("AT+CIPMUX=1", 1000);
// AT+CIPMUX=1
// OK

serialTest("AT+CWMODE=1", 1000);
//AT+CWMODE=1
//no change

serialTest("AT+CWJAP=\"xFxxxS\",\"xxebxxx\"", 1000);
//AT+CWJAP="xxxxxx","xxxxxx"
//OK

serialTest("AT+CIFSR", 1000);
//AT+CIFSR
//192.168.1.16

serialTest("AT+CWLAP", 5000);
//AT+CWLAP
//+CWLAP:(0,"",0)
//+CWLAP:(3,"Orxxxalign",-54)
//+CWLAP:(4,"BIOxxxAMD",-83)
//+CWLAP:(3,"CxxDUK",-52)
//+CWLAP:(0,"CDxxUK-GxxUEST",-52)
//+CWLAP:(4,"waxxdaroxxxWAP1xxx2ice",-64)
//CWLAP:(4,"Laxxxxxp",-67)  
//etc

Trying to test the AT module command at.cmd i have the test function below plus the calls and commented returns. Always one line whatever timeout is set. Never anything else.

// AT Test
Serial2.setup(115200, { rx: A3, tx : A2 });
var at = require("AT").connect(Serial2);
var atTest = function(cmd, timeout) {
  at.cmd(cmd + "\r\n", timeout, function(d) {
    console.log(d);
  });
};

atTest("ATE0", 1000); 
// ATE0

atTest("ATE0", 10000); 
// ATE0

atTest("AT+CIPMUX=1", 1000);
//AT+CIPMUX=1

atTest("AT+CIPMUX=1", 10000);
//AT+CIPMUX=1

atTest("AT+CWMODE=1", 1000);
//AT+CWMODE=1

atTest("AT+CWMODE=1", 10000);
//AT+CWMODE=1

atTest("AT+CIFSR", 5000);
//AT+CIFSR

When I added a few logging statements in the ESP module I downloaded and have locally I could see that in all cases I tested d was being evaluated against something that in the serial function is on the second line, but using AT it actually contained the first/only line (the command) - i.e AT+CIPMUX=1 != OK

I doubt that has clarified things much, and it's fair to say I'm a bit out my depth here, so please tell me if I'm muddying the water ;) but I suppose the question I'm posing is why am I ok using Serial2 but not the AT module which wraps Serial. Is there an issue in there?

Thanks for the tip. I pulled the ESP8266 module as you suggested. Upping the timeouts made no difference, so I also pulled down the AT module and tried to replicate what I can do with Serial2 (so far list APs, connect to a network and get my IP address) using at.cmd... and it strikes me that it is not abiding by the passed timeout param since it seems to return directly?

My AT command returns are two lines. I always get the issued command on the first line then OK on the line below. With Serial2.write and the timeout I get both to console. With my attempts to use at.cmd I only get the first, and immediately?

Also, it always seems to be first line (the command) that is in the var getting evaluated for a match to "OK" in the Esp8266 module code.

I'm not the best at following callback logic so I could be barking up the wrong tree - anyone confirm or deny that the timeout param in at.cmd is effectual?

100uf capacitors in the post tonight when I got home - so back at it.

Didn't help with the more advanced AT commands initially... but then in a stroke of "random" I upped the timeout in my test script - and started to get returns.

So...

I noticed the ESP8266 module calls the AT module with a timeout of 1000, which in my scripts couldn't do anything more than get a return from basic AT commands; other stuff like AT+CWLAP never returned (at least never to console output).

So at the risk of more noobness... could more generous timeouts in the ESP8266 js module help in the problems lots of folk seem to be seeing?

No problem, I imagine that could be a pretty big task given the info on there. I should have read the v1.81 release notes properly. That way I wouldn't have posted here plus you might even have got a PR for the change :)

I think that particular snippet is copy paste from the Espruino site actually, but there were others that were of my own crafting ;)

Thanks for that. I should have looked at that again before posting. Makes sense though - best fix my sloppy code :)

I have two picos, one on v1.80 and a new one that i've just flashed to v1.81.

On the board running v1.81 some code presents this error:

> in function called from system
> Uncaught ReferenceError: "l" is not defined
>  at line 1 col 23
> {digitalWrite(LED1,l=!l);}
>                       ^

The pico running 1.80 has no issues with it. Maybe there is more to it than this but this is the only obvious difference between the two picos? Has anyone else seen anything like this?

That's an interesting sensor - albeit a bit pricey. If you don't mind my asking what's your project. I imagine this would be a good way to monitor a fermentation process?

Thanks. I've got CH_PD connected. I guess a bigger capacitor is worth a shot though.