Skip to content
November 24, 2016 / lasseathome

Formatting a drive bigger than 2TB in Linux

I recently installed a big disk into my calculation server but could not format it with the gparted GUI. The main problem is that gparted and other tools use fdisk that cannot format drives larger than 2TB, and I wanted to add a 3 TB disk to my calculation server to store data and development code. I had to Google some solutions and found that this can be overcome by using GNU parted command using a partition table of type Intel EFI/GPT. Where the latter comes from the globally unique identifier (GUID) for the EFI System partition and uses information stored in the GUID Partition Table (GPT). EFI uses GPT where BIOS uses a Master Boot Record (MBR). There are plenty of other posts that contain the same essence, but I want to keep some commands readily available for myself so I once again post the commands I have used and want to remember, in the hope that others might find them useful.

The essence of the procedure is to identify the drive letter with lsblk, run parted to create a gpt table and a primary partition, format the drive with mkfs.ext4, and find the GUID with blkid so it can be stored in the /etc/fstab for automatic mounting. The command sequence is:

$ lsblk     # find drive name
$ sudo parted /dev/sdc # start parted
# the rest is in parted's interactive shell
(parted) mklabel gpt
(parted) unit TB
(parted) mkpart primary 0.0TB 2.7TB
(parted) quit
$ sudo mkfs.ext4 /dev/sdc1
$ sudo tune2fs -m 1 /dev/sdc1
$ sudo blkid     # Identify the drive GUID
$ sudo mkdir /Data
$ sudo nano /etc/fstab
# In fstab place the line
UUID=d18b6e08-d82d-4581-8445-8a463e1043fd /Data ext4 defaults 1 2
$ mount /Data

Now the 3TB drive is mounted in data, and I have a sandbox to play in.

July 24, 2015 / lasseathome

Avoid Killing SD Card on Raspberry Pi

Having read that there is a risk of killing the SD card with a lot of writes caused me to set up a system so that it writes the big log files and data to a normal hard drive while keeping the regular and important system information on the SD card. The reason is that I have a temperature logger based on Telldus Tellstick Duo that listens to sensor events on the 433 MHz band and writes temperature log data several times a minute. This could, according to reports and discussions on the internet, cause a burn out of the solid state card, I do not know if the risk is real for my case but I often reason it’s better to be safe than sorry. I did it three years ago on my first RPi but did not write down the procedure so here I go again documenting for anyone who is interested at the same time as I do it for my new RPi 2B. This is the hardware that I have:

  1. Rapberry Pi 2 B.
  2. External USB harddrive.
  3. USB hub with power adapter.
  4. Telldus Tellstick Duo (not important for this).
  5. A 7-port USB hub with power supply 5V 2.5A that powers the Raspberry Pi, Tellstick Duo, and USB hard drive.
  6. For completeness I also have a WiFi network adapter DWA-121 and wireless integrated keyboard/trackpad the dogles for these are connected directly to the RPi (not important for this).
  7. A separate laptop with Ubuntu Mate with SD card reader and USB connectors.

The additional USB hub (5) with external power source was necessary to get enough power for the USB hard drive to startup.

Starting up

Downloaded Raspbian Jessie via torrent and wrote it to the card using the Ubuntu laptop. Identified the device for the SD card with df and removed the additional letters and wrote the image with dd

df -h
# output ... 
# /dev/mmcblk0p3   27M  444K   25M   2% /media/SETTINGS
# /dev/mmcblk0p6  6,3G  2,6G  3,5G  43% /media/root
# /dev/mmcblk0p5   60M   19M   42M  32% /media/boot1
sudo dd bs=4M if=2015-11-21-raspbian-jessie.img of=/dev/mmcblk0

Booted up the RPi. The first and most important thing: Added password to user pi.
Then: Changed locale, changed keyboard, grew the file system. Reboot, run an update and an upgrade, and installed emacs and prepared the keyboard for swap Caps & Ctrl.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install emacs
cd /etc/default/
sudo nano keyboard
# added options XKBOPTIONS="...,ctrl:swapcaps"

Now I have a base system that will give me a basic working configuration so I can start working with the file system.

Placing /var/ on the external USB disk

Now it is time to get down to the more serious business that can do damage to the system so I work with the file system off-line on a separate machine to it up. I shut down the RPi and inserted the USB HDD drive and SD card in the Linux Laptop. In short the core idea is to place all the data in /var on the USB HDD. This is done with the motive that the files that change the most are placed in the /var/ area in unix systems. For example the log files, the www files, the database data, etc. Therefore I intend to place the USB HDD there, with the intention to have all my file sharing and data stored there. So I attached the USB HDD to the Linux machine and did the following.

  1. Formatted the HDD to an ext4 system using gparted on the linux machine, and gave it label VAR.
  2. Went to the directory of the memory card that contain the root partition and into /SDCardMountPath/etc/
  3. Added a line to the fstab file, extracted the UUID of the disk using blkid.
    sudo emacs fstab&
    blkid
    #output
    # ...
    # /dev/sdb1: LABEL="VAR" UUID="87f1540c-dac0-4911-98c1-1a23666cafed" TYPE="ext4" PARTUUID="439c27a4-01"
    # the resulting line for /etc/fstab was then
    # UUID=87f1540c-dac0-4911-98c1-1a23666cafed /var               ext4    errors=remount-ro 0       1
    
  4. Moved all data from the card’s /var/ directory to the HDD
    cd /SDCardMountPath/var/
    sudo mv * /HDDMountPath/

    This took some time to complete.

  5. Double checked that the /SDCardMountPath/var/ directory was empty after the move so that a file system can be mounted there at next RPi boot.
  6. Ran sync;sync to sync the filesystems and unmounted and removed them from the Laptop.
  7. Inserted the card in the RPi and the USB HDD in the USB hub. Booted up the RPi. At boot an fschk was run and all worked fine so the RPi 2 B is up with the HDD mounted at /var/, ready to be filled.

