The idea came from the fact that we have an IRC channel for the Taipei Hackerspace, #taipeihack on Freenode, just it is not very well (or rather: at all) frequented by people. I wanted to break that channel out of the computer, and put a physical window to it in the ‘space, so people can see what’s going on, and hopefully want to get on too!

Here is it in action:

Hardware

For this I’ve used parts that were pretty much lying around in the Hackerspace:

• an Intel Edison, then added…
• an Android Breakout Board,
• a Grove Base Shield
• a Grove RGB-LCD (that is controlled over the I2C lines)
• a Grove LED (on one of the digital pins)

I’ve started a new project in the Resin.io interface based on Edison. Downloaded their image (and checked out getting started guide), flashed it onto the board through the Android breakout board, and it was ready to get some code on (well, kinda).

Software

In the docs I’ve found that there’s a specific docker starter container made by the Resin team for Python code, and that looked like a good point to start off from.

First I was thinking using the default mraa library that Intel provides for the low level I/O, but fortunately also found UPM, a higher level library that already supports a lot of sensors and I/O – including the RGB-LCD! That saves a lot of time indeed, and has both Python and Node.js API for quicker code (besides the base C++).

Mraa is already installed on the base image, but UPM had to be added manually to the Dockerfile.

The base function of the code is crystallized out as:

• connect to a specified IRC server and join a specific channel
• listen to the messages there
• on the LCD display the messages as:
  • first line shows the user that posted
  • second line is the message posted, if longer than the width of the LCD then scroll it
  • to quickly distinguish between people, assign different colours to the different users
• blink the LED on new messages
• keep doing this…

Straightforward enough?

I’ve used the irc library in Python to create a simple IRC bot that listens to the channel and does the required I/O. Needed some code digging (because it’s not too — khm — well documented), for example to enable SSL connection for the bot part of the code (for using port 7070 on Freenode). In the end indeed “use the source, Luke!”, as they write and it worked out.

The I/O part needed to be parallelized too, there used some part of the multiprocessing library that I haven’t used before (Process), and some data sharing: the display can run and scroll the text, while the bot can notify the display’s process when it needs to show something new. Same for notifying the LED, when it needs to blink.

For doing different colours for the different usernames I use hashing: run the username through SHA256, and use the 1st, 2nd, 3rd bytes of the resulting has as Red/Green/Blue for the backlight colour.

Here’s the code in Python (2.x):

import hashlib
username = "MrEdison"
h = hashlib.sha256()
h.update(username)
ColorR = int(h.hexdigest()[0:2], 16)
ColorG = int(h.hexdigest()[2:4], 16)
ColorB = int(h.hexdigest()[4:6], 16)
# (ColorR, ColorG, ColorB) = (115, 126, 15) or #737EF

the result:

Works pretty well!

The bot’s settings (server name, port, channel, nickname) are all set through the Resin.io control panel as environment variables.

Environmental variables used at the moment:

• SERVER: the IRC server used, defaults to irc.freenet.net
• PORT: port used, has to be SSL-enabled, defaults to 6697
• CHANNEL: which channel to connect to, together with all the hashes, defaults to #mredison
• NICK: nick to choose, no authentication yet, defaults to mredison
• TIMEZONE: what timezone to display updates in standard tz database notation, defaults to UTC

This makes it quite flexible, can let the bot/setup monitor any channel on any network, though at the moment needs SSL-enabled server, but that’s easy enough to change if someone wants to run the code and don’t care about security… :P

For testing I was using mostly the #ubuntu and ##linux channels, as they seems to be pretty chatty!

Experience

It was a bit bumpy process, like most experimental works. First I’ve run into some Edison/Docker related strangeness that messed with the I/O. Solved by Shaun from Resin, the trick being needing to mount the debugfs before running my code, so the kernel can configure things correctly:

mount -t debugfs nodev /sys/kernel/debug

Edit (8/1): This in the end wasn’t enough, had to go back to the Edison GPIO Pin Muxing Guide, and turned their Example 4: Configure IO18/IO19 for I2C connectivity guide into a pretty hard core, but probably well commented bash script to set up I2C, which is called on start. Seems to work out!

There was also some issue with the bot timing out in a strange way and losing connection. I was about to rewrite the whole code in Node.js, but tried a quick client test first. Turns out that I was testing on port 6697 (which is I read the default SSL port), and that has some connection issues. After I’ve switched to 7070, all of that disappeared, and the connection seems pretty solid (no timeout so far).

There are some bugs that remain, though:

