Omatic Labs Zettelkasten

Ansible tasks for Mosquitto MQTT Broker

I've been playing with Ansible and recently had it installing Mosquitto.

It's a bit too trivial at the moment to turn into a fully fledged Ansible roll so I've just put a Gist here.

https://gist.github.com/justinatomatic/c2cf67a6c49bcdc8702e

It's only three tasks

# install mqtt broker
  - name: add mosquitto key
    apt_key: url=http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key state=present
  - name: add mosquitto repo
    apt_repository: repo='deb http://repo.mosquitto.org/debian wheezy main' state=present update_cache=yes
  - name: install mosquitto
    apt: name=mosquitto state=present

LIFX HTTP & Supervisor

Update

So it turns out it didn't work so well and after a day or two lifx-http becomes unresponsive. Also shortly after working on this LIFX 2.0 came out, breaking the current lifx-gem and introducing a cloud based http based API. I've since moved to using the lifx cloud API. Although I'm still interested in local nolin cloud communication with the LIFX bulbs.

Original article below

So I'm not a Ruby guy at all. My only current interest in Ruby is that the LIFX SDK and the LIFX HTTP API is written in Ruby.

The one other thing I'm doing in Ruby (without actually bothering to learn much Ruby outside of Stack Exchange driven development) is writing a bidirectional LIFX-MQTT bridge.

So I was playing around with trying to get Supervisor to run LIFX-HTTP. At some point I decided to upgrade my Ruby gems. Big mistake, this broke LIFX-HHTP and has lead me down a rabbit hole of Ruby gem version/dependancy management and the Ruby Version Manager (RVM).

Months ago when I was looking around to upgrade Ruby to version 2.0+ so i could run the LIFX gem I came across this page.

Ruby on Raspberry Pi

It seemed like an easy way to install Ruby on the Pi so I used that and it's worked well.

After upgrading my gems I discovered that lifx-http wasn't working. After reading through the Git Hub issues pages and trying a few things to no avail I decided that Rack version 1.6.0 was not playing well with lifx-http so the idea was to use RVM to move back to Rack 1.5.2

Once I started trying to use RVM to switch gemsets I started getting the apparently infamous "RVM is not a function" error.

With a bit of google I discovered that source ~/.rvm/scripts/rvm fixes the problem on the Raspberry Pi (raspbian). Put it it your .bashrc so it's loaded on every new shell.

To make a long story short, I created and new gemset, installed lifx-http, it automatically installed rack 1.6.0 so I uninstalled it and manually installed rack 1.5.2.

Cool lifx-http working again, back to supervisor.

RVM uses wrapper scripts to load the correct environment, as I'm very new to RVM the wrapper generation syntax was confusing me.

rvm wrapper ruby@gemset [scope] [binary-name]

so I found the cheats way.

rvm repair wrappers

This generates wrappers for all the installed gems.

With lifx-http working again and having generated the wrappers its just a matter of creating a config for supervisor. Here's what worked for me.

[program:lifx-http]
command=/home/justin/.rvm/gems/ruby-2.1.2@rack_1.5.2/wrappers/lifx-http
directory=/home/justin/lexx
stdout_logfile=/home/justin/lexx/log_lifx-http.txt
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=1
redirect_stderr=true

So now I have lifx-http working under supervisor which is a great improvement over running it in a screen session.

lifx-http                        RUNNING    pid 3660, uptime 1 day, 5:06:12
wemo                             RUNNING    pid 2080, uptime 1 day, 5:44:22
supervisor>

Raspberry Pi screen blanking

So by default when booted into X Windows the Raspberry Pi will blank its screen after 10 minutes of inactivity.

This isn’t so good for museum exhibition machines that need to show content all day.

If you google on the topic of raspberry pi screen blanking you get about half a dozen different suggestions to fix it with settings changes in a bunch of different files.

Only one thing worked for me.

The highest ranked answer here disable-screen-blanking-in-x-windows-on-raspbian

Involves editing /etc/X11/xinit/xinitrc

and adding three xset commands

xset s off         # don't activate screensaver
xset -dpms         # disable DPMS (Energy Star) features.
xset s noblank     # don't blank the video device

The trick here is that xset might not be installed.

Try an xset command on the command line to see if xset in installed.

If it’s not installed you can install it with.

sudo apt-get install x11-xserver-utils

Prototyping boards for SparkCore

I've been using my SparkCore's a lot for a variety of projects, One thing I've wanted was a simple prototyping board for the SparkCore, as there wasn't one available I decided to make one.

I've designed this prototyping shield for those small projects with just a few components and keeping it small just like the SparkCore.

Available on Tindie now

Comes with female headers so you can easily attach and remove you core from the protoboard.

Each SparkCore pin is connected to the hole on either side, so you have one spot for each pin inside the prototyping area and one on the outside of the core for connecting to external components.
There are additional connected pins for GND, VIN & 3V3
Clear labelling on both sides
Mounting holes

SparkCore in photoes not included for illustrative purposes only

Wireless Smarthome Buttons

I’ve posted a project up to hackaday.io and submitted it to the hack a day prize competition. Its something I’ve been working for a while (fairly slowly) its title for the purposes of the hack a day competition is “Wireless Smarthome Buttons” but that name is less than ideal and I really need a better one. Anyway ..

It’s a wireless 2x2 button pad backlit by RGB LED’s, it can be used for controlling any other connected device or project. However my intended usage is controlling smart home devices.

Firmware on the device is pretty simple it uses the MQTT protocol and publishes the press of the buttons to MQTT topics and subscribes to other topics that tells it what colour the LED’s should be. This way the the press of the buttons is disconnected from the illumination of the LED’s. This separation takes its inspiration from the Monome project. The most obvious use case here is the LED’s can be used for notifications as well as indicating button presses or device states.

In the current version the backend is run by some Python code on a Raspberry Pi. I’m currently controlling Lifx lamps using the magicmonkey NoteJS MQTT bridge but I’m thinking of writing my own Lifx MQTT bridge in Ruby.

I’ll be publishing more details and code in the coming weeks to my project on hackaday projects. Check it out.

links