Topics created by brolly759

Is there a solution for OpenWRT 18.06, and onoff-node? Version: Ω-ware: 0.3.2 b218 After upgrading this no longer works. opkg install onoff-node Unknown package 'onoff-node'. Collected errors: * opkg_install_cmd: Cannot install package onoff-node. I figured it out. onoff-node is gone now that npm onoff is available. Here are steps I went through to get it working. OpenWRT 18.06 & Nodejs installing onoff node module [ solved ]

I tried that already and it fails in the build process. I tried creating an updated LEDE build (Using the Omega parameters and selecting openzwave as a library to build (in menuconfig ) with and for some reason it fails. The best guess I can think of is its building for the wrong OS / using the wrong toolchain but I dont know... that is why I am here

I am not going to use ubus for this , I will pass the arguments directly into wifisetup. For future reference, this is what works now: wifisetup add -ssid test -encr wpa2 -password test1234

@brolly759 said in Queue System?: I am working in NodeJS and started to implement a queue system. I have the que system writing to files on the tmpfs directory. Is the tmpfs directory memory resident so I dont wear out the flash? Yes, tmpfs is in RAM, so no problem with writing a lot there. It seems that reading from the que is slower than writing, maybe 3-4 files a second vs writing files at about 50 a second. That is strange - I see no reason why there should be any noticeable difference between reading and writing to tmpfs. Of course it depends on the exact access pattern - if you write in large blocks at a time but read in tiny chunks, then there will be a performance difference due to system call overhead etc.

iwlist is in /usr/sbin/iwlist aps seems to work, though no nodeJS plugin for it. Maybe I can create an app that prints the "aps" debug into JSON format.

@brolly759 said I tried the above and it worked, if you have the time, try it to and let me know how it goes! Well, perhaps you can backup your uboot, but it seems that you can't write it back this way: # mtd write u-boot.bin mtd0 Could not open mtd device: mtd0 Can't open device for writing! [edit] You can, but it's not as trivial, so it requires some hoop jumping to get it done. # mtd write u-boot-env.bin u-boot-env Unlocking u-boot-env ... Writing from u-boot-env.bin to u-boot-env ... # mtd write u-boot.bin u-boot Unlocking u-boot ... Writing from u-boot.bin to u-boot ... [/edit]

I know this topic is quite old, but did anyone succeed in making eth0-4 work on the Omega2S in the meantime? I am just wondering, bc all documentation on the Omega2S i found so far only mentions 1 ethernet port - if it supported 5, why not say so in the docs? Of course the datasheet of the MT7688 clearly specifies 5 ethernet ports in IoT gateway mode, so why not in the Omega2S documentation?

The problem is the overlay scheme - when you make changes, you don't actually replace the existing files in the same storage blocks, rather you use additional blocks to store the updated files, with the overlay system then hiding the original versions as they continue to take up space. The only real fixes are to not replace as many existing files put the versions you need in the read only partition; technically this can be done by skilled use of uImage and squashfs tools without the rebuild from source that would normally be used to generate a custom disk image (over a year in, building from source still doesn't yield a system with working wifi), but it would be a fairly tricky process to figure out use some other storage media, though beware that SD cards tolerate unprepared power cycling and even usage for Linux type filesystems relatively poorly. Changing the size of the tmpfs partitions won't help, as those are ramdisks, and only really use memory to the extent that they are utilized, which the 1% and 0% numbers indicate they are not.