Doesn't install properly with nodejs version 0.12.13

[maxwellhadley]

This relates to the same system as in my comments to issue #41

Debian Jessie installs the nodejs 0.12.x release by default. I've added the nodesource repo so I get 0.12.12.

Octalbonescript fails to install properly, because it has a dependency on i2c version 0.1.8, and this version fails to compile on nodejs 0.12.x. Changing the dependency in package.json to "i2c": ">=0.1.8", and re-installing i2c from the octalbonescript directory gets i2c 0.2.1 which does compile. However I have not yet tested it for correct operation, because of issue #41.

Linux 4.1.18-ti-r53 arm LE, nodejs 0.12.12, octalbonescript 1.1.2

[adityapatadia]

41 is closed. Can you check i2c operation with 0.2.1 I2C? I will update the code if it is working fine.

[maxwellhadley]

Node.js has now been updated to 0.12.13! I don't have any i2c hardware devices handy so I can't thoroughly test it. However, I can run your example code, and try to scan the bus, although no addresses are returned:

var b = require('octalbonescript');

b.i2c.open('/dev/i2c-1', 0x018, function (data) { console.log(data); },
            function (error, wire) {
            if (error) {
                console.error(error.message);
                return;
            }
            wire.scan( function (err, data) {
                if (err) {
                    console.error(err.message);
                    return;
                } else {
                    console.log(data);
                }
            });
});

However, as far as I can tell from the documentation i2c version 0.2.1 does not work on node.js version 0.10.*

[jadonk]

With recent Debian images coming from @beagleboard, we are now shipping with a newer version of nodejs. We'd like to start shipping with octalbonescript as well since its used by node-red.

As a worst-case fallback, can you install both versions of i2c and set them to different names, such as creating a fork of the old i2c and calling it i2c-legacy? Much discussion was had on this topic at https://github.com/npm/npm/issues/5499 to give you some food for thought.

We have an urgent need to fix https://github.com/rcn-ee/repos/pull/10#event-652644899

[cautiousCentaur]

Guys, this is a mess, different versions, forks, kernels, bugs in everything. This could threaten the entire beaglebone platform. Arduino just works ootb, I know it's simpler, but how do we expect beginners to buy in to all this.

[jadonk]