• Unicode handling is non-existent, so those posts can pretty much mess up the display
• There can be race conditions using the display, not the best threading code probably…
• At bootup, the LCD display is borked, but after adjusting the environment variables (without reboot), things sort themselves out! Maybe need to tweak the startup script and add some delay between the steps?

Otherwise it’s working pretty well, the colour changes are fun, the text is readable, so I guess mission is accomplished!

The source code is on Github, and to set up your own version of this, just create a new Edison project, flash the system, clone the source code and push it to your application, finally define the environment variables SERVER, PORT, CHANNEL, NICK as they are suitable for you, and enjoy!

Future

It would be probably good to create an enclosure for this setup, to hold the parts together more securely. Then drop it in the Hackerspace and set it up to listen to our IRC channel – and get chatting.

It’s probably unlikely that I’ll change much on it in the future, most I can think of is adding some more bells & whistles (or rather, literally a buzzer:), but that might be too much. The code works well enough, but pull requests are accepted!

I’m mostly just glad that the idea worked out, and the project is done. Now I can actually move onto another one (there are way too many projects on the waiting list, driving me nuts)….

What’s your take on IRC? Do you use it? Would this project be useful for you somehow?

This project is also written up on hackster.io.

The post A window to IRC with Edison and Resin appeared first on ClickedyClick.

1. Start a new application and download an image file for your chosen single board computer (1 of 5 choices at the moment: Raspberry Pi 1 & 2, Parallella, Intel Edison, and BeagleBone Black)
2. Flash the image onto an SD card, connect the board to the network, and boot it up
3. The board shows up in the cloud management console, and you get a git repo address
4. Make an application (Docker, Node.js, etc.), do a git push: voila, your board’s running your app
5. Flash a few more SD cards, connect the devices to the network, all of them will run your application
6. Modify the app behaviour through environment variables, either all of them at once, or customize each
7. Check status, logs, updates, online, and enjoy that things just work!

I cannot emphasise enough how good any service feels that 1) runs by git pushing code, and 2) just works.

SomaStream

To try it all out, I’ve put together a very simple application: SomaStream – the SomaFM internet radio streaming app.

Grabbed my RaspberryPi that didn’t do much lately, plugged an earphone in it, and started to look for some examples in the docs how to make it play some streaming music. 

In the end I’ve used a docker image, installed mplayer, and stated a shell script in the app to start playing the stream defined by the appropropriate environment variable. This makes it very reusable: if I use more than one board, using the same code all of them could play different SomaFM channels. Also added the cache size as a variable to deal with crappy internet connections without pushing new code to the board.

After git pushing the code, it compiles the image in about 7 minutes which is not too quick, but most of the time is spent in Raspbian package install (which is not a quick thing in itself). Then the image is downloaded to the board automatically (just like it’s on the way on the image above), and if everything went well, in a minute or so there’s music to my ears through the Pi’s headphones – and can see in the logs what is it playing at the moment like this:

This is a totally toy project, but still the outcome is useful and very enjoyable. The entire code from my side is about half a dozen lines altogether, here’s the somastream repository. Tried out most of the functionality of the system, and it enables me to think of more complex problems for which it might be a good solution.

Now, with a (little) job well done, hello Secret Agent (set CHANNEL to “secretagent130”) :)

The Future

I feel that this tool will breathe new life into my Raspberry Pi, because all the possible projects just got a lot more playful and interesting suddenly. The same goes for my Kickstarter Parallellas, since Resin.io powers their new Supercomputer.io, which I’m really looking forward to see in action (Computing and science? Sign me up!)

Also, in the Taipei Hackerspace we had a chat recently to set up a small rack for single board computers, so people can try a toy “datacenter”, having their “server” there. Our question at the time was, how deep people will want to go in the abstraction of server management – all the way to the bare metal managing a Linux distro, or stay on the level applications? Now with Resin, the second option is totally realistic. I can’t wait to discuss this with people in the ‘Space, and see what projects they’ll come up with!

According to the Hacker News discussion, the magic of this system is in part powered by Yocto-generated images, and any single board computer that has a Yocto layer and reasonably new kernel will be usable. I’m a Yocto novice, but this smells like the perfect use case for their philosophy: decoupling the hardware support and the actual operating system, so any recombination of the two still works. Talk about floodgates, how many boards I have idle here that someone already made a Yocto layer (and if there’s a board that does not have a layer, now’s the time…)

The post Magic for the Internet of Things: Resin.io appeared first on ClickedyClick.