Nogal storend, maar wel eenvoudig te fixen…

The scutil command will set the following 3 items:
1) ComputerName (AppleTalk Name, SharingPrefPane, “Computer Name”)
2) LocalHostName (‘DNS’ name, how to get to a computer on a network by hostname, the ‘Edit’ button in Sharing PrefPane)
3) HostName (UNIX hostname, what shows up in terminal.)

For 1 and 2, scutil will make changes to this file: /Library/Preferences/SystemConfiguration/preferences.plist (Root -> System -> System)

SharingPrefPane ALSO makes changes to this .plist

So, if you’re a SysAdmin, like me, you can set ComputerName and LocalHostName by command line using:
sudo scutil –set ComputerName compname
sudo scutil –set LocalHostName compname

Deze info is hier te vinden.

Het eerste ‘slachtoffer’ van de meetcampagne is de zonneboiler. Die levert natuurlijk heel wat energie aan onze woning in de vorm van warm water. Die energie wordt gebruikt voor de productie van sanitair warm water. De zeldzame momenten dat de zon in de tussenseizoenen de hele dag schijnt kunnen we ook de verwarming een klein duwtje geven met de warmte van de zon. Maar wat kost ons dit nu aan elektriciteit?

In zo’n installatie zit naast het boilervat natuurlijk een ‘regeling’ en een pomp. De regeling stuurt de pomp aan, en de pomp zorgt ervoor dat het warme water uit de panelen in de boiler terechtkomt. De regeling zet de pomp aan als de panelen warmer zijn dan het water onderaan het boilervat. Hierbij probeert de regeling om het temperatuursverschil tussen de uitgang van de panelen en de bodem van het boilervat op 13 K te houden. Om dit effect te realiseren wordt de snelheid van de pomp geregeld. Hoe groter het temperatuursverschil, hoe sneller de pomp draait.

De regeling en de pomp verbruiken dus elektrische energie. Hoeveel precies heb ik de laatste weken eens gemeten. We hadden geluk met het mooie weer, de pomp heeft redelijk wat uren gedraaid.

Spoiler: het verbruik valt heel goed mee, zeker in het perspectief van de hoeveelheid energie die de zonneboiler oplevert in de vorm van warm water.

De grafiek met het elektriciteitsverbruik over de verschillende dagen van de laatste maand vind je hieronder.  Op heel zonnige dagen schommelt het dagverbruik rond de 250 Wh, terwijl het sluipverbruik van de regeling onder de 1W zit (20 Wh per dag) op dagen dat de zon niet schijnt. Je kan op de figuur klikken om de grafiek in detail te bekijken.

De bijhorende temperaturen van het boilervat zie je in de volgende figuur.

Laten we dus 1 en ander eens berekenen. Op 15/10 had ik bij wijze van test het boilervat ‘leeg’ laten trekken door de verwarming. De start-temperatuur van de hele boiler (~500 liter) was ongeveer 40 graden C. Tegen het eind van de middag was het hele vat ongeveer op 60 graden C gebracht. Die dag gebruikte de installatie 267 Wh elektrische energie. De energie-output in het boilervat bedroeg dus (ongeveer) 500 kg x 20 graden Kelvin x 4187 J/kgK = 41,87 MJ. Dat is 11,63 kWh. Meer dan een kubieke meter gas uitgespaard dus, met een investering van 267 Wh elektriciteit.

Of nog, een COP (coefficient of performance) van 44. Leuk in vergelijking met een warmtepomp he

Deze meting is uitgevoerd op een zonnige dag in het ‘tussenseizoen’. In de zomer zal de COP nog hoger liggen.

De installatie bestaat uit een Latento XXL van 500 liter, een TA UVR61-3 regeling, 4 Solarfocus CPC panelen die onder een helling van 35 graden in het dak gemonteerd zijn. Om goed te zijn zouden de panelen eigenlijk onder een grotere hellingsgraad moeten staan, want nu liggen ze optimaal gemonteerd voor de zomer, maar dan heb je sowieso zonne-energie op overschot. In de tussenseizoenen en in de winter komt de zon minder hoog op, en op dat ogenblik missen we dus een deel van de zonne-energie door reflectie.

