Skip to content
July 23, 2015 / lasseathome

Configuring WEP2 based WiFi network from command line on Raspberry Pi

This is what I did to get the WiFi config to work for my raspberry pi. I have a USB network card that is OK according to and I have a D-LINK DWA-121 USB dongle which should work out of the box with my Raspberry Pi  and Raspberry Pi 2 B. I insert into the system and double check that all is OK with the detection:

pi@RPi-2B ~ $ lsusb
 Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
 Bus 001 Device 004: ID 2001:3308 D-Link Corp. DWA-121 802.11n Wireless N 150 Pico Adapter [Realtek RTL8188CUS]
 Bus 001 Device 005: ID 1d57:32da Xenta 2.4GHz Receiver (Keyboard and Mouse)

At row 4 it is seen that this dongle is detected OK. Then I check that the basic network is OK to be configured by analyzing the “interfaces” file.

pi@RPi-2B ~ $ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

auto wlan1
allow-hotplug wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Here there is a choice one option is to put the wpa configuration in the file /etc/network/interfaces and the other is to put it in the /etc/wpa_supplicant/wpa_supplicant.conf file I selected the latter. In this case the things necessary to enter in this file are the lines after row 3 in “spa_supplicant.conf”, my file reads:

pi@RPi-2B ~ $ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev


Then i shut down the interface and restart it with the :

pi@RPi-2B ~ $ sudo ifdown wlan0
pi@RPi-2B ~ $ sudo ifup wlan0

There is an error message which is seemingly standard, but I can now check that my WiFi network is up and running. I check with:

pi@RPi-2B ~ $ ifconfig 
... irrelevant output removed...
wlan0     Link encap:Ethernet  HWaddr bc:f6:85:e7:40:0e  
          inet addr:  Bcast:  Mask:
          RX packets:1301 errors:0 dropped:99 overruns:0 frame:0
          TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:263812 (257.6 KiB)  TX bytes:58604 (57.2 KiB)

that shows that the wlan0 interface has the right local IP, so the RPi-2B WiFi card is up and running…

October 25, 2014 / lasseathome

Setting up OpenVPN on a Tomato router with Tunnelblick as client

On many occasions I want to access my computers and servers behind my firewall and the normal solution was to have only the ssh port open and then work on the command line with the machines inside. A better solution is to set up a VPN and connect to it, but I though for a long time that it was too difficult as it seemd to be so much of a threshold. I have now gone into that endeavor and it was not too hard and this documents my steps. My hardware is:

  • OpenVPN Server – An ASUS RT-N16 router with Tomato by Shibby, using K26-RT-N5x-AIO (all in one) image.
  • OpenVPN Client – Mac book where I have installed the Tunnelblick-Client and run the key generation scripts.

Starting up

Prerequisites are installing Tomato on the ASUS RT-N16. Downloading and installing Tunnelblick client on the Mac. It is good to install the Tunnelblick client before the server is finished since the keys can be generated with the easy-rsa utility included with it. I guess any other OpenVPN client also includes easy-rsa.

Setting up OpenVPN on the router

In VPN Tunneling > OpenVPN Server > Basic Tab


In VPN Tunneling > OpenVPN Server > Advanced Tab


Generating keys for the OpenVPN Keys tab

This is where we use the fact that we are on a mac with Tunnelblick installed, since Tunnelblick brings easy-rsa in its package, we go to tunnelblick’s easy-rsa folder and edit the configuration file called “vars”. We need to “sudo edit vars” the file since root is the owner to the directory. Read README and Google helped me to understand what to write in the file. (after starting Tunnelblick I saw that in Tunnelblick’s utilities tab one can open easy-rss in a terminal directly.)

cd /Applications/
sudo nano vars

Now we can start to generate some keys I followed the order according to the last lines in the README. Does a sudo bash since all commands needs to be done with root permissions in the directory.

sudo bash
export ./vars
./pkitool --initca
./pkitool --server mysever
./build-key client

This gives the following files, placed in the subdirectory keys: dh1024.pem, ca.key, ca.crt, myserver.crt, myserver.csr, myserver.key, client.crt, client.csr, client.key, and some other files. The file ca.key is private and must be stored in a safe place. The contents of these files are entered into the Tomato according to the following template:


This was the most difficult things to do, but it was not so difficult as I thought a few weeks ago.

Setting up the Client