Now I have a system where /var/ is stored on a HDD that can tolerate more writes than an SSD disk can, so I can safely log Gigabytes of data. For curiosity I can inform the interested reader that I started logging with my first Raspberry Pi 1 B, with a similar setup to an USB Disk, in August 2013 and the data is now in January 2016, 640 MB, and there is not yet any problem with the RPi and SC card.

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 http://elinux.org/RPi_USB_Wi-Fi_Adapters 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
update_config=1

network={
        ssid="MY_SSID"
        psk="MY_WPA_PWD"
        key_mgmt=WPA-PSK
        pairwise=CCMP
        auth_alg=OPEN
}

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:192.168.0.32  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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 192.168.0.32, 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

OpenVPN-1

In VPN Tunneling > OpenVPN Server > Advanced Tab

OpenVPN-2

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/Tunnelblick.app/Contents/Resources/easy-rsa-tunnelblick
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
./clean-all
./build-dh
./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:

OpenVPN-3

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.

References

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 tdtool.py with td.py.
  • 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 tdtool.py -t
protocol:arctech;model:codeswitch;house:A;unit:1;method:turnon;
protocol:waveman;model:codeswitch;house:A;unit:1;method:turnon;
+++++   The two lines above are repeated in total 7 times ++++
protocol:arctech;model:codeswitch;house:A;unit:1;method:turnoff;
protocol:sartano;model:codeswitch;code:1111111110;method:turnoff;
+++++   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 tdtool.py -t and decode the NEYCT-705.

protocol:arctech;model:selflearning;house:1642810;unit:1;group:0;method:turnon;
protocol:sartano;model:codeswitch;code:1111011010;method:turnon;
protocol:everflourish;model:selflearning;house:8210;unit:3;method:turnoff;
++++ Above transmitted 5 times ++++

protocol:arctech;model:selflearning;house:1642810;unit:1;group:0;method:turnoff;
protocol:sartano;model:codeswitch;code:1111111010;method:turnon;
protocol:everflourish;model:selflearning;house:8210;unit:3;method:turnoff;
++++ 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:
    protocol:arctech;model:selflearning;
    house:1642810;unit:1;group:0;method:turnon;
    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 tdtool.py -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.

protocol:arctech;model:selflearning;house:30891002;unit:16;group:0;method:turnon;
protocol:waveman;model:codeswitch;house:P;unit:10;method:turnon;
protocol:everflourish;model:selflearning;house:13759;unit:3;method:turnon;
+++ The lines above are repeated 6 times +++

protocol:arctech;model:selflearning;house:30891002;unit:16;group:0;method:turnoff;
protocol:waveman;model:codeswitch;house:P;unit:9;method:turnon;
protocol:everflourish;model:selflearning;house:13759;unit:3;method:turnon;
+++ 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:
    protocol:arctech;model:selflearning;
    house:30891002;unit:16;group:0;method:turnon;
  • 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.

Players

  • 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.

Distributions

  • 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.

Frameworks

  • 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 http://download.telldus.com/debian/ stable main
# Make key available and update package information.
wget http://download.telldus.se/debian/telldus-public.key
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
lsusb
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 td.py. 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: logger.py
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 = []
    callbackId.append(td.registerSensorEvent(logSensorEvent))
    # Run infinite loop
    try:
        while(1):
        time.sleep(1)
    except KeyboardInterrupt:
        for i in callbackId:
            # De-register callbacks
            td.unregisterCallback(i)
    # Close communication so telldus-core can do some cleanup.
    td.close()
## End logger.py

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

~/Src/pytelldus $ python logger.py
2013-08-12,22:49:37,159,1,24.3,fineoffset,temperature
2013-08-12,22:49:38,158,1,23.3,fineoffset,temperature
2013-08-12,22:49:45,140,1,12.7,oregon,1A2D
2013-08-12,22:49:45,140,1,12.7,oregon,1A2D
2013-08-12,22:49:59,138,1,24.9,fineoffset,temperature
2013-08-12,22:50:16,21,1,25.4,mandolyn,temperaturehumidity
2013-08-12,22:50:16,21,2,50,mandolyn,temperaturehumidity
2013-08-12,22:50:17,21,1,25.5,mandolyn,temperaturehumidity
2013-08-12,22:50:17,21,2,50,mandolyn,temperaturehumidity
2013-08-12,22:50:17,21,1,25.5,mandolyn,temperaturehumidity
2013-08-12,22:50:17,21,2,50,mandolyn,temperaturehumidity
2013-08-12,22:50:24,140,1,12.7,oregon,1A2D
2013-08-12,22:50:25,159,1,24.3,fineoffset,temperature
2013-08-12,22:50:26,158,1,23.3,fineoffset,temperature

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.

Sources

  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.