Iemand met een installatie waar de panelen vb. op 60 graden gemonteerd zijn en die wat meetinfo kan bezorgen ter vergelijking?

Dit was een eerste meting. Wat nog volgt in de komende weken: het ventilatiesysteem, de waterpomp en de diepvriezer.

Ingrediënten

• 16 ansjovisreepjes in olijfolie.
• 4 rode (of gele) paprika’s.
• 250gr kerstomaatjes.
• 4 lente-uitjes.
• 2 teentjes knoflook.
• 200gr ontpitte olijven.
• 4 eetlepel kappertjes.
• 4 eetlepel olijfolie.
• 1/2 plantje basilicum.
• 1 koffielepel oregano.
• 1 koffielepel paprikapoeder.
• peper en zout.

Bereiding

De paprika’s in de lengte in 2 snijden, de pitjes en de witte zaadlijsten verwijderen en in een ovenschotel leggen.

De kerstomaatjes in 2 of 4 snijden, de lente-uitjes fijn snipperen, de teentjes knoflook persen, de olijven in 2 snijden en het basilicum grof snijden.

De olijfolie met het geperste knoflook, de oregano, het paprikapoeder, de fijngesnipperde lente-uitjes, de olijven, de kappertjes en de kerstomaatjes mengen. Met peper en zout kruiden.

De vulling over de paprikahelften verdelen en er 2 anjovisreepjes gekruist overleggen.

De ovenschotel gedurende 30 minuten in een op 200°C voorverwarmde oven plaatsen.

Even laten afkoelen en met het grof gesneden basilicum bestrooien.

Afwerking

Met wat brood lauw serveren.

Variant voor vulling: knoflook, gehalveerde kerstomaatjes, mozzarella, olijfolie, oregano, ansjovisfilet en versgemalen peper.

Variant voor de vulling: tonijn, scheutje witte wijn, enkele olijven, kappertjes en Italiaanse kruidenmix.

Thanks to the preparatory work of Maarten Damen and Roheve I didn’t have to reverse engineer the protocol myself. Credits to you guys! I upgraded the existing xpl-plugwise code that was originally developed by Jfn and I have put it in a git repository. It is available here.

I have tested the code on firmware v2.36 and v2.37. It seems the protocol was not changed after the last update. Thank you Plugwise

I have updated the xPL interface if you compare it to the original version of Jfn for Plugwise firmware v1: the power calculation logic is hidden from the user and the xPL messages are more matching the other schema defined by the project. Moreover, basic control can also be done with control.basic messages. You can query the status of Circles and switch them on and off. It is also possible to request a list of Circles that are known to the Circle+. You can query the live power consumption and you can readout the history energy usage averaged over 1-hour intervals.

I bought a separate Stick, Circle+ and Circle to be able to develop new features independently from the ‘live’ installation in our house. The live installation is used for long-duration testing. This second hardware set will also allow me to safely install future firmware updates in a development environment before applying them to the live installation. The fact that I did not have a separate environment was the reason it took me so long to upgrade to the new firmware. We’re relying too much on a working setup in our house to automatically switch lights and the amplifiers of our Squeezeboxen. Plugwise, if you read this, could you please reconsider opening up the protocol again? Closed protocols are so 1990′s…

The next sections show how the supported commands and responses look like for the various message schemas.

plugwise.basic

This is a custom schema that is specifically targeting the Plugwise devices. It is not officially endorsed by the xPL project team (yet?). It is mostly compatible with the original proposal by Jfn, with some modification to make it more compliant with existing schemas, but without breaking existing code to interface with Plugwise devices over xPL.

Controlling a Circle on

xpl-cmnd
{
hop=1
source=mhouse-mh.misterhouse
target=hollie-plugwise.hydra
}
plugwise.basic
{
command=on
device=551e4f
}

Generates this response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
plugwise.basic
{
device=551E4F
type=output
onoff=on
}

Controlling a circle off

xpl-cmnd
{
hop=1
source=mhouse-mh.misterhouse
target=hollie-plugwise.hydra
}
plugwise.basic
{
command=off
device=994f99
}

Response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
plugwise.basic
{
device=994F99
type=output
onoff=off
}

Request the state of a plug