The startup of Tunnelblick generated a directory with a sample config file for me, “config.ovpn“, that I edited and then I added the ca.crt file and my client files client.crt and client.key, to the same directory. After that I just double clicked on the config.ovpn which starts Tunnelblick and loads this configuration file, as well as the other files. I selected to install this for my user only and not all users on the machine.

As a final comment, added after the main publication of the post, I can now confirm that it works well. I could sit in China and read and post on my Facebook account and I could also Google on the Swedish and American servers, which was not possible without the VPN connection due to the net filters active in China.


The following places were the main sources for this set up procedure and installation.

  1. OpenVPN Documentation.
  2. The blog by Maciej Mensfield, with essentially the same information as here but with a different path for generating keys and others.
  3. The README file in the directory for the easy-rsa included in the installation.
December 28, 2013 / lasseathome

Decoding NEXA remotes with TellStick Duo

This is an investigation that I have done in order to decode my remote controllers. The purpose is to understand the remote so that I later can control, supervise, and synchronize my switches inside the house when using my TellStick Duo on my Raspberry Pi. In particular I want my Raspberry Pi to be aware of the button presses on my remotes

The remotes that were tested and read.

The remotes that were tested and decoded.

Prerequisites – Hardware/software

Hardware is a TellStick Duo with two different NEXA remotes and one prove, shown in the image above and detailed in the list below.

  • NEXA NEYCT-705, normal remote with 10 buttons (four groups with on and off buttons and one general pair on/off button) and a group switch that allows to switch between four groups.
  • NEXA KCT-510, small keyring remote, with one pair of buttons marked 1 and 0.
  • proove EVT0006, 8 buttons divided into 4 groups with on and off (the first three are numbered 1-3 and the last group has black buttons and is labelled G).

On the software side there is the

  • telldus-core packages and
  • the nice python wrappers with
  • During the decoding and development I run this on a Linux Mint box, but this description is generic and it could be performed on RPi, Mac or Windows systems too.

The installation and setup is shown in a previous blog.

Decoding the KCT-510

This is the decoding of the signal from the small key ring remote control. On the selector at the back the remote is set to house A and unit 1. To do the decoding I run the following command in the command line and then press the button 1 and 0 on the remote. The results show that the remote sends the same message 7 times for each button press. The tdtool software recognizes both an arctech and waveman from it, with house A and unit 1 as it is set, it also seems to detect a sartano switch too.

> python -t
+++++   The two lines above are repeated in total 7 times ++++
+++++   The two lines above are repeated in total 7 times ++++

The sending is not consistent between on and off. When turning on there is waveman interleaved with arctec and at turning off there is sartano interleaved with arctec. This is not consistent and I have no supported hypothesis but one unsupported hypthesis about the reason. The commands sent arrive very tight in time and all are not properly received and handled so that all of them do not reach the python callback script and in the end the output.

Anyway I now know how I can use the configuration file telldus.conf to supervise and detect the usage of the keychain remote.

Decoding the NEYCT-705

Now I apply the same command python -t and decode the NEYCT-705.

++++ Above transmitted 5 times ++++

++++ Above transmitted 5 times ++++
  • For every keypress it emitts 5 messages. The messages are interleaving with model names: arctec, sartano, and everflorish.
  • The message which is most important for the NEXA system is the arctech:
    This shows the house code the unit code and the group information that later will go into the telldus.conf file.
  • Further button presses reveals the following
    • All normal buttons have group:0, the unit goes from 1 to 16. With the switch in position I the unit goes from 1 to 4, with position II unit goes from 5 to 8, etc.
    • The special G buttons have group:1 and unit:1.

Decoding the proove EWT0006

The same command python -t is applied to decode the proove EWT0006. The following sequence of commands are received by first pressing the on button and then the off button. All groups are also traversed to go the the G.

+++ The lines above are repeated 6 times +++

+++ The lines above are repeated 6 times +++
  • Every button press gives 6 messages, with arctec, waveman, and everflourish interleaved.
  • The most important part for controlling NEXA switches is:
  • The button presses result in the following.
    • Buttons numbered 1 (on and off) are connected to unit 16, buttons numbered 2 to unit 15, and 3 to 14. All of these have group 0.
    • Buttons at position 4, labelled G, are connected to unit 16 but with group 1.

Synchronizing the remote and tdtool

The telldus-core software synchronizes out of the box with the remote as long as the configuration file and the remote are consistent. Based on the information above it is now easy to build the telldus.conf file so that the tdtool and other software is in sync with the remote control.

