Marc's Public Blog - Linux Home Automation

The rest is given for entertainment purposes only:
So, I've been wanting to have a deadbolt (not a lock since electric strikes won't work on my front door), that I can control from my misterhouse PC. For a while smarthome has had an insteon module that talks to Morningstar deadbolts, but it's not a 2 way link: there is no way to know if the door is locked or unlocked.

As a result, I never bought the smarthome/morningstar solution since it was important to me to know that my door wasn't closed right, or closed but unlocked.

Then, I found out about lockstate, and quickly found http://www.lockstateconnect.com/ . A wifi lock, that sounds great, right?

But, then I read up more about it, and found out it wasn't actually what I was hoping for, nor is it something I can recommend:

Right, you said lock bug?
Yes. After some testing, I confirmed that there is a flaw in lockstate locks with auto-lock. If auto lock fails just once, because your deadbolt is not aligned with the hole (happens easily on my door if I push it too far or not far enough), the firmware will remember that auto lock is not working, and not try to auto lock later.
The big flaw is that if you manually close the lock, the firmware is not aware of that fact, and it will refuse to autolock until you either power cycle the lock, or your force a lock even using a motor (either using the lock button on the wrong side of the door when you're inside, or using the remote control for the -R models).
I have notified lockstate of that flaw, but they didn't seem very interested in notifying their customers about it. The fix would include having their CPU read back the microswitches state even when it wasn't given a command (probably having a microswitch event trigger an interrupt that wakes up the CPU and tells it to notice the new state and re-enable auto lock if the deadbolt just got locked ok).
I have personally fixed that problem by having my computer keep track of the lock state and try to re-lock it using the RF remote if it stays unlocked for too long. But understand that without that, you'll most likely end up with the door unlocked sooner or later if you don't close it in perfect alignment every single time.

Proof if you don't believe me (it has 30 second delays since I have my door auto locks after 30 seconds)

Ok, so the wifi lock isn't it. What now?
Well, I did go with lockstate afterall, because they did have cheap locks that exactly matched the black color motif of my door, and aesthetics was important for the WAF :)

I bought the Lockstate LS-DB500R-RB (rubbed bronze) because it was a great deal for $100 onsale, and I knew I could very likely hack it to do what I wanted. So, it comes with a remote control, and I knew I could trivially connect its micro switches to a relay and control the door from my PC, just like the Morningstar option, but bypassing insteon and another module I'd have had to pay for.

The more important part however was how to know whether the door was closed, and whether it was locked.

The closed part, I solved first by simply using an X10Sec/X10RF DS10A door/window sensor: http://www.x10.com/security/ds10a_s.html . This is a wireless option working on batteries, and it will fail after 1-2 years when the batteries die, but I already have a fully working monitoring setup with those and misterhouse will tell me when the batteries are low or dead.

Next, I just did not want the lock to require batteries, see amazon comments like this one, so I decided to hot wire the door to a power supply.
First, I used a flat phone cable, which I painted, and only found out later that there wasn't enough copper in that cable (just a few thin wires) and it didn't have enough 'oomph' to actuate the motor, doh! So, I put a second thicker cable with enough copper for just the power, using the phone cable for the return path. I just wired the power where the batteries would go if I had put any.

Yes, the wires fit on my door because I have a small gap. Your door may be different

Return path you said? Yes, I found out how to connect to unused pins on the microswitches and know whether the door is locked or unlocked. You can do this easily without even soldering. See picture:

Now, if you're counting, you'll say that I had 4 wires in my phone cable, and I only used 2 to get the lock/unlock status. It would be nice if the other 2 wires could be used to tell the lock 'lock' or 'unlock', but AFAIK, this is non trivial to do since you don't want a lock to unlock by just easily shorting 2 wires on the board. This is why I got the LS-DB500R with remote control support.
The interesting bit is that the remote receiver is in the keypad, and the keypad actually will tell the lock CPU: "I received an unlock code, please unlock". This does mean that lock/unlock can be sent over the few wires that go through the door, but I'm somehow hopeful that it's not as easy as just shorting 2 wires :)