This command allows you to retrieve some basic information on the status of a Circle. The response contains the onoff status, the address that is currently in use for the power consumption history, and the current date and time of the internal clock of the Circle. The address is important when you want to readout the power consumption over the last hour. See the ‘reading out power history‘ command below for more details on this.

xpl-cmnd
{
hop=1
source=mhouse-mh.misterhouse
target=hollie-plugwise.hydra
}
plugwise.basic
{
command=status
device=551e4f
}

Response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
plugwise.basic
{
device=551E4F
type=output
onoff=on
address=239
datetime=201109201836
}

Requesting a list of known Circles

This command requests to the Circle+ (= the ZigBee coordinator) what other Circles are known. Internally, this command first queries for available Circles (max 64 excluding the Circle+) and then it requests for every detected plug the calibration values required for calculating the power consumption. This command is useful to ‘discover’ Circles in an application.

Do note that the values returned are a list of known devices by the coordinator (i.e. they have been part of the network in the past). It does not mean that all devices in the list are online at the time the command is sent.

Also note: if you issue this request and not all known nodes are online, it is normal that you receive some error responses. This is due to the fact that as a consequence of this command the xpl-perl Plugwise module also tries to retrieve the calibration values. If a certain circle is offline then this command will fail and an error response will be generated.

The request:

xpl-cmnd
{
hop=1
source=bnz-test.desktop
target=*
}
plugwise.basic
{
command=listcircles
}

And the corresponding response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
plugwise.basic
{
command=listcircles
device00=98A5BE
device01=7310F6
}

Requesting the live power consumption

Now for the interesting commands if you want to retrieve the live power consumption of a Circle. In the previous version of the xpl-perl module for Plugwise you first needed to request the calibration information for a plug, then retrieve the number of pulses, and then do some calculations to determine the actual power consumption.
I have hidden all this code in the xpl-perl Plugwise module. Now you can request the live power consumption, and you, well, the live power consumption expressed in Watt. You get two results, one measurement over 1 sends, and one measurement over 8 seconds.

The corresponding xPL request looks like this:

xpl-cmnd
{
hop=1
source=bnz-sender.desktop
target=*
}
plugwise.basic
{
command=livepower
device=98A5BE
}

And the response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
plugwise.basic
{
device=98A5BE
type=power
current=0.0229
current8=0.0263
units=kW
}

This means that the measured power over the last second interval is 22.9 W, and measured over the last 8 seconds the measured power consumption is 26.3 W.

Reading out historic power information

Every Circle keeps a log of the power consumption averaged out over one-hour time intervals. If you want to keep an eye on the average power consumption of a device, it is useful to be able to access that data. The alternative, polling the Circle frequently, will not yield as accurate results.

A critical piece of information to be able to read out the historic buffer is the current log address that is in use. Get it by sending a status request to the Circle. Then subtract one (we want to read out the last complete 1-hour interval) and send this command (assuming the output of the status command for Circle 7310F6 was ‘address=222′):

xpl-cmnd
{
hop=1
source=bnz-sender.desktop
target=*
}
plugwise.basic
{
command=history
device=7310F6
address=221
}

The corresponding response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
plugwise.basic
{
device=7310F6
type=energy
current=0.044
units=kWh
datetime=201109131400
}

This response contains the following information: the ID of the device, the type of report that is generated, the energy used over the hour that is covered by the log address, the units in which the value is expressed (always kWh), and the date and time associated with the log address. This last piece of information is important for Circles that are not always online, and for cases where one wants to ‘dump’ the complete history that is present in the Circle memory.

control.basic

This is an official and supported message schema. The Plugwise devices can be controlled on and off. Other functions might be added later when it becomes clear how.

Controlling a Circle on

xpl-cmnd
{
hop=1
source=mhouse-mh.misterhouse
target=hollie-plugwise.hydra
}
control.basic
{
device=551e4f
type=output
current=enable
}

Generates this sensor.basic response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
sensor.basic
{
device=551E4F
type=output
current=HIGH
}

Controlling a circle off

xpl-cmnd
{
hop=1
source=mhouse-mh.misterhouse
target=hollie-plugwise.hydra
}
control.basic
{
device=994f99
type=output
current=disable
}