device {
  id = 1
  name = "I-1: Kitchen"
  protocol = "arctech"
  model = "selflearning-switch"
  parameters {
    house = "1642810"
    unit = "1"
device {
  id = 2
  name = "I-2: Bedroom"
  protocol = "arctech"
  model = "selflearning-switch"
  parameters {
    house = "1642810"
    unit = "2"
device {
  id = 5
  name = "II-1: Dimmer"
  protocol = "arctech"
  model = "selflearning-dimmer"
  parameters {
    house = "1642810"
    unit = "5"
device {
  id = 100
  name = "Outdoor"
  protocol = "arctech"
  model = "codeswitch"
  parameters {
    house = "A"
    unit = "1"

With this I am now able to control the switches with the remotes and have my telldus system in sync with the rest of the system. One reason for doing all this is that I can now see the status of the NEXA switches in my small web application where I also can control the switches.

December 26, 2013 / lasseathome

Music players on Raspberry Pi

List of players

I have been using squeezebox for a while and have several players but I would like to add a Raspberry Pi software player to the list. What I want is both to have individual and synchronized play in several rooms and since I have already invested in several squeezebox players this was the path forward. Now with the monitors (read TV) I do also in some cases want to have a media and video player that integrate with my squeezebox server and music. To make a decision on what platform to test and run I found several options around the web and to get some structure to my own thinking I compiled the following list with players, raspberry Pi distributions, and some facts about general frameworks for audio and video. As always I make it public for anyone to read in the hope that you will find it useful.


  • SqueezeSlave is a software music player that allows you to play misc steamed from Squeezebox Server and SqueezeNetwork.
  • Squeezelite is a small headless (no keyboard or display) squeezebox emulator for linux using alsa audio output.
  • SqueezePlay, SoftSqueeze – Software players, in my opinion these are old.


  • Pi MusicBox – Small distribution (about 1GB 2013-12-26) with spotify server based on Mopidy. Browser interface with MPD-client (Music Player Daemon). AirTunes/AirPlay streaming.
  • piCorePlayer – Minimalist RPi distribution with Squeezelite as player.
  • SqueezePlug – Distribution for RPi (and other) with media server and player.


  • Mopidy is a music server which can play music both from multiple sources, like your local hard drive, radio streams, and from Spotify and SoundCloud. Searches combines results from all music sources, and you can mix tracks from all sources in your play queue. Your playlists from Spotify or SoundCloud are also available for use.
  • MPD (Music Player Daemon). There are many MBD-clients that can control an MPD.
August 12, 2013 / lasseathome

Installing telldus-core on Raspberry Pi

This blog entry is about my installation of telldus-core on Raspberry Pi where the aim is to be able to read temperature sensor values. It relies on a Raspberry Pi with the Raspbian “wheezy” distribution, this comes from my Kickstarting the Raspberry Pi. The order of the commands are much the same as the excellent Swedish blog [1] listed below.

1. Make Telldus sources available to the distribution

# I always work in a dedicated Src directory when compiling things...
cd Src;mkdir telldus-core;cd telldus-core
# Make Telldus sources available to the distribution
sudo nano /etc/apt/sources.list.d/telldus.list
# Add the line:
# deb-src stable main
# Make key available and update package information.
sudo apt-key add telldus-public.key
rm telldus-public.key
sudo apt-get update

2. Install needed packages, compile from source, and install

sudo apt-get install build-essential  # already installed 
sudo apt-get build-dep telldus-core
# This fetched the following packages
# debhelper gettext html2text intltool-debian libgettextpo0 libunisting0 po-debconf

# Install other needed packages
sudo apt-get install cmake libconfuse-dev libftdi-dev help2man

# Download sources and compile
sudo apt-get --compile source telldus-core

# Install the three packages: libtelldus-core2 telldus-core libtelldus-core-dev
sudo dpkg --install *.deb
# Clean up
cd ..;rm -Rf telldus-core

3. Make a test run

Plug in the device and watch that lsub gives the desired behavior.

# Check that the device got connected
Bus 001 Device 008: ID 1781:0c31 Multiple Vendors Telldus TellStick Duo
# First test run with tdtool
tdtool --help
tdtool -l

As through magic I am now able to see the temperature sensors with the list command. Doing some tests to push the remote control to see that the Tellstick Duo blinks and that I can control my devices with it. No switch is connected to my configuration so I will need to add some information to the configuration file /etc/tellstick.conf. A good source is the Telldus Developer instructions for tellstick.conf, and as always another possibility is to take inspiration from a configuration from the internet, see for example [1] below or this little example with a Nexa-switch and a Nexa-dimmer.

deviceNode = "/dev/tellstick"
device {
    id = 1
    name = "Switch 1"
    protocol = "arctech"
    model = "selflearning-switch"
    parameters {
        house = "950"
        unit = "1"
device {
    id = 101 
    name = "Dimmer"
    protocol = "arctech"
    model = "selflearning-dimmer"
    parameters {
        house = "950"
        unit = "2"

4. Extracting received events from the TellStick Duo

There are possibilities to receive data from the libtelldus-core libraries, and there are four callback methods available in the Telldus Core API, which is documented on the Telldus developer site. The documentation has C function examples to send commands and receiving callbacks when events occur and to complement this there is also a couple of python scripts that illustrates how the libraries can be interfaced from python.

The following example is a script that is based on the pytelldus and uses the The script registers a callback for sensor events, extracts the sensor readings and prints all information to one line. The main thought is to provide a compact but human readable format for logging sensor data. The code is

# file:
import td
import time
def logSensorEvent(protocol, model, id, dataType, value, timestamp, callbackId):
    # print a line for each event with time, sensor id, data type, value, protocoll, and model
    print '%s,%d,%d,%s,%s,%s' %(time.strftime("%Y-%m-%d,%H:%M:%S"), id, dataType, value, protocol, model)
if __name__ == '__main__':
    # Intialize the communcation
    td.init( defaultMethods = td.TELLSTICK_TURNON | td.TELLSTICK_TURNOFF )
    # Register callbacks
    callbackId = []
    # Run infinite loop
    except KeyboardInterrupt:
        for i in callbackId:
            # De-register callbacks
    # Close communication so telldus-core can do some cleanup.
## End

When the python script is run it generates the following output. The function is quit by pressing Ctrl-C.

~/Src/pytelldus $ python

This output is easily piped to a log file that can be read, analyzed and presented with plotting commands at a later stage. This service is currently running on the Raspberry Pi, to a separate hard disk.

This concludes my struggle to get a simple solution to log temperatures inside and outside the house.


  1. Swedish blog “IT teknikerns vardag” on installation of software on Raspberry Pi. Installs deb-src for telldus-core and compiles from scratch.
  2. Telldus Technologies developer site.
August 10, 2013 / lasseathome

Information on temperature logging with Raspberry Pi, Telldus.

This is a compilation of links and facts that I collected while researching the Raspberry Pi, Tellstick Duo, and how to store temperature sensor information. As always it is mostly for myself and put into the open if someone else might find it useful. A good starting place to find information is at Telldus forum, and Raspberry Pi site.

Software for Linux:

  • telldus-core, Telldus drivers for a unix based system.
  • TelldusCenter, telldus-gui simple gui for configuring the devices.
  • remotestick-server, Python scripts that use telldus-core.
  • tellprox, Python scripts based on Remotestick server.
  • HomeAutomation, Web interface for TellStick. PHP and MySQL.
  • NexaHome, Java based system. Uses Telldus Center for configuration.
  • SwitchKing, C# or mono based software with iPhone app.
  • VSCP, Protocol for IoT and other things that support Tellstick.

Remote controllers:

  • Remote stick, Android based controller uses Telldus Live.
  • TellEvent, iOs application.

Temperature sensors:

For my own notes I have: Oregon Scientific and Viking sensor with display.


  • Compiling telldus-core from source on the Raspberry Pi.
  • Compiling and installing, a swedish blog with a good guide to installation of telldus-core and on a on R-Pi. (Only control no sensors.)
May 18, 2013 / lasseathome

Print Screen to Desktop and Clipboard on Mac

There are several ways to do print screen on a Mac and I always have problem of remembering them, so I decided to store them on the blog for my own convenience.

Print to desktop:

  • Apple key ⌘ + Shift + 3 : Print full screen.
  • Apple key ⌘ + Shift + 4 (+ mark region with mouse) :  Print a selection of the screen.
  • Apple key ⌘ + Shift + 4 (+ space bar + click a window) : Print a window to the desktop.

Print to clipboard:

  • Apple key ⌘ + Ctrl + Shift + 3 : Print full screen.
  • Apple key ⌘ + Ctrl + Shift + 4 (+ mark region with mouse) :  Print a selection of the screen.
  • Apple key ⌘ + Ctrl + Shift + 4 (+ space bar + click a window) : Print a window to the desktop.

Get every new post delivered to your Inbox.