So, instead of explaining in long details, I'll show a few pictures on how to modify the remote control to connect it to relays. I used a small breadboard with a voltage regulator to get 3V from 5V which I have on my 1-wire relay board, and you can send lock/unlock codes by shorting one of the green wires with ground.

note the holes for power wires, nicely labelled 3V + -

finished setup with voltage regulator and power LED (since the remote will not show if it has power)

And I then connected everything to my 8 Channel 1-wire I/O board from hobby-boards.com.

If you look at the above picture carefully, relay 7 is an input relay that gets the 2 wires saying whether my door is locked. Locked shows as LED on. Relay 5 is an output relay to send the unlock command to the remote, and relay 6 sends the lock command. From there, you can watch the video showing how sending the unlock command from my PC (off camera) shows relay 5 going on, then input 7 going off showing unlocked, and later relay 6 going on for lock, closing the lock sense relay and turning input 7 LED back on.

And this is how I got a fully locally controllable lock with lock state sense and door open sense for barely over $100 and a little bit of time.

At linux.conf.au 2011, I gave a talk on Saving Money with Misterhouse: Running Your Lights and HVAC system, and other home automation tricks.
The video can be seen here.

Later, I gave a talk on Power Monitoring with Linux (including how to use the ECM1240 and graph its output with cacti) at Linuxcon 2011.

The simplest way to avoid this problem is simply to go wireless so that lightening does not reach your inside computers and networks. As a side note, the WMR968, while far from perfect, is cheaper than 1-wire equivalent solutions (only $200). The equivalent functionality with 1-wire is about $500

The kit comes with solar panels that recharge your device batteries, so they're supposed to run forever (i.e. until they eventually die), and you get:

wind sensor on the roof with the portable receiving console

rain sensor on top and hygro/temp sensor in the shade under the roof

little 'hack' to make the rain sensor more sensitive

The main thing that is nice with that kit outside of the fact that it's cheap, is that you can buy more receivers than there are in the kit (like multiple indoors BTHR receivers to get humidity in different rooms) and while the main console will not receive more than one, the rfxcom receiver I have plugged in my PC can receive as many as you can have (even your neighbours' :) ).
This allows for having the console in the kitchen for instance, and not have to run a cable to your computer in the closet by having it use its own receiver with a bigger antenna and processing ability for many more devices (see list).

Here is a link to all the WMR 968 graphs received from the rfxcom via XPL, with a couple of samples below:

The only caveat is that it's a bit cheaply built, some of the outside sensors are not super water proof, so I slightly modified mine to make sure I had good water seals, and so far so good: can't beat the price and it hasn't failed for me yet :) Not having to climb on the roof to change batteries every so often is a nice bonus :)

I had an old CM19a (USB X10RF and X10Sec transceiver) lying around. This was more desirable than the well known CM26a used by many misterhouse users in that on top of being USB, it more importantly can decode X10 Security RF signals, as well as send X10RF signals too.
Now, the problem with the CM19a, is that like the CM26a, it has a useless antenna and therefore a useless RF range. The good news however is that the same antenna hack that can be applied to the CM26a works with the CM19a too.

For pictures, see the example for the CM26a antenna modification this hack was based on (scroll to the antenna plug wiring).

In a nutshell, you cut the antenna wire to go far enough to reach the new antenna plug that you attach to the plastic (I used my soldering iron to burn a hole through it). The antenna wire will plug to the center connector. Then, the tricky side is to use the piece of wire you cut off, and connect it to the ground plate of that board. Ground is actually easy to solder to: most holes through the board with metal on each side are ways to pass ground from one side of the board to the other. I used one of them (see red arrow) to solder my other wire to, and connected that to the ground of the new plug.

You then have the option of using a dipole antenna or a quarter plane antenna to connect to your new plug (which one is best depends on where you put the antenna and what kind of area you are trying to cover).