Response:

xpl-stat
{
hop=1
source=hollie-plugwise.hydra
target=*
}
sensor.basic
{
device=994F99
type=output
current=LOW
}

log.basic

The Plugwise xPL client uses the standard log.basic message schema for reporting errors.

Error response

When an invalid command is issued or an invalid Circle ID is passed, an error response is generated. The error response contains a descriptive text string, the message that caused the error (in Stick dataformat) and the returned error code by the Stick.

xpl-stat
{
hop=1
source=bnz-plugwise.hydra
target=*
}
log.basic
{
type=err
text=Received error response
code=0023000D6F0000ABCDEF8EFB:00E1
}

Helper scripts

I wrote some helper scripts to generate the messages described in this document. You can find them here.

Have fun experimenting! Feedback is always welcome…

I’ve been using this script quite some time to backup my Linux desktop to an NSLU2. I found it back during the spring clean of my archives and save it here for future reference.

#!/bin/sh

# This script does personal backups to a rsync backup server. You will end up
# with a 7 day rotating incremental backup. The incrementals will go
# into subdirectories named after the day of the week, and the current
# full backup goes into a directory called "current"
# Credits: tridge@linuxcare.com

# directory to backup
BDIR_LIST="/home /usr/share/jalbum"

# excludes file - this contains a wildcard pattern per line of files to exclude
EXCLUDES=excludes

# the name of the backup machine
BSERVER=hydra

# your password on the backup server
export RSYNC_PASSWORD=<insert_password_here>

########################################################################
# --exclude-from=$EXCLUDES
BACKUPDIR=`date +%A`
OPTS="--force --ignore-errors --delete-excluded
      --delete --backup --backup-dir=$BACKUPDIR -a --exclude-from=$EXCLUDES"

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin

# the following line clears the last weeks incremental directory
[ -d $HOME/emptydir ] || mkdir $HOME/emptydir
echo "Clearing last weeks incremental directory..."
rsync -vv --delete -a $HOME/emptydir/ backup@$BSERVER::backup/$BACKUPDIR
rmdir $HOME/emptydir

# now the actual transfer
echo "Starting actual backup..."
for BDIR in $BDIR_LIST; do
	rsync -vv $OPTS $BDIR backup@$BSERVER::backup/current
done

echo "Backup completed!"

Ingrediënten

• 16 cannelloni
• 125 g gerookte forelfilet
• 150 g spinazie (vers of diepvries, maar zonder room)
• 300 g groentereepjes
• 250 g ricotta
• 50 g gemalen parmezaan
• 50 g geraspte mozzarella
• 1 ui
• 2 teentjes knoflook
• 400 g tomatenstukjes met basilicum
• 2 dl kippenbouillon (1/2 blokje opgelost in 2dl heet water)
• 1 eetlepel olijfolie
• nootmuskaat
• peper

Bereiding

Voor de cannelloni vulling:

• De diepvriesspinazie laten ontdooien.
• De  gerookte forelfilet in fijne stukjes snijden.
• De stukjes forel met de ricotta tot een mousse mixen.
• De gemalen parmezaan en de spinazie eronder mengen.
• Met nootmuskaat en peper kruiden.
• De cannelloni met de ricottavulling vullen (tip: met behulp van een spuitzak).
• De cannelloni naast elkaar in een grote ovenschotel leggen (best de schotel vooraf inwrijven met een beetje olijfolie).

Voor de saus:

• De knoflookteentjes en de ui fijn snipperen.
• Wat olijfolie in een kookpot verhitten en de fijngesnipperde ui en het knoflook glazig bakken.
• De groentereepjes toevoegen en even laten meebakken.
• Met de tomatenstukjes en met de kippenbouillon overgieten.
• 10 minuten laten sudderen.
• De groentesaus over de cannelloni gieten.
• Met de geraspte mozzarella bestrooien.

De schotel in een op 200°C voorverwarmde oven plaatsen en ± 40 min. laten gaar worden.

Afwerking

4 cannelloni op elk bord schikken en er een stukje ciabatta bijgeven. De gerookte forel kan gerust door gerookte zalm vervangen worden.

