I think you need to try an avoid using python-pip unless you can get it to use a USB drive, @Vitalii-Topoliuk . if you're running out of space just installing python-pip, imagine how quickly you'll run out of space trying to install your python packages and all their dependencies on top of it.

my bet would be on trying to use pure python scripts and upload a self-contained project that doesn't need installation or compilation. alternatively, I would try building it in a buildroot environment and transferring it to the omega with all the dependencies resolved.

I've tried installing python-pip as well and ran out of space because it pulls in way too many dependencies. I wouldn't even know how to compute the space it's going to need, but i suspect it'll be much bigger than the available space on the omega, even with /www removed.

Hi guys, is there a way to figure out what has changed between versions? When major or minor versions go up, there must be some kind of change. Maybe there a diff to look at on GitHub or elsewhere.

opkg update downloads metadata into /tmp. When you shut down your omega and boot it back up again /tmp gets wiped and you lose the lists of available packages. So the next time you boot you need to run opkg update to install something. If you don't, the package will not be found and can't be installed.

Here's another tip. To see what packages are available, run opkg list. When I'm looking for a particular package, say python, I run opkg list | grep python. This gives me all packages that have python in the name or description. Sometimes it returns too many packages, so I adjust my query or use other tricks to make sense of it.

Hi guys, I did a quick talk and a demo of my Onion Omega setup at a meetup in Sydney.
I showed off my set up with one omega used as an access point and a MQTT broker and two others connecting to it for WiFi and MQTT. One of those was a pressure and temp sensor pushing messages to the queue. The other was fetching and displaying this data on the OLED expansion. All of the work is done in a few bash scripts that use i2c, oled and mosquitto command line tools.

http://www.meetup.com/OzBerryPi/photos/26969207/#449991484

If you have configured you Omega(s) to be on your local wifi and don't want to type their omega-xxxx.local each time, you can easily navigate to them via Bonjour in Safari on your mac.

Go to Safari Settings > Advanced -- see the Bonjour section to enable the menu in Bookmarks on in Favourites bar.

Hi peeps, this is just a heads up that i2cget command-line tool is little endian. This means that when you request a word from it, it assumes the first byte is the least significant one. So if you're reading from a sensor and it gives you two bytes in sequence, say first 0xAA then 0xBB, i2cget will output 0xBBAA.

My sensor is big endian, so I end up having to flip bytes every time I read a 16bit word. In my case i need 0xAABB from above example.

It's probably the case that i2cset is little endian as well. I haven't had to write any data via i2c on command line, so cannot confirm.

Looks like with a bit more hardware you can run SPI over I2c

NXP SC18IS602BIPW: I2C-bus to SPI bridge

I think the discussion of the future of community should be moved out of this thread. Either into a category of it's own or at least a thread. I don't think NodeBB structure encourages good structure. Perhaps, the roadmap should be managed in Github issues - this way, even if there's not much future planning, you at least get a way to construct a changelog and explore all associated conversations.

To begin with, I would recommend you guys to familiarise yourselves with the work of Pieter Hintjens and his efforts on building the ZeroMQ community. Here's one of his recent articles that may be relevant: Ten Rules for Open Source Success. There are quite a few of his talks on YouTube where he talks about community building.

Main thing to do now would be to publish the roadmap - you keep referring to it in many posts. Then you need to reach out to the community for help in bringing that roadmap to life.

At this stage, I think that the software side of things is something community could clearly help with. Things like building and porting OpenWRT packages to omega and configuring systems for particular use cases. As an example, for many answers to my questions I go directly to OpenWrt website as they have a decent structure and tons of content. Something similar can be achieved with a system like GitBook. I personally believe that if it's not possible to comment on a piece of documentation - it's dead. All docs must be searchable.

Thanks @Boken-Lin