By now, you actually have turned your CM19a into a device that's almost as good as a W800 for reception, but with the bonus of being able to send data too.

Next (for me), was making use of this in misterhouse. Because it is a USB device that does not emulate a serial port, it will not work in misterhouse without a special driver.
To find the simplest way to solve my problem, I decided to use the open source mochad to talk USB to the device and spit out the data frames it was receiving (I hacked mochad to spit out undecoded data). I then wrote a glue shell script that sends that data to a pipe which misterhouse can then read from. It then sends that data into the misterhouse X10_RF module, reusing the common decoding and injection code used by the X10_W800 and X10_MR26 misterhouse modules.
This all ended up in the new lib/X10_CMxx.pm module I wrote and added to misterhouse svn.

You can find more details on the Misterhouse Page for X10Sec and X10RF support with CM19a and CM15a through mochad.

Here are two examples of logs with debugging enabled:

02/07/2011 14:51:45  CMxx: Ignoring first send of X10RF data from mochad (looking for confirmation resend): 8F 80 84 7B F1 80
02/07/2011 14:51:45  CMxx: decoded data received from mochad: 07/02 14:51:45 Rx RFSEC Addr: 8F:F1:80 Func: Contact_normal_min_DS10A
02/07/2011 14:51:45  W800: security: unmatched device 0xf1 (state = NormalMin)
02/07/2011 14:51:45  CMxx: X10RF data from mochad: 8F 80 84 7B F1 80
02/07/2011 14:51:45  X10_CMXX: security: unmatched device 0xf1 (state = NormalMin)
02/07/2011 14:51:45  CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 2): 8F 80 84 7B F1 80
02/07/2011 14:51:46  CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 3): 8F 80 84 7B F1 80
02/07/2011 14:51:46  CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 3): 8F 80 84 7B F1 80

02/07/2011 14:51:59  CMxx: Ignoring first send of X10RF data from mochad (looking for confirmation resend): 60 9F 20 DF
02/07/2011 14:51:59  CMxx: decoded data received from mochad: 07/02 14:51:59 Rx RF HouseUnit: A1 Func: Off
02/07/2011 14:51:59  XA1AK: testx10 off
02/07/2011 14:51:59  CMxx: X10RF data from mochad: 60 9F 20 DF
02/07/2011 14:51:59  XA1AK: testx10 off
02/07/2011 14:51:59  XA1AK: testx10 off
02/07/2011 14:51:59  CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 2): 60 9F 20 DF
02/07/2011 14:51:59  CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 3): 60 9F 20 DF
02/07/2011 14:51:59  CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 3): 60 9F 20 DF
02/07/2011 14:51:59  CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 3): 60 9F 20 DF

Ultimately, mh without debugging only sees, which is what you want:
02/07/2011 14:51:59  XA1AK: testx10 off

Turns out that the freezer door had not been closed right (almost but not right, and it was enough not to make a tight seal). Unfortunately I found out right has we had left the house for a few days, so the freezer had to suffer through with the air leak, which created a lot of frost inside, but I was able to take care of it as soon as we got home, and all was well.

Until recently, I had a Brand One Powermeter to measure PG&E Meter, PV system and my AC. It was bulky, unreliable, and impossible to reprogram. In other words, it was a poor and expensive solution. That said, I still got some data and reasonable graphs from it as per this earlier blog post.

But let's be honest, I really didn't like that monitor and wanted to ditch it. After some research, the ECM1240 is the best feature/cost ratio power monitoring device I found. You can read about it on the brultech ECM1240 page.

Why is it better than the alternatives?

Here's what it looks like:

the whole system

I calibrated the TTs vs the split 60CTs and the small CT-40s by comparing measurements of the same load

the 2 white boxes are the ECMs1240s, but I also have my older and bigger brand one power meters in there

the small donut CT-40s are great, they take no room at all

