Marc's Public Blog - Linux Home Automation

SUCCESS!

That only took about 6H, why it it dark outside? Oh, it's past midnight. What was I doing before that?

This is what it looks like:

I analysed how the DS10A worked, and due to sheer luck in its design, the wires going to the magnetic sensor turn out to be ground and signal, and the water sensor conducted enough current between them to allow triggering of the DS10A:

Wiring is totally trivial, you only need to use a 3rd wire connected to the plus from the 2 batteries, and it "just works". For extra credit, I wired a buzzer between signal and ground, and my water sensor passed enough current to allow the buzzer to run.

I used the Phantom YoYo High Sensitivity Water Sensor which was $10, but apparently you can get one that should work too from seedstudio for $3

The DS10A, I have a stack of, which you can sometimes find on ebay for cheap in bundles, and my house is already wired to receive those signals, so it was trivial to generate an Email and page from misterhouse when this sensor got triggered.

With my new roomba, I even setup 3 zones with virtual walls, and I really wanted to have an idea how long my roomba went out to see how much work it was doing and how its battery was doing over time.

In the end, I ended up using a DS10A door/window sensor and glued a magnet on top of my roomba, which closes the contact when it goes back to its dock. I then have misterhouse code that kept track of how long I left my doors opened to also keep track of my roomba and long it goes to work, as well as warn me if it doesn't make it back to its dock after too many hours:

My mailbox now shows:

Chg: Roomba Just Left                                    
Chg: Roomba Just Returned after 41.1 mn                  
Chg: Roomba Just Left                                    
ChgTmr: Roomba Left longer than 300 mn                   
Chg: Roomba FINALLY Returned after 2881.1 mn             

That way, I know when the timer worked, how long my roomba worked, and whether it got stuck somewhere or not. Ok, it'snot perfect, it would be nice to know when it crossed the zones, and how long it ran before getting stuck. This sounds a lot more involved though, maybe later.