@kory44 what is your suggestion? My feeling is that we focus on an integrated set of features in the official release images and make that integrated set of features "just work". Better to ask people to upgrade to the latest image (getting easier all the time, partially now thanks to etcher.io and eventually we'll be able to leverage a cross-platform, browser-based BBBlfs) than to get mired down in nothing but trying to keep old images working. https://github.com/beagleboard/image-builder is our primary integration point with http://github.com/beagleboard/repos and http://beagleboard/linux feeding into it. Support from projects feeding into it to perform continuous integration (http://builds.beagleboard.org) should provide a reasonable test basis for getting stuff that works to other members of the community.

[cautiousCentaur]

(Edit: So I just re-read your post, I think we're on the same page) I'm a mechanical engineer, so I don't have a fancy suggestion, but I think each image should get a release that's compatible with the released node, and that version should be stable enough to last to next image. If it's got bugs it shouldn't make it into image.

Stability is more important than latest features.

Need to create a suite of automated tests that can automatically pass an image so no one should ever have to upgrade. Feature creep will kill this project if you lose critical mass of followers.

Can apt-get update/upgrade handle this, npm is too explicit.

Upgrade settings should be implicit to the distro/image, user shouldn't have to specify anything

I definitely believe bonescript should be baked into the image, not so reliant on npm

[RobertCNelson]

@kory44 "bonescript" is an npm package...

"Supported" is more important the latest features. That's what i'm pushing..

Right now we for default images we have, and users are free to use what ever they want..

Debian 7 (Wheezy) = nodejs v0.10.x Debian 8 (Jessie) = nodejs v0.12.x Debian 9 (Stretch/testing eta release in ~10 months) = nodejs 4.x

From: https://github.com/nodejs/LTS#lts_schedule

Release LTS Start   Maintenance Start   LTS End
v0.10   (current)   2015-10-01  2016-10-01
v0.12   (current)   2016-04-01  2017-04-01
v4.2.0  2015-10-01  2017-04-01  2018-04-01
v.Next  2016-10-01  2018-04-01

So in 5 months, v0.10.x is going eol, but note by 2017 Q1, i'm going to start axing any non v4.x nodejs packages.

Regards,

[adityapatadia]

Hi @jadonk I will be happy to help if you are planning to ship with OBS. I am merging #66 and release new version tonight so OBS starts working on nodejs 0.12.x. I really feel that it makes sense to release OBS v1.5.x so that node 0.10.x users can keep using current version and new users can use latest version.

I will document it in release notes and readme as well.

[Andrewiski]

What is the highest version of node the you recommend for OBS assuming the latest stable BeagleBone Debian release which at this moment is 4.1.15

[RobertCNelson]

@Andrewiski

the i2c npm package only supports nodejs v0.10.x & v0.12.x

for v4.x, i2c doesn't currently support it, and based on: https://github.com/kelly/node-i2c/issues/69

most users are switching to i2cbus instead..

Regards,

[adityapatadia]

@RobertCNelson Should we move to i2cbus in OBS?

[RobertCNelson]

@adityapatadia i think we should, as it has nodejs v4.x+ support now...

BUT it's not a drop in replacement i2c. Thus it's more of a target goal, due to it requiring a rewrite for users.

[adityapatadia]

If we can keep APIs same, it would be great to migrate it. I will take a look when I get some time.

[Andrewiski]

So I know I am working bleeding edge as you are still working out migration paths of dependencies, but just wanted to throw in my observations. So this is on a Beagle Bone Green, Linux beaglebone 4.1.15-ti-rt-r43, Node 0.12.13 running octalbonescript 1.2.0, "npm install" returns no errors Anyways seem to be having an issue access the eprom. Is this a Beaglebone Green issue or did I miss something?

If there is anything I can do to help with migration or testing please let me know.

Anyways here is the debug output.

DEBUG=bone node bin/www bone Using Universal Cape interface +0ms bone is_ocp() = /sys/devices/platform/ocp +82ms bone find_sysfsFile(cape-universal,/sys/devices/platform/ocp,ocp:cape-universal) +26ms bone is_cape_universal() = /sys/devices/platform/ocp/ocp:cape-universal +9ms bone index.js loaded +9ms bone Reading EEPROM at /sys/bus/i2c/drivers/at24/0-0050/eeprom +11ms bone Unable to open EEPROM at /sys/bus/i2c/drivers/at24/0-0050/eeprom: Error: ENOENT, no such file or directory '/sys/bus/i2c/drivers/at24/0-0050/eeprom' +8ms /var/hvacController/node_modules/octalbonescript/lib/hw_universal.js:99 if (x.boardName == 'A335BONE') platform.name = 'BeagleBone';

---

ls /sys/bus/i2c/drivers/at24/0-0050 at24-0 driver modalias name of_node power subsystem uevent

[RobertCNelson]

@Andrewiski

For Reading the board eeprom:

v4.1.x (early versions): /sys/class/nvmem/at24-0/nvmem

v4.1.x (later) -> v4.3.x /sys/bus/nvmem/devices/at24-0/nvmem

v3.8.x, (skip) v4.4.x+ (and mainline) /sys/bus/i2c/devices/0-0050/eeprom

Regards,

[Andrewiski]

@RobertCNelson

Thanks for the reply so based on your reply I could just move to debian 8.4 and the old path works again and so should the octalbonescript call.

Is the team developing against debian 8.4 for octalbonescript 1.2.0?

Thanks

[RobertCNelson]

@Andrewiski so the 2016-05-01 release of debian jessie (8.4):

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt

Is our first release with the v4.4.x-ti kernel

I for-see a bunch of users still using v4.1.x-ti, but v4.4.x-ti is in a much better shape as a lot of the dt-overlay patches in v4.1.x-ti went into mainline..

Regards,

[Andrewiski]

@RobertCNelson

Any chance we can exchange some emails? adevries at digitalexample.com