After getting this installed, I was able to get data on linux after I got a working but incomplete (for me) ecmread.py from prior authors, Brian Jackson, Kelvin Kakugawa, and Amit Snyderman. I modified it to support net metering and show high precision data as required by proper per second graphing in cacti.

Code

Ok, first you can find all the graphs here: all regular owfs derived graphs.
And here are the interesting composite graphs.

So, US houses come with 2 120V phases. Now, if you wanted 100% exact wattage measurements, you'd have to measure the voltage on each and every circuit breaker you measure, but in reality measuring each phase is close enough.
In real life, measuring amps on one phase with voltage from another phase will only give you about a 1-2% error at worst, so it's not a lot to agonize about. In my setup I tried to measure phase 2 loads on my ECM that's plugged into phase 2 power, but wasn't fully able to do it, and it's not meaningful when you measure 240V loads anyway.

This is what the phases look like, as the graph shows phase 1 typically gets more power than phase 2 for me, but depending on the load in my street and my house, they sometimes become close or equal:

Of course, I have a lot of single interesting graphs. Can you tell when my disk to disk backup completed? :)

More importantly, and worryingly, compiling the same kernel took 30mn and 20W on my dual core duo laptop:

While compiling the same kernel on my dual Xeon P4 server took 2H and 80W-ish:

Another interesting graph was charging a 12V marine battery for my UPS:

Thanks to this graph, I was able to find that my TV and speakers took 30W when off. I got a smart power strip that turns them off totally and saved about 30W off my base load:

Ever wonder how much power your fridge is really using?

So, how much power does AC use? Well, not only 3500W for AC, but another 1000W for the whole house fans:

A cool graph showing House Power Use (calculated) from PG&E meter and PV production probe:

And for the money shot, all the house uses combined on one graph:

And the same graph, but with AC that was activated:

Setting up cacti

See my cacti config page.

Now, the tricky part is creating graph items that do not exist (like house use, or unmonitored house use). See this post I made on how to do this.

The other tricky part is that I had my ECM graphs setup to refresh every 10 seconds, which is faster than the cacti poller which runs every minute. This post explains how I did a faster than 1mn refresh in cacti

In a prior post, I wrote about using digitemp to talk to 1-wire temp sensors.
Digitemp is a good first choice if you only care about temperature since it's already available in most linux distributions, and it's pretty easy to setup. However, digitemp is fairly limited: first it does not support anything but temperature, and one humidity sensor (with only one convertion table, and there are several depending on which one you end up buying). On top of that, the humidity sensor only works with the serial interface and not the USB one.

1-wire supports a lot more than just temperature, including several kinds of humidity sensors, a moisture sensor which can be used to measure the amount of watering needed for your lawn, and outdoors UV and solar intensity sensors (available from hobby boards).
1-wire also has weather stations, but you do have to worry about your pole with the wind sensor being hit by lightening that would then be channeled back inside your house and to your computer (not good). Also, I have not found 1-wire weather stations to be price competitive with an Oregon Scientific WMR968 which is wireless and can be directly connected and read from via its serial port on linux and through misterhouse.

http://www.hobby-boards.com/catalog/index.php?cPath=22

This gives you a total of $493. For comparison an oregon scientific WMR968 weather station costs $200 (see this thread for details on that) and my WMR 968/rfxcom page for my setup.

After switching from digitemp, I realized that my single bus described here was really stretching the limits of a single bus. I therefore ended up adding a hub.

What you need to know about the hub is that you get 6 buses split off your original bus (i.e. you get 7, one is the original bus passed through but with bus power added, and there are 3 1-wire switch chips with a MAIN and AUX sub bus each, effectively giving you 6 more busses). The Hobby-Boards 1-wire hub, which is the one I bought, injects regulated 5V power and unregulated 12-24V power for some special outdoors 1-wire devices on all the ports, including the pass-through one.
Having a powered bus with 5 and 12-24V allows the use of some special 1-wire devices like the moisture meter, and the UV sensor.
If you go with the hobby-boards hub, you should plan to wire like they do to make your life easier: hobby boards wiring chart.
.

