Does node.js not include packages in opkg yet?

Dan L.

Hmm, looking into this now, I just woke up. I'm getting the same error, but also note you need to call var Controller = new gpiohelper(); — the new keyword creates an object with the methods. Otherwise, the constructor function runs but you wont get an object out of it.

Theodore Borromeo

@Dan-L. updated code:

var gpiohelper = require('./GPIOHelper'),
    ledPins = [0],
    buttonPin = 26;

var Controller = new gpiohelper();

function turnOn(){
    for (pin in ledPins){
            Controller.setPinSync(pin,1);
            print("Turning on pin {0}".format(pin));
    }
}

function turnOff(){
    for (pin in ledPins){
            Controller.setPinSync(pin,0);
            print("Turning off pin {0}".format(pin));
    }
}

do {
     var p1 = new Promise(
         function(resolve,reject){
             setTimeout(turnOn,1000);
         });
    p1.then(
        setTimeout(turnOff,1000)
    )
    .catch(
        function(reason) {
            console.log(reason + ' rejected');
        });
} while(1);

Still no dice, and same error.

Dan L.

Turns out the export errors are kinda OK? Still works without em (if you try/catch). It's not working from the command line either.

There were also a bunch of other bugs, like the wrong variable name as you found above, and if you called .setPin(5, true) it would send "true" rather than "1".

Try the new code, then check the "/sys/class/gpio/" folder — do you see a bunch of gpioX folders?

EDIT: Code now here https://community.onion.io/topic/46/simple-node-js-wrapper-and-demo

Theodore Borromeo

@Dan-L. SO with this code in test.js:

// test.js
var GPIOHelper = require('./gpiohelper');

var helper = new GPIOHelper();

// Get pin value synchronously
console.log("Sync value was "+helper.getPinSync(1));

// Set some pins synchronously
helper.setPinSync(0, true);

// Get pin async
helper.getPin(0, function(err, val) {
    if(err) {
        console.log("Couldn't set pin?", err);
    } else {
        console.log("Value is", val);
    }
});

// Set pin async
helper.setPin(0, true, function(err) {
    if(err) {
        console.log("Couldn't set pin?", err);
    }
});

helper.setPinSync(0,false);
console.log("Sync value was "+helper.getPinSync(0));

I get:

/mnt/sda1/out/Release/node test.js
Ignoring pin 0 export error Error: EBUSY, resource busy or locked
Ignoring pin 1 export error Error: EBUSY, resource busy or locked
Ignoring pin 6 export error Error: EBUSY, resource busy or locked
Ignoring pin 7 export error Error: EBUSY, resource busy or locked
Ignoring pin 8 export error Error: EBUSY, resource busy or locked
Ignoring pin 12 export error Error: EBUSY, resource busy or locked
Ignoring pin 13 export error Error: EBUSY, resource busy or locked
Ignoring pin 14 export error Error: EBUSY, resource busy or locked
Ignoring pin 23 export error Error: EBUSY, resource busy or locked
Ignoring pin 26 export error Error: EBUSY, resource busy or locked
Ignoring pin 21 export error Error: EBUSY, resource busy or locked
Ignoring pin 20 export error Error: EBUSY, resource busy or locked
Ignoring pin 19 export error Error: EBUSY, resource busy or locked
Ignoring pin 18 export error Error: EBUSY, resource busy or locked
Sync value was 1
Sync value was 0
Value is 1

So with some static typing, I perhaps could have realized I should have been using 'true' and 'false' instead of int values Though I don't even think that it would have mattered. I'm modifying code now to get a simple blink example off of pin 0.

Dan L.

@Theodore-Borromeo Ahh, well 1 or 0 would have worked with the previous code — but I updated it so any "truthy" value will be sent as "1".

Next step is adding some event listening, which should really get things moving. It'll be hacky though and have to use polling! Will try and implement tonight though

Theodore Borromeo

It seems that depending on javascript to take care of file handle closing, especially with asynchronous calls, is a bit too much with the current state of this sample

I get, when I just try to run a blink example in an infinite loop, this error:

Error: EMFILE, too many open files '/sys/class/gpio/gpio0/direction'
    at Object.fs.openSync (fs.js:427:18)
    at Object.fs.writeFileSync (fs.js:966:15)
    at GPIOHelper.setPinDirectionSync (/mnt/sda1/scripts/js/gpiotest/gpiohelper.js:61:8)
    at GPIOHelper.setPinSync (/mnt/sda1/scripts/js/gpiotest/gpiohelper.js:65:10)
    at Object.<anonymous> (/mnt/sda1/scripts/js/gpiotest/test.js:15:23)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)

I think that, perhaps it wouldn't be a bad idea to utilize a command line to fast-gpio, so that this stuff is taken care of for simple access. Until, that is, lower level and better syncing primitives are explored. This driver, I think, would best be implemented in C and wrapped up into a js lib, right? Heck, I'm not exactly well versed in getting the js side hooked up to the C low end drivers, so I wouldn't be the best person to ask.

In any case, this is a good start and proves that your system works. Of course, for pins, EBUSY doesn't make any sense for those coming from the arduino/avr world. But, having linux on your device is going to expose all the ugly embedded nonsense that makes it not that fun

Theodore Borromeo

@Dan-L. Cool! I'm honestly not really that great with Javascript yet, just knowledgeable enough to get myself into and out of trouble. However, the reason I bought the omega was the idea that we as the community could define node packages, have node.js on device, and just extend the capabilities for the device with npm.

The solution I stumbled upon did seem to have npm, and can be built with the script:
https://github.com/nneves/openwrt_mips_ar9331_nodejs/blob/master/npm_mips_ar9331.sh

