Since our new place has a rather large hen house we decided to make use of it and got ourselves some indian runner ducks. These ducks are a bit unconventional
because they walk almost upright (almost like penguins) and are rather fun to watch because of that.
They should also be great egg layers but I can’t comment on that yet since they are a bit young for that.
PS. in case you don’t get the dogmask reference here’s an explanation.
I have two Linksys WRT54g wifi APs at my grandparents’ place that have been running since May 2005. The one facing the Internet is connected to a 24 dB parabolic wifi (2.4Ghz) antenna that is directed towards a tower 8km away and the other one is connected to an omni antenna and is configured as an open access point.
The other end of the link as (not) seen from the position of our antenna. It's usually not visible with the naked eye in the daylight but the lights are visible at night.
Our improvised antenna tower
These two WRT54g-s are situated in a garage and do not have any special kind of enclosure. The garage is not heated and has always basically the same temperature that is outside. So it has seen days with temperatures below -30 C and several weeks with the temperature constantly around -20 C. It has pulled through all this without any problems. I only had to replace a couple of power supplies so far because of the lightning but otherwise that installation has required no attention whatsoever. I wish all of my gear was that reliable.
Actually it has required so little attention that it has been years since I last attempted to log into these routers. They are still running an ancient OpenWRT build from 2005. It turns out that the modern versions on the openssh client are not able to work with the old version of the dropbear ssh daemon that I have in the AP’s.
The openssh client in the verbose mode will give you something like this if you try:
debug1: Remote protocol version 2.0, remote software version dropbear_0.45
debug1: no match: dropbear_0.45
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
Connection closed by 192.168.9.1
A nice and simple workaround that I found is to use the SSH client that the dropbear package itself provides (called dbclient).
PS. I plan to retire one of these APs soon because I have a Ubiquity Bullet 2 lying around that is a much better fit for such environments and I believe that it’s better to replace these before the inevitable failure comes along.
With a lot of help from my friend Kalle (actually he did ~95% of the work) we managed to get window automation running.
We haven’t had time to repackage and rewire the control panel so it looks a bit hackish at the moment
The windows are actually controlled from the Beagleboard in the garage over WiFi. The Beagleboard also has an IPv6 address so we are able to directly access it from anywhere in the world even though it sits behind several NAT gateways.
Here’s a high level overview of how the automation is set up at the moment:
And here’s a bit more detailed schematics of how the electronics in the greenhouse are connected:
I recently bought myself a couple of Plugwise smartplugs that can be used to control and measure power usage over the wireless ZigBee protocol. I wrote a bit about these and the alternatives in the last post.
The Home Start kit consists of a USB stick that is reasonably enough called Stick and two smartplugs: Circle and a Circle+ (a circle that has ZigBee router capabilities). The Stick takes care of the ZigBee communication and provides the operating system with a simple serial port interface.
The Circles are really nicely designed and reasonably priced at somewhere around 40€ per Circle (125€ for the kit), which is a lot cheaper and smaller than the alternatives mentioned in the previous post.
Plugwise Home Start kit
Plugwise Circle
The only problem with these things from my perspective was that they use a proprietary communication protocol and you are basically supposed to use their Windows based software for managing them. I haven’t used Windows in a decade or so and I’m interested in integrating it into my own system instead of using some special GUI app so I had to find some other method for communicating with these things. Luckily most of the protocol has been reverse engineered by Maarten Damen so I just wrote my own Python library called python-plugwise that implements this spec. It’s available under the MIT licence here.
The library also contains a small command line utility that can be used to test the basic functionality of the plug (measuring power, switching on/off). The Circles also support uploading an on/off switching schedule and reading the power usage log so you wouldn’t have to keep a computer constantly running just to do these things. I haven’t yet implemented these functions since I control these and other things from the Beagleboard. It is a very small and low powered ARM based fanless computer that uses around 3W of power so it doesn’t waste much resources to keep it always on.
I haven’t really tested the working range of these things but currently the Stick is about 7m away from both Circles and there’s a brick wall and a door between them and the communication seems to be stable so far.
Anyway here’s the first quick and dirty RRD graph of power usage from a couple of appliances:
I have lately spent considerable amount of time on reading various home automation related stuff from the energy efficiency front. With a goal of finding some solution that would allow me to measure and control electricity usage down to specific device. The idea being that in general people have found ways to reduce their energy consumption by ~20% if they see where it’s actually going. One interesting case study is here which shows that almost 1/4 of the energy in the measured office building is used up by the printers and coffee&vending machines account for almost half of the total energy usage.
In my case I believe I already have a pretty good idea what to optimize and I just need something cheap and open enough to do it.
I concentrated ZigBee smartplug solutions since it’s just really convenient to connect it anywhere without having to deal with the wiring and I already have some ZigBee stuff around for the greenhouse controller.
I came up with the following options:
Then there’s the more fundamental question if controlling your devices should be done over such wireless protocols at all since it makes attacking your network that much simpler. The low power aspect doesn’t really help much against that since similarly to Bluetooth long-range attacks it can easily be worked around with well directed powerful antenna. I haven’t really looked well enough at ZigBee security aspects and neither am I security expert, but judging by how far more evolved WiFi security has been taken down several times I wouldn’t be hopeful that ZigBee security stands for long without major holes. Some attack tools are already available and the referenced presentation describes several awfully simple attacks (even simple replay attack is effective against several products!).
I don’t care much if an attacker can read my sensor network and determine how much power I use or what is the temperature in each room but being able to control central heating, sauna, water and gas valves etc. remotely is quite another thing. Another rather interesting question is what do you do when the protocol that is embedded in chips in wall sockets, lamps, switches and whatnot becomes trivially exploitable? Replace the whole thing? Reflash the firmware over the air? Some of the security stuff can be implemented in hardware for efficiency so firmware replacement wouldn’t help even if you could do that…
So in general I think I will use ZigBee for things that I don’t care about and for which randomly turning on and off doesn’t have any bad consequences. For critical things that can burn out or burn down the house if kept in too long I will use well shielded cable or no computer control at all.
At the end of every year Makezine publishes a list of most interesting opensource hardware projects. And here is the list for 2010. Descriptions are a bit terse this time around but there were several new discoveries even for me even though I follow progress in open source HW all year round.
For me the most interesting projects from that list are Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking and the Bus Pirate.
Hopefully I can use Freakduino to replace Arduino + XBee combo that I currently use to communicate with greenhouse and the Bus Pirate looks just interesting and might be helpful sometimes. Pandaboard is missing from that list for some reason, probably because it was released so close to the end of 2010 and is already backordered well into 2011.
Sometimes every programmer finds something in the code that shouldn’t do anything, but in reality is essential to the correct functioning of the code because of some side effect. Someone really should make a site that gathers these since they are usually really interesting and you can learn much from the reasoning behind them.
One of the first of encounters with these subtle no-NOOPs was back when I was at university and had to hack something together for a deadline that was just a few hours away. The program worked fine under the FreeBSD that I was using for development but crashed under the Solaris where it was supposed to be run by the supervisor.
The bug seemed to be a Heisenbug since it went away when I added printf()’s to see what’s happening. I inferred that it must be something that corrupts the stack and I added some debug variables along with printf’s. These must have provided enough buffer space on the stack to avoid overwriting critical stuff.
Since I didn’t have any time left before the deadline to actually debug it I just added declaration of a small char array and set some of it’s element so the compiler wouldn’t complain that it was unused. This stabilized the program even though in a extremely ugly fashion. Of course I also mentioned this problem in the report and fixed the real bug later.
The next one is probably known to every embedded programmer. If you want to wait for something for a very small amount of time and do not have any operating system that would provide you with sleep() or other similar facilities the logical thing is to do a busy wait – basically a simple loop similar to:
for(int i=0; i<1000; i++);
The only problem was that it didn't work. It took me almost an hour before I was desperate enough to check the compilers assembler output and saw that the loop was just optimized away since compiler inferred it wasn't necessary.
The next one comes from a embedded platform browser that I use at work. All the pages that used the device specific JS APIs had the following line as the first JS line on every page:
var v = document.width;
The v variable was never used anywhere, but the code wouldn't work without that line in place since some of the platform specific objects were missing.
So executing that line probably initialized JS engine into some good state.
And the last one is from the wonderful world of JS where one of the things you have to do to work around some of the same domain origin policy limitations is this:
document.location = document.location
I have read the explanation several times and I still can't fully understand why would it change anything.
Beagleboard now seems to have a sister project called Pandaboard which is similar in it’s form to the Beagleboard designs but uses more powerful dualcore 1Ghz OMAP 4430 CPU and has 1GB of RAM.
Size is ~11x10cm and like beagleboard it’s fanless and actually doesn’t seem to have any heatsinks too. Since it should be capable of decoding h264 videos at 1080p resolution it will probably be widely successful with the HTPC crowd.
It even has an ethernet port, 802.11b/g/n wifi & bluetooth directly on board so there’s no need to use USB networking adapters that we had to use with the Beagleboard.
Power consumption of the beagleboard was around 3W when playing videos so I speculate the pandaboard uses at most 6W.
I will probably buy it for home automation & robotics experimentation. Also hacking it will probably become a good Meego devel platform.