I think you guys should consider opening up this project a bit more and asking for community help with things, not try to do everything yourselves. You're doing a great job with the hardware and i presume a lot of time is going into trying to commercialise the service side of things and the app store. With only the 3 of you working on it, there's not much time left to work on documentation and helping the community get the most of their omegas.

As I understand it, success (velocity) of projects like this one is heavily dependent on community, transparency and docs/specs/guides. Personally, I think forums are a great place to interact, but not a great place for longer-term knowledge capture or as a "source of truth". Your wiki is kinda there, but it doesn't allow community participation or comments. Perhaps GitHub should play more of a role in helping community participate or resolve issues.

Good job on the update and on giving us NodeJS!

Hi @Carlos-Sancho how do you control your OLED? do you use oled-exp or related python/c libraries or did you have to write your own program to communicate with the display?

Hi guys, I did a quick talk and a demo of my Onion Omega setup at a meetup in Sydney.
I showed off my set up with one omega used as an access point and a MQTT broker and two others connecting to it for WiFi and MQTT. One of those was a pressure and temp sensor pushing messages to the queue. The other was fetching and displaying this data on the OLED expansion. All of the work is done in a few bash scripts that use i2c, oled and mosquitto command line tools.

http://www.meetup.com/OzBerryPi/photos/26969207/#449991484

Thanks for the update and the change log. I guess now that kmod-bluetooth is in, we'll have a quick tutorial on using the BLE dongle. Can't wait.

Here's some more code I found on the web for configuring openwrt to act as a bridge

https://bitbucket.org/pklaus/openwrt-configurations/branches/compare/TP-Link_TL-MR3020%2Fwisp TP-Link_TL-MR3020%2Fdefault#diff

https://bitbucket.org/pklaus/openwrt-configurations/src/c6186f9106c7?at=TP-Link_TL-MR3020/wisp

Thanks @Lazar-Demin. I was trying to avoid dropping down to C level just yet.
I did see that the C library allows more flexibility in reading and writing bytes over i2c.

I'll start another thread when I get into Python i2c interaction. Will check out your code.

Looks like you're on the right track.
Here's a bit more info. https://wiki.openwrt.org/doc/recipes/dumbap
This doc also talks about disabling DHCP and the firewall.

I played with it last night but couldn't get it to work yet. Was configuring it over serial and trying to connect my computer to Omega acting as Dumb AP. Will try again later.

Looks like you need to disable DHCP on the omega and let it act as just an access point without creating a separate network.

My experimental setup is similar to yours:
ADSL Router --> WIFI 1 --> Onion A --> WIFI 2 --> Computer and Onion B

I've considered in disabling DHCP on Onion A, but didn't because sometimes I find myself in a situation without internet or main router, but still wanting to hack on the Onions. Having Onion A be my router and access point is quite helpful in those situations.

Hi @Boken-Lin, the main limitation of i2c-tools for me is that the binary i2cget cannot read more than 16 bits in one go - i need to read 24 bits, for example. The fact that it's endianness cannot be controlled is a bit of an inconvenience, but can be worked around.

I am yet to interact with i2c via python, mainly because py-smbus parts of i2c-tools are not compiled and not available for install via opkg. Hence my need to get my hands dirty with buildroot and compilation.

Hi peeps, this is just a heads up that i2cget command-line tool is little endian. This means that when you request a word from it, it assumes the first byte is the least significant one. So if you're reading from a sensor and it gives you two bytes in sequence, say first 0xAA then 0xBB, i2cget will output 0xBBAA.

My sensor is big endian, so I end up having to flip bytes every time I read a 16bit word. In my case i need 0xAABB from above example.

It's probably the case that i2cset is little endian as well. I haven't had to write any data via i2c on command line, so cannot confirm.

fair enough @Kit-Bishop, i thought you were just trying to compile i2c-tools.
can't help you with compilation yet as I haven't tried setting up a buildroot yet. intend to get to that soon as I'm hitting limitations with stock i2c-tools and need to go to writing code in C.