Digital Picture Frame as a router status display

A 320x240 cheap (2,90€ by pearl.de) digital picture frame attached to a router is a very useful addition to show router's status information. The DPF display driver is already integrated into the lcd4linux project that makes it easy to use the frame. This for example is how it works for me:

Some details regarding DPF hacking can be found here (the page is in German)

Although lcd4linux is a powerful tool I'm still looking for a way to build complex dynamic menu structures to be able to control MPD from my remote, i.g to be able to navigate visually through the MPD database and select items into the playlist. And it seems like the lcd4linux is not powerful enough to do such things. I'll add some additional notes if I find a solution.

Update: my lcd4linux.conf for this layout is here
Update2: the digit's font is Impact, 48 points
Update3: I was asked to add some info about weather parsing

Well, first of all I have a script that is called when WAN interface goes up:

A simple bash IRC logging bot

Couple of years ago I googled for a simple bash IRC logging bot that I could start on my router to log some channels. I've found a very simple script that worked but didn't handle PINGs from the server. So I extended it a bit trying to keep it as simple as possible.

Encrypting with the openssl in bash

With a bit of commandlinefu it becomes easy to encrypt and decrypt files with the strong 256 bit aes algorithm using openssl.

Add the following into your ~/.bashrc

# crypting functions
function encrypt {
  if [ -t 0 ]; then
    # interactive
    local fname="$1"
    shift
    openssl aes-256-cbc -salt -in "$fname" -out "${fname}.enc" $@
  else
    # piped
    perl -e 'use IO::Select; $ready=IO::Select->new(STDIN)->can_read();'
    openssl aes-256-cbc -salt $@
  fi
}
function decrypt {
  if [ -t 0 ]; then
    # interactive
    local fname="$1"
    shift
    openssl aes-256-cbc -d -in "$fname" -out "${fname%\.*}" $@
  else
    perl -e 'use IO::Select; $ready=IO::Select->new(STDIN)->can_read();'
    openssl aes-256-cbc -d $@
  fi
}

and source it to let changes take effect (source ~/.bashrc).

collectd-mod-exec Part 5

Part 1
Part 2
Part 3
Part 4

In this final part I'm publishing a real world example of the collectd-exec usage - weather info collecting script.
I'm using yahoo weather api to get weather information because it sends back very concise xml formatted text file which is only 2k in size. The weather info is updated once per hour so I've added special logic to retrieve it once per hour and feed same values in between.

collectd-mod-exec Part 4

Part 1
Part 2
Part 3

There is only one thing left to explain - how to get notified if some values go out of scope. As an example I'm going to send notification emails if CPU temperature reaches 57 degree Celsius. This could be implemented with only one additional if statement and this would work perfectly if I only had one script that sends notifications. It would become cumbersome if I needed to edit multiple scripts to change say an email address where my notifications are sent. In other words the collecting and notification logics shall be separated. To  do this one can use 'PUTNOTIF' statement that shall be sent to the script STDOUT - exactly the same way like 'PUTVAL' is sent. Documentation of the 'PUTNOTIF' arguments can be found on the collect-exec module documentation page. Additionally there shall be some logic added to send notification after some time out period otherwise emails would be sent after each $COLLECTD_INTERVAL which is by default 30 seconds. Updated tmpcollect.sh script is shown below:

collectd-mod-exec Part 3

Part1
Part2

I'll continue with the tmpcollect.sh script from the second part of this How-To. First of all I want to optimize it a bit. Running sed two times is not very performant and is also not necessary. Updated script is shown below:

collectd-mod-exec Part 2

Part1

My router SBC is equipped with two temperature sensors to monitor cpu and board temperatures. Executing 'sensors' command produces the following result:

root@Alix:~# sensors
lm86-i2c-0-4c
Adapter: CS5536 ACB0
temp1:       +36.0 C  (low  =  +0.0 C, high = +70.0 C)
                      (crit = +85.0 C, hyst = +75.0 C)
temp2:       +42.5 C  (low  =  +0.0 C, high = +70.0 C)
                      (crit = +85.0 C, hyst = +75.0 C)

With a bit of the script-fu I'm stripping temperature values and feeding them into the database:

collectd-mod-exec Part 1

Having some spare time I decided to write about powerful yet not well documented feature of the OpenWRT's luci-app-statistics plugin -- collectd-mod-exec module. This module allows collecting any type of data an external application could supply. In other words the module starts a user specified application which feeds collectd module with data. Principally having this module installed one could simulate all other collectd-mod-* modules.

IR control for your router

There are no buttons on my router but very often I need to start some task without accessing the shell. For example I want to switch wireless interface off if I don't need it and the problem here is that I cannot switch it on again wirelessly because wireless interface is off. So I thought I need some kind of a one button USB keyboard or mouse but there is no such thing. Second thought was to use some kind of IR receiver with a remote control. As far as I already have a universal remote control Logitech Harmony 885 I only needed an IR receiver that is supported by Linux. So I bought one manufactured by TechniSat for 15,20Euro with delivery (just google for - TechniSat USB IR receiver)

AVCLan (IEBus) sniffer and device emulator project

Purpose: to be able to simulate different devices attached to the IEBus.

Toyota uses the IEBus standard for internal equipment to communicate. As far as it is almost impossible to buy the IEBus driver IC it is possible to simulate it on a uController. The uController shall be fast enough to process the bus signal impulses that are less then 3 uSec. And at the same time the uController shall be fast enough to send received and processed data to the host computer in less then 120-130 uSec so the next message on the bus is not lost.

The uController of choice is pic18f2550. It contains the USB 2.0 module which supports full speed communication mode and can principally work up to 48MHz. It also contain 2 internal comparators that can be used to receive signal from the bus (though it was decided to use an external comparator to separate the uController from the bus). Device is supported by the PICmicro 18Cxx C compiler so it is possible to write the firmware in C. I'm using compiler version 2.40.

Complete schematic of the emulator is here.