So, when I get time on Monday, I'll probably have to update the Dockerfile for nneve's scripts to build npm too. That should allow us to quickly iterate on stuff, push to npm, and then disseminate that way until official support for a slimmer node.js server comes from Onion, Inc.

Great stuff and great progress!

Dan L.

Hey @Theodore-Borromeo, can I see your blink code? I'm managing to write a bunch of things and not getting the EMFILE, too many open files message at any point. If you were using setPinSync you shouldn't get that, but maybe with just setPin you might?

Theodore Borromeo

@Dan-L.

// test.js
var GPIOHelper = require('./gpiohelper');

var helper = new GPIOHelper();

//blink LED hooked up to pin0
do {
    setTimeout(helper.setPinSync(0,true), 500);
    setTimeout(helper.setPinSync(1,false),500);
} while (1)

As I don't have access to sleep() (haven't figured out how to do that yet in js), I may be hosing myself by using non-synchronized setTimeout. . . Again, js is not my forte.

I was thinking this would be better:

 // test.js
var GPIOHelper = require('./gpiohelper');

var helper = new GPIOHelper();

function toggle(value) {
     return value == true : false ? true;
}
//blink LED hooked up to pin0
var truthy = false;
do {
    truthy = toggle(truthy);
    setInterval(helper.setPinSync(0,truthy), 2000);
} 
while (1)

Though I left my omega at home so can't test right now

Theodore Borromeo

Also, as per https://github.com/paul99/v8m-rb/pull/19#issuecomment-24131056 , you can tune node via libv8 parameters via command line, which may help getting this tuned.

Dan L.

Hey @Theodore-Borromeo

setTimeout(helper.setPinSync(0,true), 500); will set the pin immediately. The first argument of setTimeout should be a function, but you're actually just passing in the return value of setPinSync (which is undefined). You probably meant to do this:

setTimeout(function() {
    helper.setPinSync(0, true);
}, 500);

BUT, doing that will still just delay that call by 0.5s. If you do that a bunch of times in an infinite while loop, you're actually just queueing an infinite amount of timers to run, but since the loop never ends, the timers never get a chance to run. An infinite while/for loop will halt all timers, due to the way V8's event loop works.

Instead you probably want to use setInterval, not in a loop:

var lightState = false;
setInterval(function() {
	
	// Toggle
	lightState = !lightState;
	
	// Set value
	helper.setPinSync(0, lightState);
	
}, 500);

Or you could recursively call setTimeout. This one will toggle the light on/off at random intervals:

var lightState = false;

// Function which is triggered every 0+ to 1 seconds
var next = function() {
	
	lightState = !lightState;
	
	helper.setPinSync(0, lightState);
	
	setTimeout(next, Math.random() * 1000);
	
}

next();

I also put some samples on GitHub

https://github.com/manspaniel/node-omega-gpio

Theodore Borromeo

@Dan-L. Yeah, as soon as I posted the do-while loop that will continuously call a function some half a second into the future, I realized that I wasn't going to get far. In any case, the do while loop was a hold over from me sleeping for half a second and toggling on and off forever.

But I'll def take a look later and see your examples. Coincidentally, the newest firmware has a way to set the GPIO pins directly via the "GPIO Helper Tool" app! I hope that they reimplement their landing page as a webapp hosted by a node.js server running on device! That would be poetic

Lazar Demin

@Theodore-Borromeo About the Console, the front-end is implemented in HTML and Javascript, and the back-end uses the OpenWRT UBUS service, which is language independent.

Don't worry, we plan to release a detailed guide on how to implement your own apps and how to extend the UBUS service! No definite timeline for this guide but it's definitely on our list of priorities.

Theodore Borromeo

@Boken-Lin @Lazar-Demin
from borromeotlhs/onion-omega:v1

is now available for use in a Dockerfile. it'll contain the entirety of the toolchain per your cross compile environment setup guide.

Regards,
TJ

Boken Lin

@Theodore-Borromeo This is fantastic! We'll put it up on our website so that everyone can use it to compile their firmwares

Theodore Borromeo

@Boken-Lin That's fine, but I still haven't compiled a thing with it!! Can anyone test it to compile some drivers and stuff?

Boken Lin

@Theodore-Borromeo I will test it out when we are doing our own compilation stuff. BTW, would you be able to write a simple tutorial in markdown showing the steps to get the image up and running on Docker? I think it can be a really useful thing to have on our wiki!

Theodore Borromeo

@Boken-Lin Assuming you know how to use docker, there are only a few ways to run it:

1.) Pull the image from docker hub and run an interactive console. e.g.:
docker pull borromeotlhs/onion-omega:v1
docker run -it 'borromeotlhs/onion-omega:v1' /bin/bash

2.) Pull the image from docker hub, reference it in your own Dockerfile 'FROM' line, run resultant image built from that Dockerfile. e.g.:
docker pull borromeotlhs/onion-omega:v1

<Dockerfile>
MAINTAINER joeschmoe@schmoenet.com
FROM borromeotlhs/onion-omega:v1

RUN . . .
</Dockerfile>

docker build -t 'my-new-image' .
docker run -it 'my-new-image' /bin/bash

There But yeah, let me know what repo you want me to write this out in Markdown, and I'll try to get to it.

PS
My vote for a package you all could try: https://github.com/OnionIoT/OpenWRT-Packages/tree/master/iojs

Chris Ward

@Theodore-Borromeo Is this your published docker image - https://hub.docker.com/r/borromeotlhs/onion-omega/ Is it best to start with this then?

Christopher Hiller

Has anyone had success building the iojs 2.x package?