Search results for:

@MaBe @Gordon thank you both. This is what I thought should be happening and what I've been doing. Thanks for confirming.

Thanks Gordon. Hope 2016 is the year Espruino goes mainstream - where it belongs. Have a good break and Christmas.

Almost 24 hours now. Best I had before was about 14, so I'm hoping I can ride out server disconnections now :)

What is the best way to save() code that has required modules (whether local or from the espruino modules directory), so to be able to run standalone?

Yes. The way I was setup I could destroy the object but then I lost the listeners, so I've moved the whole thing including require, connect and the listener bindings into their own wrapper method which I recall on disconnect event. Appears to be working well with my triggering disconnect, so hopefully works when server triggers it. Thanks for the steer @Gordon

@Gordon, very likely, and I think the way I've setup my code is not helping me clear and reinstantiate it. I'll have a look at that first before I waste any of your time here.

I think I need unsubscribe, to clean up, then reconnect

I'm testing against test.mosquitto.org. Every so often I get disconnected - which I imagine is from the server and is to be expected, as I think they regularly rollout the latest version.

I have a disconnect event I can listen on, and currently I reissue mqtt.connect() in the events callback. My problem with this approach is that I'm losing memory. It might survive one reconnect, but not two. I have duplicated message listeners which I imagine is part of the memory problem.

I considered another approach would be to save to memory and fire the reset() function, to bring the board and whole program back up?

But is there any pattern/approach that I could use to recover without a restart?

Edit: I've just considered that maybe I should unbind the listeners in the disconnect event callback too?

Great thanks - something for the weekend!

@Gordon would this manifest itself just in HTTP or would anything dependent on sockets be impacted?

Nice, thank you for pointers. This is all new to me - and I thought I knew a bit of javascript - shows how lazy can be when space and memory not at a premium!

Just the first of your suggestions - binding the onData function late only pushed the module size up marginally, but saved 32 jsvars! Looking at the commits now.

Apologies for momentarily hijacking this thread, I know this was a bit off topic. Thanks again.

@gordon, thanks for reply in other post on the object vs extending prototype piece. Looking at the above commits, you've made some prototyped methods into generic functions? Is the benefit here solely compactness of the script so less to load or is there more to and by not making them part of the MQTT object you're saving memory?

Will check that out. I've just this minute got my fermentation script measuring temp, controlling two 433Mhz sockets, reporting actual temp over MQTT and listening for targetTemp adjustment commands over MQTT also. It's running on an "OUT OF MEMORY" knife edge, and had to strip most of the console progess logging, and I doubt will stay up long. So I'll be sure to look at all the above suggestions. Thanks again!

Re below snippets, can anyone advise what is least expensive from a memory perspect. I have a habit of doing the former, since I thought I had read it saved memory (or at least was quicker??) but notice that many of the modules extend prototype. So which is better, this?

var myObj = {
 myproperties: {},
 method1: function() {},
 method2:function(){}
};

or this?

myObj = function(){
 this.properties = {};
};
myObj.prototype.method1 = function(){};
myObj.prototype.method2 = function(){};

Great stuff thanks @Gordon I'll try that!

It's here - https://github.com/olliephillips/tinyMQTT
There is a lot missing from the original module, but I've been testing against test.mosquitto.org and it seems to do enough for my use case. If it can be better, and still small, please let me know :)

I've been trying to hack the MQTT module myself over the last couple of days. To get it to load with no "out of memory" I had to be sub 3k. Even then, there was not enough memory to do anything, so the best I achieved was connecting. However, going bottom up and with the help of your Kickstarter example I have a module that will do publish and subscribe with events to sort of match the existing module's API, that comes in 1.3k minified. I'm testing it now and will share it ASAP.

I now own another full size board. That's a very good deal!

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?

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

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
});

I do it like this:

function onInit() {
 // Call to an function that kicks off my code
}  
save();

My undertstanding is that onInit() fires automatically on startup/reset. I make save() the last line of code. I can't advise if this is the best way, but it does seem to work.

@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.

@tve great stuff!

I think the watch feature would be cool and useful. Keeps everything self contained and easy start. In the go version it was a very simple thing to implement as someone had provided a package. Same appears to be true for Node.js

https://www.npmjs.com/package/filewatcher

@Gordon I noticed you gave Espruingo a mention - thanks very much- but you know now I'll have to maintain it ;)