Skip to content
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 Paspberry 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.
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.

Guides:

  • 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 remotestick-server.py 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.
March 16, 2013 / lasseathome

Kickstarting Raspberry Pi

I recently invested in my first Raspberry Pi device and this is my story of how I it started it the first time. The things that were available:
Raspberry Pi, USB keyboard and mouse, SanDisk SDHC Ultra Secure Digital memory card, a Linux laptop with SD card reader.

  1. Downloaded the disk image from the site http://www.raspberrypi.org/downloads
  2. Unzipped the image file.
  3. Inserted my 8GB flash card, and located it to reside in /dev/mmcblk0p1
  4. Started the shell command line and did my
    > sudo bash
    to get root privileges for doing dd.
  5. Downloaded the image to the flash card (note that the last letter and number for the device need to be removed from that which was identified above).
    > dd bs=1M if=2013-02-09-wheezy-raspbian.img of=/dev/mmcblk0
  6. Inserted the SD card in Raspberry Pi, together with USB keyboard & mouse, HDMI cable.
  7. Started it and configured it with languages, ssh server on, changed the default password, etc.

Wheeha, now it is up and running. This was a really nice piece of thing, so now it is time to do some fun stuff.

Follow

Get every new post delivered to your Inbox.