Oh shoot! Does Onion have a community manager now!?! Congrats! Just like a real-life Hardware startup

@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

Assuming you have serial console access or have terminal access from the wifi console, and that your onion omega is connected to the same wifi network. PLEASE NOTE: working node.js is NOT built from openwrt toolchain provided by onion corp., and I am still working on getting that 'container-ized', so that is still TBD.

1.) Download the two files from google drive I linked to, get them over to a mounted usb drive on the onion (i format to ext4). Run:
ln -s /path/to/usb/libv8.so /usr/lib/libv8.so

2.) and then go to:
cd /path/to/usb/

3.) and run:
./node --version

That's about it

OR
pull borromeotlh/docker-onion-omega-nodejs from dockerhub, then:
docker cp over 'node' and 'libv8.so' from /node/nodejs_deploy to your host machine
scp over those two libs onto a usb drive (ext4 formatted is what I used, but ymmv) mounted to on the omega
make a symlink for /usr/lib/libv8.so that points to libv8.so you just scp-ed over
go to usb drive and run './node --version'

https://hub.docker.com/r/borromeotlhs/docker-omega2plus/ Now builds from LEDE 17.01 branch. Use latest tag until I can properly tag it.

@Chris-Ward I compiled node from a completely different process than Onion's buildroot. It is also available at:
borromeotlhs/docker-onion-omega-nodejs

This image will contain the precompiled node and v8 binaries in them, I think in a folder called 'node_deploy'. That image will, I assume, have a working toolchain in it, though not entirely sure it was specifically suited to the onions hardware (tho node and v8 seem to work).

good luck!

@Lazar-Demin If that's what you have, then I already have an omega2 plus lede buildroot within a docker container. . .

You can utilize my containerized buildroot on docker with:
FROM borromeotlhs/omega2

The image was built for omega though, not omega2(+).

tagged a 'v1' image last night. This isn't tested, so I'd recommend you compile your own image with verified settings at your own risk. You will most definitely need to choose a different architecture to build for omega2, but the environment (LEDE) is set up to work.

I make zero guarantees nor warranties. Ymmv. Please consult a doctor and discontinue use if this software causes nausea, discomfort, vomiting or diarrhea.

@Stephen-Tunney docker use, as referenced by myself anyways, is only and always in reference to the host machine you would use to cross compile for the onion omega. Docker does not even officially support the arm work going on, that I think MIPS support is not existent.

@Chris-Ward https://hub.docker.com/r/borromeotlhs/docker-onion-omega-nodejs/

@Lazar-Demin as always, thanks for the response! I literally keep this open waiting for developments as they occur

I am assuming that this information will come, but you seemed to point out something I was worried about:
I have a bunch of static and/or dynamic libraries I want to link with, but without control of a makefile, I can't ensure the resultant application is built/linked properly. This is a slight downside, but, I can just build something that requires static libs myself, at that point, as I'd have more capabilities myself then cloud compile would actually give me.

To that end, I just realized that I could extend the docker container I made up for nodejs compiling to utilize the toolchain and create a arbitrary programs given a directory filled with makefiles/sources/static libs.

Nominally, I could mount a directory of a project via -v flag to draw in any git repo for building in my toolchain container. I could then have a build hook/script within the container or in the git repo that, post-build step, POSTs the results to onion cloud for loading and installation to the omega. This would entail that I also, along with mounting the project directory, perhaps mount the credentials directory for the specific API key I want to post to. . .

Love it! Now that onion cloud/ubus/api integration is up, I feel the community can move at a much faster pace. I feel, though, that perhaps you should invite and open up your design meetings to members of the community (as much as you can without sacrificing your competitive edge) so that community advocates can do this sort of documentation and whiteboarding for you I mean, I'm happy to spitball all my good ideas and all, but I feel you all should get to your core business and allow critical functions to be taken over by your dedicated and fanatical community.

Keep up the good work!

@Carlos-Sancho Than you should cycle through different colors and think about duty cycles. Do you absolutely need it on ALL THE TIME? Perhaps you can add a pushbutton to bring up a reading? In industrial plants that I've seen, this is what they do as constantly replacing LCD screens (or bulbs, depending on the age of the equipment) gets terribly wasteful and expensive.

And since it is the internet we're connected to, perhaps have an always on message bus, with the screen displaying when the pushbutton is pressed to compare network connectivity. It'd be a quick way to verify that your code or the network hasn't gone stale from a remote monitoring station, and it'd also protect you from burn in.

A final alternative is to add scrolling animations, or cycle which measurement is scrolling via above pushbutton.

Basically, add a button as a "JIT" duty cycle enabler. You'll be happier you did, and you don't even need to write software to create an electronic interrupt using a BJT or whatever. It'd be a nice experiment in low cost/low power/no code solutions.

Errrr, couldn't you utilize: https://onion.io/store/arduino-dock-r2/ ?

It seems that you would then get the maximum response from your sonar, and then shuttle the data from the arduino chip one to the omega. For around $25 (20 for the dock, and around 4-5 for the sensor) you could get this done much in the same way you have before, without having to depend on linux timing being a bit inadequate for the task.

@Luciano-S. I know that that can be done, but there should be a JavaScript button I can press to copy that info to my clipboard as well, right? Total convenience function, but it'd be nice if it's not too much trouble.

@Bas-Rijniersce I think settings.uiHost is the only place you can set the listen path. This may be an issue of your configuration file not being loaded with the same permissions as node-red is run as?

I good way to check is to see if changing the uiPort in the the settings file will be respected as well. Have you tried setting the listening port via the command line and then via the settings file? What command are you using to start node-red?

@Chris-Stratton I have never seen swap pushed that far, or assumed to be that efficient on any embedded system. I think, though, that you've seemed to answer the question with your suspicion on SD card performance. Have you tried class 10 cards on a 2plus? the other option is the max size command, which seems to work for some.

@Bas-Rijniersce also, swap space only moves data out of ram based on LRU, it doesn't take away the fact that while in operation, an entire program generally needs to be resident in memory. this would mean that node.js, libv8, and node red at least ( and that's not counting whatever lib you are going to put on to run the web front-end, if at all)

@Bas-Rijniersce no problem. I did mean ram, as I don't know what the swap space size is set at for the omega 2. also, turns out that node red is only built out for omega2, so it's def not an architectural issue. This all makes me wonder why yours is not working when the tutorial seems to imply this should work out of the box. . .

@Bas-Rijniersce
http://nodered.org/docs/hardware/raspberrypi.html

The article above talks about starting node red on a pi such that memory is culled at 256MB! There's also mention of how you can (and should) set the limit at which node.js and node-red begin memory reclamation.

@Lazar-Demin @Boken-Lin : do you all intend to set the node.js memory limit in the omega openwrt package itself?

@Bas-Rijniersce now that I actually look at the error messages it seems that you need to reduce the size of your base image. Even still, node red might just be taking up the remainder of your 64MB of memory despite that.