Several fixes were already proposed, but they all focussed on replacing the built-in power supply. The problem with that is that the 3.5″ internal hard drive needs both a 12V and a 5V rail. So either you fix the original supply, you connect an ATX power supply or you take a 12V supply and build your own DCDC convertor to generate the 5V net from the 12V of the supply.

I was looking for a more simple solution and came up with this…

Instead of trying to revive the internal 3.5″ hard drive I replaced it with a 2.5″ laptop drive. The original drive was already running for quite some time either way, so replacing it with a new drive would help increasing the reliability of the Time Capsule (TC).

The advantage of the drive swap is that laptop hard drives typically only require a 5V rail. Moreover, laptop drives consume less power, heat and noise when they are active. The TC itself requires no 12V net so after the drive swap we can power the device through a simple 5V/3A wall wart.

Some action-shots of the upgrade…

First open the TC, and carefully remove the drive. Don’t forget to detach the temperature sensor from the drive. It is located under the foam sticker. Remove the broken power supply.

Then remove the metal bracket by unscrewing the two black screws. This bracket will be used to mount the laptop drive in the TC.

Drill the mounting holes and attach the drive with two screws.

Test-fit the data connector of the hard drive. You might need a little assistance for this

Then, let’s work on the power supply. First of all: when you remove the cover, only remove the part at the low-voltage side of the supply. The hot side (that is the part where the mains socket is connected to) has a few capacitors without bleeder resistors. This means that they keep a mains voltage level for a few days after the last time mains voltage was applied to the supply. If you inadvertedly touch them, you’ll feel it Should the cover break completely when you try to get access to the low-voltage side, make sure you discharge the high-voltage caps first. Then, unsolder the wires from the old power supply. You’ll need to remove the grey goo that is used to keep the wires in place. Then, solder two wires that will be connected to the plug socket for the wall wart. The negative wire should be soldered to the ratsnets that consists of 5 wires, the positive should be soldered to the ratsnest that consists of 4 wires. Isolate the remaining single wire that was used for the 12V net. Add a socket for the wall wart and glue it in place after the cable opening for the mains cable was adapted with a dremel.

Glue the temperature sensor on the new drive.

First test that the TC boots without powering the drive to ensure that everything is working fine.

Then shut it down, attach the hard drive and restart it.

Finally, put the cover back on the device. Enjoy your upgraded, more silent and more power efficient TC. It should last longer now since most of the heat producing parts have been removed from the space-constrained enclosure of the TC.

Parts used:

• 5V/15W power supply (Conrad 510820 - 89)
• Laptop hard drive (verified with Samsung spinpoint M7 drives of 500 GB and 640 GB)

Now this makes me wonder, why did Apple not design the device around a 2.5″ hard drive in the first place?

• Added a PWM output (can be enabled in the firmware with a define, is off by default to keep compliance with older firmware versions)
• Added support for OneWire temperature devices (DS1820-alike), sensors are queried once a minute but messages are only generated when the temperature changed (as per the xPL spec)
• The heartbeat messages gives info on the number of OneWire sensors that are detected, and on the PWM output if it is enabled
• Added packing support on the XPORT so that we shouldn’t be sending uncomplete xPL messages any more when two messages are generated consecutively
• Various bug fixes, including one that caused multiple nodes on a single LAN to ping-pong messages to each other causing the xPL network to be flooded…

Note, this firmware requires an update in the XPORT configuration: packing needs to be enabled with a gap of 12 ms.

The Plugwise system consists of neat plugin adapters that fit between a device and the power socket. The adapters can turn the plugged mains device on and off, and can at the same time measure the power consumption of the device that is attached.
The plugs are called ‘Circles’ and they form a wireless ZigBee mesh network around a coordinator (called Circle+). By itself, the network has no intelligence, it needs a link to a computer. This link is provided by a USB stick device (called ‘Stick’).

My problem: my home automation server is located upstairs, and my Circles are on the ground floor. The Stick cannot reliably communicate with the Circles.

Solution 1: buy the device called ‘Stretch’ provided by Plugwise. This device allows you to connect the Stick to your LAN to place it in range of your Circles.

Solution 2: build a custom device that performs the same functionality (and adds some neat features )

Obviously, we go for solution 2