1-wire basic setup

I talked about what to buy, and how to wire on my last Temperature monitoring and graphing with 1wire devices, digitemp, misterhouse, and cacti post. Go read that section.

1-wire and star technology

If you have a wiring closet where all your cables come back, you have a star topology. With a hub, you can have up to 7 branches, which may be enough for you. If however you need more than that, when you use the wiring chart from hobby-boards, I recommend that you use pair 3-6 as a return for pair 4-5: i.e. you send signal down your cat-5 to some location and then you connect 4 to 3 and 5 to 6 at the end point. You then connect 3 and 6 to 4 and 5 of your next Cat-5 run elsewhere in your house.
When combining this techique and the 7 branches you get from a hub, this should give you more than plenty branches from your network closet.

I added the Hobby-Boards UV sensor to my roof 1-wire bus now that it had bus power added to it after I got the hub, and I used cella-wrap to make sure water wouldn't get in the box or touch the 1-wire device wires and create a temporary bus short. The UV board also has a built in temp sensor, but the weatherproof box it comes with will act as a greenhouse somewhat, so the temperature read by that sensor will be higher than normal (it is used for UV readout temp correction). If you don't care about UV index as much and would like outside humidity level, you may want to consider the humidity/temp/solar sensor instead (I get outside humidity through my WMR968 Oregon Scientific Weather Station, so I didn't care to have that in my outside 1-wire sensor).

UV sensor in mostly water proof box

gets inside the attic through a water proof hole

The moisture meter has a temp sensor on the moisture meter control board, but it is unfortunately not used to correct the moisture readings from the moisture probe (this sensor does have a moisture value that can vary up to 50% when fully wet between temperature extremes). Thankfully in real life, your soil temperature deeper down should not change too much and affect the reading too much.
I then buried the control board too so that it could be used as a soil temperature sensor.

moisture meter

the trick was not to bury the sensor too deep: just as deep as my grass roots

protecting the board from water

regular DS18B20 outside temperature probe in the shade

The temperature graph is not super exciting, but still good info. It's reassuring that the dirt temp doesn't change much and therefore the moisture readings won't be foiled much:

The moisture readings are more useful and for instance this graph shows how I wasn't watering enough, and turned up the sprinkler times a little bit so that the humidity ends up at a reasonable state:

But the really interesting graph is seeing soil humidity over soil temperature (green) and outside temperature (red):

what this graph shows is outside temperature obviously affecting soil temperature a little bit, and when soil temperature goes up on a wet sensor, it brings up the moisture reading somewhat unfortunately.
Similarly, from the 1-wire side, you don't see a humidity percentage, but a negative current value

cat /etc/owfs/moisture/35\ Front_Lawn/current; echo
    -1.35875

This is the code I use for now:

# 0.56625/0.5675 bone dry, but once got 0.335625.
# glass of water yielded 1.74 but I've sometimes seen 2.555. What to use?
my ($min, $max) = (0.33, 2.6);

# value should be temp ajusted in an ideal world, but I don't have correction tables.
$value *= -1;
$value = $min if ($value < $min);
$value = $max if ($value > $max);
$value = (100 * ($value - $min) / ($max - $min));

I've struggled on finding the upper value. First, I got -1.74 but eventually I sometimes got -2.55 out of the blue for a few samples, which yielded some clipping, so I changed the max value from -1.74 to -2.6 at noon on this graph, explaining the sudden dip. You can however you can see on the left the jump to 100% when the sprinklers were started:

Despite the sensor being noisy, temperature dependent, and hard to calibrate, the overall graph is still useful enough to show whether your sprinklers are keeping the dirt moist enough, or if your overall moist is just going down (bad).

Owfs setup

But back to 1-wire and owfs, owfs is more work to setup but it's just the way to go if you want anything more than temperature monitoring.
You need to start by getting the latest source code from http://www.owfs.org/, and compiling it. /configure --enable-debian did the right thing for me, but you need to make sure you have the right headers on your system

I wrote this script, read_owfs that reads from an owfs symlink tree and generates a digitemp looking logfile so that it's easy to parse the logfile later with the same code regardless of whether you use digitemp or owfs to capture the data.

owfs with a hub is a bit "interesting" since you have to find your devices in subtrees, which is why I made a symlink tree to make my life easier. I setup a symlink for each hub port and a chain name to point to each of the 3 buses' AUX or MAIN branch. This is what it looks like:

/etc/owfs/bus1 -> /owfs/1F.F05005000000
/etc/owfs/bus2 -> /owfs/1F.E25005000000
/etc/owfs/bus3 -> /owfs/1F.E15005000000
/etc/owfs/chain1 -> bus2/main
/etc/owfs/crawlspace_chain -> bus2/aux
/etc/owfs/dining_chain -> bus3/main
/etc/owfs/roof_chain -> bus1/aux

/etc/owfs/humidity/56 Hall_Closet -> ../chain1/26.2E4DF5000000/HIH4000
/etc/owfs/moisture/35 Front_Lawn -> ../crawlspace_chain/30.131A62120000

/etc/owfs/temperature/11 Family_Room -> ../chain1/10.A8D1ED010800
/etc/owfs/temperature/12 Living_Room -> ../chain1/10.52D1ED010800
/etc/owfs/temperature/15 Garage -> ../chain1/10.2223EF010800
/etc/owfs/temperature/21 Attic -> ../roof_chain/10.5DE1ED010800
/etc/owfs/temperature/22 Roof -> ../roof_chain/10.94A2ED010800
/etc/owfs/temperature/23 Outdoors_Roof -> ../roof_chain/28.57B659020000
/etc/owfs/temperature/25 Roof_UV -> ../roof_chain/EE.E749CB010800
/etc/owfs/temperature/31 Crawlspace -> ../crawlspace_chain/10.F9F3EE010800
/etc/owfs/temperature/32 Outdoors_Crawlspace -> ../crawlspace_chain/10.D1D0ED010800
/etc/owfs/temperature/35 Front_Lawn -> ../crawlspace_chain/30.131A62120000
(...)

This is how I start owfs and the xpl-owfs gateway:

gargamel:/etc/owfs# cat /etc/init.d/owfs 
#!/bin/sh
case "$1" in
  start)
        umount /owfs 2>/dev/null
	# serial
        /opt/owfs/bin/owserver -d /dev/DS9097U -F --error_print 0 --error_level 1 --nozero
	# usb
        #/opt/owfs/bin/owserver -u -F --error_print 0 --error_level 1 --nozero
        /opt/owfs/bin/owfs    -F -s localhost:4304 /owfs --nozero
        /opt/owfs/bin/owhttpd -F -s localhost:4304 -p 8082 --nozero
	# this comes from xpl-perl, reads /owfs devices and relays their data periodically
	# over XPL, where they can be relayed to misterhouse.
        xpl-owfs --interface eth1 --owfs-mount /owfs >/dev/null &
        ;;
  stop)
        pkill -f '/opt/owfs/bin/owfs'
        pkill -f '/opt/owfs/bin/owserver'
        pkill -f '/opt/owfs/bin/owhttp'
        pkill -f 'xpl-owfs'
        ;;
  restart|force-reload)
        $0 stop
        $0 start
        ;;
  *)
        echo "Usage: owfs {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac
