My Take on SageTV Server Power Savings

I've been working off & on with the media server's power management. Since we have a DirecTiVo, most of our live viewing is done on that along with some recording, so the Sage server doesn't need to be online unless we're watching some recorded content from it or it's recording. So I can really keep this thing powered down 70% of the time, and almost 90% of the time since it's summer. So I spent some more time figuring out when SageTV is being used and came up with this write up. My solution, like our home automation system, integrates a lot of separate pieces to get things just right.

Let's get to it. First off, as in my previous post, we use the exported sage schedule. Grab this Perl file and save it as a .pl file. The script is fairly simple. It takes a command line argument, the path to the schedule file, and figures out what hours of the day SageTV is recording. It puts that info into a mySQL database called mystuff with username and password as the login credentials. You don't have to use mySQL, that's just what I use to pass data between different components of our system.

The next step involves our xPL Plugin for SageTV and your favorite xPL scripting engine. The engine we use is our homebrew xPL sCU - an xPL bridge to starCOMUltra, the HA software we use. With the xPL plugin for Sage, you can query it for which clients & extenders are currently playing media (or you can rely on the hidden feature where the plugin will check the playing status whenever it receives any xPL message - it will send an update only if the status has changed). In xPL sCU, I've scripted up logic for processing those updates:

function xPLReceived(e,schema,source,dest,msgtype) {
    switch(schema.toLowerCase()) {
        case "doghouse-sagetv.media":
            if (schema.toLowerCase()=="media.mptrnspt") {
                mpName=e.XplMsg.GetParam(1, "mp");
                mpCommand=e.XplMsg.GetParam(1, "command");
                mpStatus = mySQLQuery("locals","value","SagePlayerStatus");
                switch (mpName) {
                    case "LR":
                        mpID=0;
                        break;
                    case "FR":
                        mpID=1;
                        break;
                    case "Master":
                        mpID=2;
                        break;
                }
                if (mpCommand=="play") {
                    mpStatus=mpStatus | Math.pow(2,mpID);
                } else {
                    mpStatus=mpStatus & (7-Math.pow(2,mpID));
                    if (mpStatus==0) {
                        sTimers.load("SageClientIdleTimer",20*60);
                    }
                }
                if (mpStatus!=0) {
                    sCUDevices.Flags.Item("SageClientIdle").State=0;
                }
            }

What the snippet does is process xPL messages about the media players' state. If any player is in use, it clears the SageClientIdle flag in starCOMUltra. If a player becomes idle, it checks to see if all the players are idle and starts a 20 minute timer. Elsewhere in the code (not shown) is if that timer expires and all players are still idle, the SageClientIdle flag is set. You can choose your own idle timer length.

Now we have the player and recording status, but wait, what if I'm using the server for some other purpose? The only way I'd be using the server is via remote desktop, so i set up an EventGhost macro on the Sage server to send xPL messages when an RDP session is initiated or closed. A timeout period after a session is closed will determine if that aspect of the server is idle.

Finally, we have all the pieces in the place. In starCOMUltra, where everything comes together, we have this piece of code that runs hourly (along with the parseSage.pl script):

        // to prevent unneeded throttling, we'll check if sage is currently
        // recording or will need to in the next 3 hours
        sageRecord=0;
        for (i=0;i<4;i++) {
            if (mySQLQuery2("sagesched","value","hour",TimeHour()+i)==1) {
                sageRecord=1;
            }
        }
        // check if media server is awake and no RDP sessions open and no recordings
        // for the next 3 hours and no players in use - then 10 after the hour
        // we'll put the server to sleep
        if (mySQLQuery("locals","value","MediaAwake")==1 && \
            mySQLQuery("locals","value","mediaRDP")==0 && \
            Devices.Flags.Item("SageClientIdle").State==1) { \
            sageRecord==0 && mins==10) { 
            LogDevice("#        stop sage server");
            HibernateMedia();
        }

To wake up the server manually, all our viewing areas have a 3Com Audrey touchscreen nearby. It has a screen to wake up the media server which takes a few minutes. Not perfect, but like I said, we use the DirecTivo for most of the on demand TV watching. Plus, most of the time, we watch recordings during prime time and the server is already on.

"That's all!" ;) Obviously, this is very specific to our setup and situation, but hopefully there are ideas and code bits that may be useful to you.

Remote W800 Deployed & Remote System Summary

I just installed the new W800 at our other house. In keeping with my tradition of cheapness, I ordered the bare $49 W800 instead of the $75 kit. I made my own power adapter from a leftover 9V wall wart and a 3.5mm mono jack (tip positive). I had 3 different 9V wall warts to choose from in my junk box, one output 8.7V, one 10.5V, and the third put out 11.5V. The W800 would only work with the highest output wall wart, which jives with the output from power supply from the first W800. Instead of the kit antenna, I connected the W800 to a set of leftover TV rabbit ears. I'm not looking for long distance reception as it's a small place. Finally, I had an extra serial cable in a spare parts bin.

I'm using xPLW800 and it works perfectly. I installed a few devices from my leftovers - 2 DS10A's as leak detectors and a few Hawkeye motion detectors. The motion sensors, combined with the Bluetooth tracking, will allow the system to track occupancy and execute the security lighting scheme if we're not around.

So far, the remote thin client is loaded up with:
* CM11A on a USB-serial adapter, using xPLCM11 for lighting/device control
* W800 on COM1, using xPLW800 for occupancy, dusk/dawn & leak detectors
* xPL Rocket for remote pan/tilt control of the USB rocket launcher & AirLink netcam wire-tied to it
* BlueTracker for occupancy detection
* EventGhost with xPL Plugin for all automation logic

With those apps running, there's still about 190MB of RAM free after I did the 512MB upgrade. CPU utilization is low, typically around 5-10% and briefly jumping to about 20-25% when an X10 command is issued. I can probably add a couple more small apps without killing the system.

The thin client is turning out to be the perfect device for our application. It is slow, but we don't interact with it at all, unlike our main home's automation server. It has low power consumption (10-12W), solid state disk reliablity and auto-powers on after an outage. I thought about putting it on a UPS, but since we won't be at house very often, I'm wary of leaving a UPS there. I've had one UPS burn up after several months and 2 others ended up with cracked and leaking batteries.

I've been very pleased with EventGhost as the heart of the system. It's lightweight in memory and CPU, has many useful plugins (Network Sender & Receiver are key for me) and has tons of flexibility with integrated Python scripting. It wouldn't be very useful to me if it weren't for the great xPL plugin I wrote ;)