On domoticaforum, somebody published a first version of an xPL module that could communicate with the Circles through the Stick (firmware v1). This module is written in Perl (yay!).

So, I dusted off my trusty old NSLU2 (nick-named ‘Slug’), put a Debian install on it, and now the Slug is hosting my Stick on the home LAN on the ground floor. Commands are sent from Misterhouse through an xPL module I wrote to control the devices that are connected to the Circles.

The steps required to duplicate this setup:

Get a Slug.

Flash it with the Debian firmware. I tried other firmwares, but eventually I ran into problems to install all required software to get the xPL module up and running every time. So I went with a full Debian install.

Install the xpl-perl software package (add deb http://www.xpl-perl.org.uk/download/debian ./ to sources.list),

Install the following packages

apt-get update
apt-get install libxpl-perl
apt-get install runit
apt-get install daemon-tools
apt-get install libclass-dbi-loader-perl
apt-get install libdatetime-event-sunrise-perl
apt-get install libdevice-serialport-perl
apt-get install libdigest-CRC-perl

Patch the xpl-perl IOHandler.pm file in your install so that it uses the Device::SerialPort module.

Add the xPL support to the xpl-perl software that has been installed by fetching and installing the files from my code.google.com account.

Run xpl-perl-setup

This will generate the required folders/files to run the daemons required for xPL (mainly the hub and xpl-plugwise)

Edit the xpl-hub run file to add the -i eth0, else the hub does not work.

Copy one of the /etc/xpl/services folders to /etc/xpl/services/xpl-plugwise and edit the run file to contain

#!/bin/sh
exec 2>&1
exec setuidgid xplperl envdir ./env softlimit -d300000 /usr/bin/xpl-plugwise --verbose --plugwise-verbose --interface eth0 --plugwise-tty /dev/ttyUSB0

Execute the ‘run’ for xpl-plugwise manually in the terminal to verify that it works correctly.

Finally, ensure that everybody has write access to /dev/ttyUSB0, or add the user xplperl to the dailout group. The way I did this was adding to /etc/rc.local the following line:

/bin/chmod a+rw /dev/ttyUSB0

That’s it, now you can control your Circles from whatever device on your LAN usign the open xPL protocol. If you install the Debian to a flash disk, the complete device (Slug+Stick) uses ~4 W.

The only disadvantage it that when Plugwise upgrades their firmware again and you migrate, you might need to update the xpl-plugwise software on the Slug to keep the communication ongoing. This is of course only a problem if you continue using the Stick with the windows software.

So for the moment, I’m still running the pre-February2010 firmware (called v1). When you buy new Circles right now, you get them with newer firmware that is not supported with the current version of the xpl-perl Plugwise module because Plugwise updated their API.

All in all, I’m quite happy with this setup…

Note:  before considering to duplicate this setup, be aware that there are some disadvantages to the Plugwise hardware.

First of all, the software that is provided to control the Circles is Windows only.
Secondly, the people behind Plugwise refuse to document the protocol that is used to communicate between their software and the Stick. It is not clear to me what they try to obtain by doing that, as every time they update their protocol there is always someone who reverse-engineers it.
Another annoyance with the hardware is that some of the Circles emit a low-volume buzzing noise when they are enabled. This is something to keep in mind should you plan to use the plug for a reading light next to your couch.
Finally, there is no way to find out what RF links between Circles are good and what links have a marginal link budget. The solution provided by the company is ‘just place more plugs to make the network more robust’. Nice plan, but when you have most on the plugs on the ground floor, and your server upstairs, then you don’t want to put buzzing Circles in your sleeping room to have a reliable link between the PC and the ZigBee network.

So, why did I choose to use the Plugwise system then? Well, the plugs have a nice formfactor, and Plugwise was the the only company I know of that delivered a ZigBee-based solution at the time I bought the hardware. Indeed, originally it was stated on their website that using the appropriate network key other devices could also make use of the ZigBee mesh network. I thought it would be nice to build a basic mesh network in my house to which other devices/sensors could be added. Unfortunately, when I asked for the key, I got a friendly reply that this feature was not supported, I got the offer to return the hardware if I had a problem with that, and finally, the statement was withdrawn from their website…