exit 0

owfs-xpl is a good way to relay 1-wire data to misterhouse via its XPL gateway as opposed to reading owfs directly since you're assured not to hang.
This is how you setup devices in misterhouse:

XPL_SENSOR, bnz-owfs.*:10.2223EF010800, garage_temp, , temp
XPL_SENSOR, bnz-owfs.*:28.3359C7010000, freezer_temp, , temp
XPL_SENSOR, bnz-owfs.*:28.998D4D020000, computer_closet_temp, , temp
XPL_SENSOR, bnz-owfs.*:26.2E4DF5000000, hall_closet_temp, , temp
XPL_SENSOR, bnz-owfs.*:26.2E4DF5000000.1, hall_closet_humidity, , humidity

If you use xpl-owfs, adding .1 behind a humidity value lets it pick another DA converter between the default one in owfs: .1 for HIH4000, and .2 for HTM1735 (it makes a difference since the analog value is turned into a different moisture percentage value as a result).
Here's what it looks like and the patch for xpl-owfs if you are not running a recent one with that support:

gargamel:~# grep . /owfs/26.2E4DF5000000/{.,*}/humidity
/owfs/26.2E4DF5000000/./humidity:     58.8895
/owfs/26.2E4DF5000000/HIH4000/humidity:     60.5681
/owfs/26.2E4DF5000000/HTM1735/humidity:     56.8768