But the important thing is that the telnet connection 2-way, so it will also tell you whathe receiver is doing. I use this to know when the receiver turns on or off, and more importantly when it tunes into my mythtv input. When that happens, I have my controlling PC (the one that's always on) know that the AV receiver switched to mythtv, and it will send a wake on lan (WOL) packet to my mythtv to wake it up from S3 sleep, as well as restart X because for my video card X doesn't resume properly over HDMI.

At the same time, as explained in an earlier post on how to mute and change volume on a Denon receiver using a mythtv remote, I already have my mythtv send commands to my Denon AV receiver to change the volume or mute it.

Given the above, I now had the problem that both my hacks didn't work at the same time because denon receivers only accept one telnet connection. Thankfully the connection is 2-way, but you need the code that can receive status from it independently from writing to the telnet socket.

So, I found denon.pl from bradfitz and quickly adapted my code into it. My new code reads commands from a FIFO and passes them on ot the socket. With my diffs, it's not super pretty code, but I stopped caring when it worked :)

So now, I have my denon to trigger a WOL packet to wake up my mythtv PC from S3 ACPI sleep when it's selected in the receiver.
In turn, when my denon is told to sleep, my code receives the state change over the telnet connection and my controlling PC uses the info to make mythfrontend exist back to mythwelcome, which in turn will cause the mythtv to go to S3 sleep if it's not doing anything else.
This can all be done by only reading from the telnet connection (which I used to do), but now I also use mythtv to control the sound on the receiver and this is done by sending commands asynchronously from the status updates being received.

This is how the mute script works:

 

#!/bin/bash

FILE=/tmp/denonmute

test -f $FILE || touch $FILE

# prevent bounces
[ $(( $(date "+%s") - $(stat -c "%Z" $FILE) )) -lt 2 ] && exit

if grep -q MUON $FILE 2>/dev/null; then
	CMD=MUOFF
else
	CMD=MUON
fi

# Used to be: 
#echo -ne "$CMD\r" | nc -q0 denon 23
#echo $CMD > $FILE

echo $CMD | tee $FILE > /var/run/denon.fifo

Here is the code that interacts with my Denon AVR:

On the mythtv side, these are some of my scripts:

 

#!/bin/bash

# See http://www.mythtv.org/wiki/ACPI_Wakeup
# Time wakeup format was hh:mm yyyy-MM-dd and changed to time_t

DATE=$(date "+%Y:%m:%d-%H:%M:%S")
LOG=/var/log/mythtv/myth_acpi

exec >>$LOG
exec 2>>$LOG

# This will shutdown if I pause too long without turning off denon.
#for mplayer in $(pgrep mplayer)
#do
#    # See if mplayer is currently playing.
#    before=$(grep pos /proc/$mplayer/fdinfo/*)
#    sleep 2
#    after=$(grep pos /proc/$mplayer/fdinfo/*)
#
#    if [ "$before" != "$after" ]; then
#	echo "$DATE: $0 found running mplayer, cancel sleep"
#	ps auxww |grep "[ ]$mplayer"
#	exit 1
#    fi	
#done

# mplayer is killed in myth_frontend_shutdown.
if pgrep mplayer; then
    echo "$DATE: $0 found mplayer, cancel sleep"
    ps auxww |grep "[mM]player"
    exit 1
fi

if pgrep xbmc.bin >/dev/null; then
    echo "$DATE: $0 xbmc running, cancel sleep"
    exit 1
fi

if who | grep -qv mythtv; then
    echo "$DATE: $0 root logged in, cancel sleep"
    who
    exit 1
fi

echo "$DATE: $0 called, and nothing blocking shutdown"

 

#!/bin/bash

etherwake -i eth1 00:22:15:8c:66:e9
etherwake -i wlan0 00:22:15:8c:66:e9 &>/dev/null

 

#!/bin/bash
LOG=/var/log/mythtv/myth_acpi
exec >>$LOG
exec 2>>$LOG

if pgrep xbmc.bin >/dev/null; then
    echo "$(date "+%Y:%m:%d-%H:%M"): Asking XBMC to shut down"
    /var/local/scr/alarm 5 wget --quiet -O /dev/null 'http://localhost:8080/xbmcCmds/xbmcHttp?command=exit'
    sleep 5
    ps auxww | grep '[xX]bmc'
    if pgrep xbmc.bin || pgrep xmbc; then
	echo "$(date "+%Y:%m:%d-%H:%M"): XBMC DID NOT DIE, FORCIBLY KILLING."
	killall xbmc.bin xbmc
	sleep 1
	killall -9 xbmc.bin xbmc
    fi
fi

# stop mplayer so that myth_can_shutdown can detect and shutdown.
killall mplayer

# killing xbmc can restart mythfrontend.
sleep 1

if pgrep -f mythfrontend.real >/dev/null; then
    echo "$(date "+%Y:%m:%d-%H:%M"): Asking mythfrontend pid $(pgrep -f mythfrontend.real) to shut down"
    # http://www.mythtv.org/wiki/Keybindings
    #for key in space f1 escape escape down enter
    #do
	#nc -q0 localhost 6546 <<< "key $key"
	#sleep 1
    #done
    for cmd in 'jump mainmenu' 'key escape' 'key down' 'key enter'
    do
	echo "sending $cmd"
	nc -q0 localhost 6546 <<< "$cmd"
	sleep 1
    done
    # Key enter takes a long time to exit mythfrontend.
    sleep 10
    if pgrep -f mythfrontend.real; then
	echo "$(date "+%Y:%m:%d-%H:%M"): MYTHFRONTEND DID NOT DIE, FORCIBLY KILLING."
	/usr/bin/killall mythfrontend.real
	sleep 1
	/usr/bin/killall -9 mythfrontend.real
    else
	echo "$(date "+%Y:%m:%d-%H:%M"): mythfrontend has shut down."
    fi
fi

 

#!/bin/bash

export PATH=/var/local/scr:$PATH

while :
do
    # I shouldn't have to kill mythfrontend because it shouldn't be running
    # but this is just for completeness.
    # I have also had one case like below where I had to kill Xorg.
    # |-login(6160)---startx(6184,mythtv)---xinit(6307)-+-Xorg(6308,root)
    # |                                                 `-xinit(6318)
    killall mythwelcome xinit mythfrontend.real mythfrontend Xorg

    sleep 6
    X_TTY=$(ps auxww | grep '/usr/bin/[X]' | sed -e "s/.* tty//" -e "s/[^0-9].*//")

    /var/local/scr/alarm 3 sudo chvt 2
    sleep 1
    /var/local/scr/alarm 3 sudo chvt $X_TTY

    sleep 2
    # This doesn't actually check that X is talking to a screen, it works 
    # when waking up from RTC and no screen is connected :(
    #if grep 'intel(0): EDID vendor "DON"' /var/log/Xorg.0.log; then
    if grep 'Resuming AIGLX clients after VT switch' /var/log/Xorg.0.log; then
	echo "X seems be running and displaying"
	break
    else
	echo ">>>>>>>>>>>> X isn't displaying, trying restart loop <<<<<<<<<<<<<<<<"
    fi
done

For indexing purposes, here is a snapshot of the main denon code

 

#!/usr/bin/perl

# Originally from bradfitz (denon.pl on github).

use strict;
use IO::Socket::INET;
use Time::HiRes qw (sleep);
use POSIX qw(mkfifo);
use Carp qw(croak);
use FileHandle;

my $host = "denon";
my $fifo = "/var/run/denon.fifo";
my $port = 23;

STDOUT->autoflush(1);
STDERR->autoflush(1);

("\xff\xfd\x03" eq fromhex("ff fd", " 03 ")) or die "Unittest failed";

# ----------------

my $sock = IO::Socket::INET->new(PeerAddr => $host,
                                 PeerPort => $port)
    or die "Failed to connect to $host:$port";

sub expect_from_denon {
    my $expected = shift;
    my $got = "";
    my $buf;
    print "Waiting on ", printable($expected), "...";
    while (length($got) < length($expected) &&
           sysread($sock, $buf, length($expected) - length($got))) {
        $got .= $buf;
    }
    croak "Didn't get expected input." unless $got eq $expected;
    print "Got it.\n";
    return 1;
}

sub fromhex {
    my $in = join(', @_);
    $in =~ s/\s*(..)\s*/chr(hex($1))/eg;
    return $in;
}

sub send_to_denon {
    my $str = shift;
    syswrite($sock, $str) = length($str) or die;
    # We don't sync with the reader, but blind sleep for each line sent.
    sleep 0.2;
}

sub printable {
    my $str = shift;
    $str =~ s/[^[:print:]]/sprintf("x%02x", ord($&))/eg;
    return $str;
}

sub turn_off_myth {
	# for key in 'key space' 'jump mainmenu' 'key escape' 'key down' 'key enter'; do 
        # echo "$key" | nc myth 6546; echo "$key"; sleep 3; done
	system("date; /var/local/scr/alarm 10 telnet myth 10221; date");
}

sub wakeup_activate_myth {
    if (not system("fping -c3 -p1 -q myth"))
    {
	print "myth is already up, toggle X screen to wake X up\n";
	system("date; /var/local/scr/alarm 20 telnet myth 10222; date");
    }
    else
    {
	# If we start myth too quickly and the display isn't ready, it becomes
	# unable to talk to it until it goes through another suspend/resume.
	# Mmmh, actually it doesn't look like sleeping here is useful. but let's
	sleep 1;
	print "myth is down, wake it up and restart X\n";
        # 5 Seconds is a bit aggressive for the machine to wake up and
	# be ready to flip Xorg, but it seems to work.
	system("date; sudo /var/local/scr/myth-fmr_wol; fping -r 5 myth && date && "        
        "echo 'sleep 5 wait for X to restart safely' && sleep 5 && /var/local/scr/alarm 20 telnet myth 10222; date");
    }
}

sub printlog {
    my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime();
    my $mesg = $_[0];
    $year+=1900;
    $mon++;

    chomp($mesg);
    printf LOG ("%.4d/%.2d/%.2d %.2d:%.2d:%.2d - $mesg\n", $year, $mon, $mday, $hour, $min, $sec);
}

# --------------------------------------------------------------------------------

my $hello = fromhex("ff fd 03", # Do Suppress Go ahead
                    "ff fb 18", # Will Terminal Type
                    "ff fb 1f", # Will Negotiate About Window Size
                    "ff fb 20", # Will Terminal Speed
                    "ff fb 21", # Will Remote Flow Control
                    "ff fb 22", # Will Linemode
                    "ff fb 27", # Will New Environment Option
                    "ff fd 05", # Do Status
                    );

send_to_denon($hello);

expect_from_denon(fromhex("ff fb 03"));  # Will Suppress Go Ahead
expect_from_denon(fromhex("ff fa 18 01 ff f0")); # Send your terminal type

print "send terminal.\n";
send_to_denon(fromhex("ff fa 18 00",
                      "rxvt",
                      "ff f0",  # suboption end
                      ));

expect_from_denon("BridgeCo AG Telnet server\x0a\x0d");

my $child = fork;
defined($child) or die "Fork failure.";

if ($child) # we're the parent process.  accept input.
{
    if ($#ARGV eq -1)
    {
	while (1) 
	{
	    print "DENON> ";
	    my $line = <STDIN>;
	    chomp $line;
	    next if (!$line);
	    exit if ($line eq "quit" or $line eq "q" or $line eq "exit");
	    send_to_denon($line . "\x0d");
	}
    } 
    elsif ($#ARGV eq 0)
    {
	my $arg = $ARGV[0];

	if ($arg eq "--server")
	{
	    -p $fifo or mkfifo($fifo, 0700) or die "mkfifo($fifo) failed: $!";

	    print "Will read from fifo $fifo until ^C\n";
	    my $logfile = "/var/log/denon-send.log";
	    open(LOG, ">>$logfile") or die "Can't write to $logfile";
	    LOG->autoflush(1);

	    open(FIFO, "<$fifo") or die "Can't read from $fifo: $!";
	    while (1) 
	    {
		sleep 0.1;
		my $arg = <FIFO>;
		next if (not $arg);

		chomp $arg;
		printlog("sending $arg");
		send_to_denon($arg . "\x0d");
	    }
	}
	else
	{
	    print "Will send $arg to $host\n";
	    send_to_denon($arg . "\x0d");
	}
    } 
    elsif ($#ARGV eq 1)
    {
	my ($arg, $repeat) = @ARGV;
	print "Will send $arg to $host $repeat times\n";
	foreach $_ (1 .. $repeat)
	{
	    send_to_denon($ARGV[0] . "\x0d");
	}
    } 
    else
    {
	die "Too many args: ".join(" ", @ARGV);
    }
} 
else # Child process, 
{
    my $logfile = "/var/log/denon.log";
    open(LOG, ">>$logfile") or die "Can't write to $logfile";
    LOG->autoflush(1);

    # Init state machine for keeping track of whether receiver is on or off
    # and on which output. By default, we'll pretend the last output was DVR
    my $input = "SIDVR";

    # Sometimes, the connection to denon dies when denon starts up.
    # When this happens, we missed the first PWON, so we assume that
    # we're at stage one already (first PWON seen) when we start.
    my $denon_state = "on_stage1";

    # Turning back on to mythtv when it was off, we need to wait for the 2nd PWON
    # 2011/11/09 05:50:17 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:50:17 - PWON
    # 2011/11/09 05:50:17 - ZMON
    # 2011/11/09 05:50:20 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:50:21 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:50:24 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:50:24 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:50:25 - PSROOM EQ:AUDYSSEY
    # look for 2nd PWON vvvvvvvv
    # 2011/11/09 05:50:25 - PWON
    # 2011/11/09 05:50:42 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:50:44 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:50:44 - PSROOM EQ:AUDYSSEY
    # 
    # Turning on when mythtv was the last input to DVD
    # 2011/11/09 05:48:22 - ZMOFF
    # 2011/11/09 05:48:38 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:48:38 - PWON
    # 2011/11/09 05:48:39 - ZMON
    # 2011/11/09 05:48:41 - PSROOM EQ:AUDYSSEY
    # 2011/11/09 05:48:43 - SIDVD
    # 2011/11/09 05:48:43 - Denon switched input to SIDVD
    # 2011/11/09 05:48:43 - SDHDMI
    # 2011/11/09 05:48:43 - SVSAT
    # 2011/11/09 05:48:43 - DCAUTO
    # 2011/11/09 05:48:43 - CVFL 495
    # 2011/11/09 05:48:43 - CVFR 505
    # 2011/11/09 05:48:43 - CVC 495
    # 2011/11/09 05:48:43 - CVSW 52
    # 2011/11/09 05:48:43 - CVSL 495
    # 2011/11/09 05:48:43 - CVSR 52
    # 2011/11/09 05:48:43 - CVSBL 50
    # 2011/11/09 05:48:43 - CVSBR 50
    # 2011/11/09 05:48:43 - CVSB 50
    # 2011/11/09 05:48:43 - MVMAX 98
    # 2011/11/09 05:48:43 - PSROOM EQ:AUDYSSEY
    # look for 2nd PWON vvvvvvvv
    # 2011/11/09 05:48:47 - PWON
    # 2011/11/09 05:49:19 - SIDVR
    # 2011/11/09 05:49:19 - SDAUTO
    # 2011/11/09 05:49:19 - SVDVR
    # 2011/11/09 05:49:19 - DCAUTO

    # Show any read data, and depending on some commands read, wake up
    # or put mythtv to sleep.
    my $data;
    while (sysread($sock, $data, 300)) 
    {
      $data =~ s/\015/\n/g;
      foreach my $line (split(/\n/, $data))
      {
        printlog("Read: ".printable($line));

	if ($line =~ /SIDVR/)
	{
	    printlog("Denon switched to MythTV (denon state $denon_state), waking up myth");
	    wakeup_activate_myth();
	    $input = $line;
	}
	elsif ($line =~ /^SI/)
	{
	    printlog("Denon switched input to $line");
	    $input = $line;
	    if ($denon_state eq "on")
	    {
		printlog("Denon on (state $denon_state), but switched to $input. Turn off mythtv");
		turn_off_myth();
	    }
	}
	elsif ($line =~ /PWON/)
	{
	    if ($denon_state eq "off")
	    {
		$denon_state = "on_stage1";
		printlog("Denon being turned on, switching to stage1 on");
		# Between now and the second 'ON', we'll have gotten a new
		# input line if input got switched at power on, or we use
		# the last one we've seen in the past.
	    }
	    else
	    {
		printlog("Got another PWON (was $denon_state)");
		$denon_state = "on";
		if ($input =~ /SIDVR/)
		{
		    printlog("Denon turned on and was last on MythTV, waking up myth");
		    wakeup_activate_myth();
		}
		else
		{
		    printlog("Denon turned on but input is $input, doing nothing");
		}
	    }
	}
	elsif ($line =~ /PWSTANDBY/)
	{
	    $denon_state = "off";
	    if ($input =~ /SIDVR/)
	    {
		printlog("Denon turned off and was last on MythTV, turning off");
		turn_off_myth();
	    }
	    else
	    {
		printlog("Denon turned off but last input was $input, not doing anything");
	    }
	}
      }
    }
}

sub END
{
    #print "Killing child\n";
    kill(9, $child);
}

exit;
___END___
#!/bin/bash

# $0 cmd [repeat]

for i in `seq 1 ${2-1}`
do 
	echo -ne "$1\r" | nc -q0 denon 23
	sleep 0.2
done

exit

PWON", "xon"
PWSTANDBY
PW?", "power-status"
MVUP", "volplus"
MVDOWN", "volminus"
MV62", "vol-18"
MV80", "vol+0"
MV98", "vol+18"
MUON", "mute-on"
MUOFF", "mute-off"
SIPHONO", "input-phono"
SICD", "input-cd"
SITUNER", "input-tuner"
SIDVD", "input-dvd"
SIVDP", "input-vdp"
SITV", "input-tv"
SIDBS", "input-dbs"
SIVCR-1", "input-vcr1"
SIVCR-2", "input-vcr2"
SIV.AUX", "input-vaux"
SICDR/TAPE", "input-cdr"
SI?", "input-status"
SDAUTO", "digital-in-auto"
SDPCM", "digital-in-pcm"
SDDTS", "digital-in-dts"
SDANALOG", "digital-in-analog"
SDEXT.IN-1", "digital-in-ext-in"
SVDVD", "video-select-dvd"
SVVDP", "video-select-vdp"
SVTV", "video-select-tv"
SVDBS", "video-select-dbs"
SVVCR-1", "video-select-vcr1"
SVVCR-2", "video-select-vcr2"
SVV.AUX", "video-select-vaux"
SVSOURCE", "video-select-source"
MSDIRECT", "surround-mode-direct"
MSPURE DIRECT", "surround-mode-pure-direct"
MSSTEREO", "surround-mode-stereo"
MSMULTI CH IN", "surround-mode-multi-ch-in"
MSMULTI CH DIRECT", "surround-mode-multi-ch-direct"
MSMULTI CH PURE D", "surround-mode-multi-ch-pure-direct"
MSDOLBY PRO LOGIC", "surround-mode-dolby-pro-logic"
MSDOLBY PL2", "surround-mode-dolby-pl2"
MSDOLBY PL2x", "surround-mode-dolby-pl2x"
MSDOLBY DIGITAL", "surround-mode-dolby-digital"
MSDOLBY D EX", "surround-mode-dolby-d-ex"
MSDTS NEO:6", "surround-mode-dts-neo6"
MSDTS SURROUND", "surround-mode-dts-surround"
MSDTS ES DSCRT6.1", "surround-mode-dts-es-dscrt61"
MSDTS ES MTRX6.1", "surround-mode-dts-es-mtrx61"
MSWIDE SCREEN", "surround-mode-wide-screen"
MS5CH STEREO", "surround-mode-5ch-stereo"
MS7CH STEREO", "surround-mode-7ch-stereo"
MSSUPER STADIUM", "surround-mode-super-stadium"
MSROCK ARENA", "surround-mode-rock-arena"
MSJAZZ CLUB", "surround-mode-jazz-club"
MSCLASSIC CONCERT", "surround-mode-classic-concert"
MSMONO MOVIE", "surround-mode-mono-movie"
MSMATRIX", "surround-mode-matrix"
MSVIDEO GAME", "surround-mode-video-game"
MSVIRTUAL", "surround-mode-virtual"
MS?", "surround-mode-status"
MSUSER1", "surround-mode-user1"
MSUSER2", "surround-mode-user2"
MSUSER3", "surround-mode-user3"
SSCUP", "cursor-up"
SSCDN", "cursor-down"
SSCLT", "cursor-left"
SSCRT", "cursor-right"
SSENT", "cursor-enter"
SSMEN ON", "system-setup-menu-on"
SSMEN OFF", "system-setup-menu-off"
PSMEN ON", "surround-parameter-menu-on"
PSMEN OFF", "surround-parameter-menu-off"

I hearby want to thank Wansview for giving me some of the above cameras for review (I bought some of them on my own, and after seeing my reviews, they asked me to test and review a few more). Note that while wansview cameras do not offer the sharpest 1080p pictures I've seen (Zavio and FI9900 win, even I hate foscam), the nice things I've written on wansview are not based on the free cameras, but the fact that they have always answered my support queries, including the technical ones showing issues with the firmware, and fixed the firmware after that (including making it work on linux and other other operating systems), while Foscam tells people that they're running the wrong version of windows, and that's it.
zavio truly sells good cameras, but sadly they cost more than double, which may be a bit out of reach for many people.

Zoneminder

One good page to know about is ispyconnect, which gives all the entrypoints for many cameras:

Camera in 2009

Dlink DCS900

Cameras in 2013/11

Foscam FI8904W

Wansview NCB541W

Foscam FI8910W

Because it wasn't wide angle enough, I got a 3rd party (cheap) wide angle F2.0 lens for it. It blurs the picture around the edges quite a bit, but gives me the shot I wanted:

Foscam FI8920W

Foscam FI8921W

I also changed the F2.8 lens to a wider dealextreme F2.0 lens that's blurry around the edges:

Ubnt Aircam

out of focus out of the box, this is kind of sad

this is only barely better than the 480p version but great wide angle

480p picture blown up to 720p to compare with 720p 'native'

Edimax 3115w

Zavio F3210

Cameras in 2015/08

Foscam FI9826PB

Foscam FI9805P

Foscam FI9900P

Anyway, here's what I found on the Foscam 9900:

If you guessed that I think Foscam sucks by now, you guessed right. First to me, they look like liars and cheaters by what really looks like buying fake reviews on amazon, and then in the last 2 years, they actually made their web interface worse since the FI8921W where you could at least login on linux and change settings.

While I'll repeat that life is too short to deal with this crap and give money to that company, I used jpeg URL ( /cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=user&pwd=pwd1 ) to make it work with zoneminder, and it works well enough. As other reviews have said, the optics are actually quite good, I do like the very wide angle picture without barrel effect:

Too bad that Foscam's firmware sucks so much, the optics are good now. If you need an outdoor camera, and value your time and sanity a few dollars, I'd recommend the Zavio B6210. If an indoor camera used outdoors with light weather proofing is good enough, try the cheaper and somewhat better Wansview NCM625GA/Q1 below (although its picture isn't as wide and show barrel effect):

Wansview NCM625GA (aka Wansview Q1)

Cons:

Pros:

Updates:

Info:

The 1920x1080 shots are truncated to 1280 for display on this page

Wansview NCM751GA (aka Wansview W1)

This camera was superseeded by the Wansview W2 which is both much smaller and cheaper. Honestly, the only advantage of the W1 is the onboard storage if you care about that. For remote capture support, the W2 will be a much better bet (and almost half the price).

The viewing anble is pretty narrow. That's either a good or a bad thing depending on your needs, but if you need wide, prever the NCM625GA if you can put it outdoors safely, or consider the foscam or a higher priced camera. The night vision is decent though:

The 1920x1080 shots are truncated to 1280 for display on this page

My camera was giving blurry pictures because the lens was mis-adjusted. I had to open it up and readjust the lens for the picture to a bit more clear.

Like the NCM625GA, it now comes with firmware that works fine with linux and any operating system, and the android app gets the camera working in no time after you scan the QR code.

Wansview K1

It's a great little camera. Just like its big brother, I installed the recommended iSmartViewPro on android, scanned the QR code on the back of the camera, and had it working instantly. The picture quality is very good and this is the widest picture of any camera I've reviewed so far (even if it comes at the price of barrel effect).
Please refer to my Wanview NCM625GA review for configuration details. The only real downside is the placement of the ethernet jack, making it hard to fit some ethernet cables unless you remove the flexible sleeve, but that's a manageable problem :)

If you have firmware 0.39 or 0.40 and install this firmware patch I got from Wansview (via the web upload interface), http://ipaddr/mjpeg/snap.cgi?chn=0 now returns a proper Content-Type: image/jpeg header and will work with Zoneminder and other software that expects a jpeg. If your firmware is 0.41 or later, it should just work without the patch.

It is the best 1080p camera you can get for that price, I'm quite impressed with it.

The 1920x1080 shots are truncated to 1280 for display on this page

Wansview W2

My camera shipped with firmware 0.42 which supports http://ipaddr/mjpeg/snap.cgi?chn=0 out of the box with a proper Content-Type: image/jpeg header and will work with Zoneminder and other software that expects a jpeg.

This is definitely a good alternative to the Foscam FI9900 if you are ok with a narrow lens in exchange for better firmware froma better company. However I'm not going to lie, the picture is not ultra sharp. It doens't look blurry but it feels like the sensor is not truly 1080p, or something is robbing a bit of resolution or sharpness.

The 1920x1080 shots are truncated to 1280 for display on this page

Wansview Q2

My camera shipped with firmware 0.42 which supports http://ipaddr/mjpeg/snap.cgi?chn=0 out of the box with a proper Content-Type: image/jpeg header and will work with Zoneminder and other software that expects a jpeg.

The Q1 picture is a bit more narrow and looks a bit more sharp

The Q2 picture is a bit wider and bit less sharp

Here are the other Q2 screenshots, they look fairly good at night;

Reolink RLC-410

Setup was a breeze, the one downside is because it's a PoE camera, it does support 12V input, but it does not ship with a 12V power supply. Thankfully I have a drawer full of those :)
The default picture was way too bright (over exposed) and the sharpening was turned up too high, making the picture grainy. On the last picture, I turned the brightness down as well as the sharpening, and the results are better. The lens is about as wide as Wansview Q2. *Update* a firmware update seems to have dramatically improved the picture quality, which to be honest, was pretty poor. The screenshots below are the old picture quality, I have not had the chance to get shots with the new firmware yet since my camera is installed outdoors at the moment.

Here are screenshots (resized to 1280, but you can click on them to get the full original size). Again, these are very poor quality and a new firmware fixes those:

Wansview K2

So, for that limited price, you still get most of the typical wansview interface without any sdcard or recording support, but you can tell the CPU is slow. It's slow enough that you have to wait for the web page to load, and also slow enough that a reboot takes a while. Last, but not least the picture is only 720p, not 1080p, and when comparing a downsided picture from a K1 and a native 720p picture from the K2, the K2 picture is not as sharp but still very usable
It's far from a perfect camera, but again, you only paid $30 (my favourites from Wansview are definitely K1 and Q1). If you want a camera that's more capable, the K1 is a very good small camera, so get that one instead. The choice is yours :)

Here are the screenshots in native 720p:

Using cameras outdoors

Foscam FI9821W and Zavio F3210, along with an IR booster for better distance vision at night with the Zavio

we don't exactly have harsh winters here, or really bad rain, so part of my equipment is just outdoors under the gutter

I then have ethernet and power going in my yard to the malibox

I do use a waterproof box for equipment outside (includes an insteon iolinc to control the mailbox and flood light if you open it)

very tight fit, but I used a 7A 12V power supply to power the gigabit switch, floodlight (12V LEDs), and 4 IP cams

this should take care of any mailbox thieves :)

Actually, the lock is not from lockstate, they simply resell a Taiwanese product from Ez Set which is available through other channels like QVC.

User manual: https://support.remotelock.com/hc/en-us/articles/360001749972-DB-500R-User-Manual

To be fair, many locks are unsafe and can be hacked. Also, the default key lock can likely be unlocked with a bump key, making any fancy unbreakable electronics a bit worthless anyway. So as long as you don't expect a high security lock for $100, let's continue... (but yeah, since I changed their key with a better one that can't be brute forced so easily, I'd feel better if I knew that the RF code can't be trivially sent by a van in the street). It's very possible that Lockstate doesn't know either and only the Ezset folks in Taiwan know.

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 event 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, many comments make it clear that the batteries never last long enough, 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.

By the way, if you want to debug RF, the LS-DB-500R (aka Ez Set), transmits on 433.92Mhz.

Last, but not least, the lock has another issue where it locks/unlocks the deadbolt on power reset. This is not a huge problem if you are using batteries, but with house power, that means that a power outage would unlock your door for a brief time when the power comes back up. Not so great... So I hacked mine with a Voltage regulator, put the lock behind it and also connected the batteries behind a diode to give backup power if the wall power goes away (diode stops the wall power from trying to recharge non chargeable batteries):

Also, I figured I'd show the voltage regulator I use to power the door. My original one was a 5V Vreg and it just wasn't enough for the lock. It would often complain that the voltage was too low.
I now use a 6V LM regulator and add a big diode that prevents both backflow and drops the voltage by only 0.3V, giving me 5.7V. The door is very sensitive to low voltage and will complain loudly if your voltage drops to 5V or less. The batteries can give up to 6.2V or so, and their voltage gets dropped to 5.5V by regular diode that drops 0.7V. The end result is that the battery voltage is always lower than the power supply, and the batteries never power the lock unless the power supply is disconnected (which in my case means a power failure):

end result

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.