Linking xPL Between Two Homes Over The Internet

As I wrote before, I would like to link xPL messages from our 2nd home. I needed to figure out a way to wrap the UDP xPL messages in TCP and tunnel them through some kind of connection. I decide to use EventGhost's Network Event Sender/Receiver plugins so I wouldn't have to write a separate app.

The first step is to establish a secure connection between the two networks. I chose SSH as I already have a device capable of being an SSH server at our 2nd/remote home. I will establish the SSH connection using Putty from our 1st home.



I'm creating a tunnel that will map port 8888 on the remote SSH server to port 8888 on my local machine. I'll need to click the Add button to enable it. I also checked Remote ports do the same, which will allow devices on the remote network to connect to the remote SSH server's port 8888. To enable this remote forwarding, you may have to configure your SSH server. For example, with OpenSSH, you need to add GatewayPorts yes to the sshd_config file.

Once that's set up, I can establish the SSH connection. On the local machine, I will add the Network Event Receiver plugin, point it to port 8888, set a password and an event prefix. On the remote machine, I will add the Network Event Sender plugin and point it the remote SSH server's port 888 and set a password to match the receiver.


Local EventGhost

Remote EventGhost

Now, in the remote EventGhost, I create a macro that captures all xPL messages and sends them the Network Event Sender.



Finally, on the local EventGhost, I create a Network Event Receiver macro that parses the data received and issues an xPL message with the original contents, but with the local EG as the sender instead of the original sender.




That's all there is to it. Now, I've got remote xPL messages coming across to my home network. You can easily add a remote EG receiver and local EG sender to allow xPL messages to flow in the opposite direction.

Upgraded & Configured Thin Clients

I finally got my 512MB flash disks from Transcend and upgraded all 3 T5700s and bumped their RAM to 512MB as well. This gives me enough resources to install .NET 2.0 so I can run some of my xPL apps on it. The xFx xAP hub fatals so I have to run a different hub to run xAP apps. So far, I've loaded one up with xEKG, an alternate version of my xPL Gameport app and EventGhost.

xPL EG Plugin Update

Did some code clean up on the plugin a week ago. The sendxPL task now only takes 1 argument for the xPL command. Latest plugin here.

Sample EventGhost Python Script for Parsing xPL Messages

To make my EventGhost xPL plugin really useful, you really need to be able to pick apart an xPL message to extract data from it. Luckily, EG allows you to associate a script with a macro. This makes it pretty simple to create complex interactions based on xPL messages. Just create an event to trigger on 'xPL.*' and add an action to it that's a Python script. Here's a sample script that sends an acknowledgment message when Blabber receives the word 'test' from a user. This script can easily be extended to handle all your xPL interactions.

import re

# split up the event components
xPLSplit = eg.event.suffix.split(':')

# make the pieces easy to remember
xPLType = xPLSplit[0]
xPLSchema = xPLSplit[1]
xPLSource = xPLSplit[2]
xPLTarget = xPLSplit[3]
xPLBody = xPLSplit[4]

# we only want xpl-trig messages
if xPLType == "xpl-trig":
    # only want messages from blabber
    if re.search('doghouse-blabber',xPLSource):
        bodySplit = xPLBody.split(',')
        # extract the components of the message body
        for i in range(3):
            if re.search('device',bodySplit[i]):
                senderSplit = bodySplit[i].split('=')
            elif re.search('type',bodySplit[i]):
                typeSplit = bodySplit[i].split('=')
            elif re.search('current',bodySplit[i]):
                currentSplit = bodySplit[i].split('=')
        # we only want the message type and messages that
        # contain the word 'test'
        if typeSplit[1] == "message" and currentSplit[1]=="test":
            # if we get 'test' we'll reply back to the sender
            # that we got his message
            
            returnMsg = "device="+senderSplit[1]+"\n"+"current=EG got your test"
            eg.plugins.xPL.sendxPL(u'xpl-cmnd', u'control.basic', xPLSource, \
            returnMsg)

Updated EventGhost xPL Plugin

I updated the EventGhost xPL Plugin I wrote about here. It now supports EG version 0.3.6. Grab it.

xPL Plugin for Event Ghost

I just threw together an xPL plugin for Event Ghost in a couple days. It allows you to add macros in EG that respond to xPL events and to send xPL messages in response to other events. I'm not a Python coder by any stretch, but I can hack my way through enough of it to be dangerous. Therefore, don't expect the code to be that great or readable.

Here's a couple of screenshots of it in action:



This one shows an event generated by the plugin. The format of the event is:
xPL.<message identifier>:<schema>:<source>:<target>:<xPL message body>

Obviously, you'll get billions of different events so that may make it more difficult to deal with on the EG side as there doesn't appear to be any wildcarding of events.



This screencap shows the configuration box to send an xPL message.

Download the plugin here. I don't have much time to support this, so good luck with it ;) You should understand xPL. If not, read and ask.