--- /usr/share/perl5/xPL/Dock/Owfs.pm.orig      2010-04-17 09:08:43.000000000 -0700
+++ /usr/share/perl5/xPL/Dock/Owfs.pm   2010-04-17 09:25:25.000000000 -0700
@@ -154,6 +154,8 @@
   foreach my $dev (@$devices) {
     foreach my $rec ([ "temperature", "temp" ],
                      [ 'humidity', 'humidity' ],
+                     [ 'HIH4000/humidity', 'humidity', 1 ],
+                     [ 'HTM1735/humidity', 'humidity', 2 ],
                      [ 'counters.A', 'count', 0 ],
                      [ 'counters.B', 'count', 1 ],
                      [ 'current', 'current' ]) {

Once you have misterhouse configured to receive XPL messages, with those in mh.private.ini:

ipaddress_xpl_broadcast = 192.168.205.255
ipaddress_xpl = 192.168.205.3
# this is how you turn it off
#xpl_disable = 1
# if you are using a better XPL hub, turn off the mh built in one
#xpl_nohub = 1

Then, you can simply read owfs values in misterhouse via XPL like so:

my $compcloset_temp = $computer_closet_temp->state()

Note that there are other ways to read owfs in misterhouse, namely:

The summary of the threads I posted however is that xPL and xpl-owfs are the way to go for reading owfs sensors in mh.

Feeding data in cacti / code

Now that you have data available in /etc/owfs/*, and being sent to misterhouse via xPL, you can (and should) log it to a file.

I have written two scripts for this:

The second script is the important one which can generate cacti data or help you regenerate/build an rrdtool RRA file from scratch if you add fields or change your data format (my recommendation is to plan ahead and add extra fields in your RRD file for probes you might add later (you can't add fields after the fact without regenerating the entire file and refilling it with all the data from time 0, so it's better to plan ahead and get it right the first time, and a good way to do that is to just add extra fields that you're not using yet but can use later) ).

For more details on cacti integration, see my Gatewaying 1-wire, XPL (Oregon Scientify Weather), Brultech ECM1240 Power Data, and Brand OneMeter Data to cacti page.

cacti_owfs can also be used for feeding data in an rrdtool after the fact (--dump-cacti) and used like so:

sort -u < dump | time xargs rrdtool update $RRD --template `cacti_owfs --cacti-dump-header`

See my cacti config page.

Gratuitous Graphs :)

Ok, first you can find all the graphs here: all regular owfs derived graphs.

And here are the interesting composite graphs.

I keep track of the humidity in our wine closet. This chart shows when I refilled the evaporation water plate:

AC run on a warm day:

I was curious to know if our old fridge in the garage was having unreasonable and too frequent on/off cycles. The old garage fridge does run a bit warmer but doesn't cycle that much more often than the new one, so I'm not as worried about it dying soon as much (it does take a fair amount of extra power though, being 10 years older):

Interestingly enough, it is actually the newer kitchen freezer which has occasional big temp jumps to >50F.

And this lets me keep track of temperature and humidity in our wine closet (the good news is the water plate in the closet does keep humidity higher compared to the house humidity level):