-
Notifications
You must be signed in to change notification settings - Fork 130
Embedded
toc The misterhouse install instructions say //"In theory, much of the function should run on any platform that can run Perl.//". Let's test that theory...
Estimated U.S. power use: $2/yr. See the Pi page
Estimated U.S.power use: $5/yr. See the MisterPlug page
Estimated U.S. power use: $4/yr. The NSLU2 is a Linksys router, but a search on Google might suggest that most of them seem to be in the hands of linux folk who have 're-tasked' them to run a standard linux distro. Cost is about £60 (round about $100). The processor is a 266MHz ARM device, with 32MB of RAM on board, power consumption is a miserly 10W approx, and there is 1 ethernet port and 2 USB ports (with a TTL-voltage 'real' serial port solderable on inside!). As most of my misterhouse hardware is interfaced by RS-232 and USB, this looks like a good place to start!
Note that there is no display on these devices, this is just a 'back end' which can be accessed by a web or phone interface on another device. All setup and config is done via a ssh link. In my case it will hopefully replace a 50W 500MHz Pentium desktop PC so it doesn't need to be switched on all the time.
The result of the installation detailed below has now run for several weeks without problems, although the slooooowwww rrd graph update issue needs more investigation. This will be a particular issue as I note the newer version of mh generate the rrd graphs on demand- that will be a very long wait!
See http://www.nslu2-linux.org for details of the Linux options on the nslu2 Install debian as per instructions at http://www.cyrius.com/debian/nslu2/install.html. I started with a 1GB USB FLASH disc which was easily to hand, but have now moved to an old 2GB hard drive in a USB to IDE enclosure.
I can't even remember how to install misterhouse from scratch, so I've started with my existing working misterhouse-2.102 installation, which I tarred up and copied across to the NSLU2: code me@existing:$ tar -czvf /usr/local/misterhouse-2.102 ~/snapshot.tgz misterhouse@nslu2:$ scp me@existing:snapshot.tgz . misterhouse@nslu2:$ su - Password: root@nslu2:# tar -tzvf /home/misterhouse/snapshot.tgz root@nslu2:# cd / root@nslu2:# tar -xzvf /home/misterhouse/snapshot.tgz root@nslu2:#
code There are plenty of install guides for misterhouse, if you need to start from scratch.
Edit the /etc/init.d/misterhouse file to include the debian /lib/lsb/init-functions Start misterhouse and watch the log files code /etc/init.d/misterhouse start && tail -f /usr/local/mh/data/logs/mh.log code and watch the error messages go by...
Error, perl RRDs.pm is not installed. code apt-get install rrdtool apt-get install librrds-perl
code Error in use GD: Can't locate GD.pm in @INC Initially, edited /etc/misterhouse.private.ini to add gd = 0 (GD does pretty graphics, not needed just now). In January 2011, installed GD: code sudo aptitude install libgd-gd2-perl libgd-text-perl
code At this stage, after about 1 hour's effort, it runs! top shows CPU is running about 42%, 30MB memory and 75MB swap in use, so it's not fast. It's also merrily writing logs to disk, which will not make the USB stick happy, if I wasn't expecting to use an IDE drive instead, I'd do something about that... ... but later that day after a few hours, dozens of mh processes have appeared, it slows to a crawl (30 sec between responses to keyboard input on the remote ssh session) and load average is 16 (?!?!?). code apt-get install psmisc code to give me a killall command for when that happens again. Killall is also used by the /etc/init.d/misterhouse script so I can use it properly now as well... More positively, I added a dummy 'digitemp' shell script which seemed to stop the proliferation of mh processes, so it now runs at 45% cpu, 54% memory, with 30MB memory and 30MB swap, load average approximately 0.5, round about 10 misterhouse passes per second. Once the iButton interface is added, I'll add the real digitemp.
Next stage is to add a USB to multiport serial device (like http://cpc.farnell.com/jsp/search/productdetail.jsp?sku=CS12792%29 to give me the necessary serial ports for CM11 (X-10), Weeder (misc digital I/O), iButton (temperatures etc) ...
For an ubuntu-user, the lack of sudo is tiresome, so I put it on too... code apt-get install sudo code Then digitemp to talk to the 1-wire network code apt-get install digitemp code
- //[Note]//**
code to stretch the formatted filesystem over the new partition. Now enable the new swap partition and format the remainder as a shared data partition: code sudo mkswap /dev/sdb2 sudo mkfs.ext3 /dev/sdb3 code Hopefully at this point you can reboot the box with the memory stick removed and it will boot off the newly installed hard disk instead.
Also installed the new 4-port USB serial port (see part number above). The box says suitable for Linux >2.4 and they were indeed immediately recognised and assigned to /dev/ttyUSB[0-3]. The multiport USB serial device helpfully has lots of diagnostics LEDs (although they are undocumented which is less useful!). Each port has 2 LEDs for power, then 1 for transmitted data and 1 for received data. This is marked on the PCB silkscreen. After trying code echo "hello" >> /dev/ttyUSB0 code and repeating for ttyUSB[1-3], I noticed that the numbering on the front panel (each port has a number of dots, from 1-4) is the opposite way round to the linux device numbering- the port with 4 dots is /dev/ttyUSB0, the one with 1 dot is /dev/ttyUSB3. If it weren't for the copious LEDs, that might have taken a bit longer to work out...
With a weeder board, a CM11 (that one didn't seem to work at first, not sure why) and a link45 from http://www.ibuttonlink.com to replace my aging DS9097
Needed to code rrdtool dump weather_data.rrd >> rrd.xml code on the original installation, then copy it to the NSLU2, then code rrdtool restore rrd.xml weather_data.rrd code to recreate the new database. This is because rrd databases can't natively be transferred between different architectures (i386 to ARM in this case), probably because the data is stored optimally for speed/space instead of portability. Next, the RRD database is not being updated. The temperatures are being read OK by digitemp, once weather_common.pl was enabled they are displayed on the status line but not updating weather_data.rrd. That turned out to be a mixup between different installed versions of weather_rrd_update.pl. Next, it appears to be updating weather_data.rrd (file timestamps are incremented) but not producing png files. Weather zoom works OK, just not the routine production of graphs... but it takes 40 minutes to do a single graph. Changed update rate to 700 minutes (5 graphs, 3 sensors, 40 mins each) to see if it is just running out of time... but still haven't found out the reason for such a long graph-generation time!
After enabling debug for weather_rrd_data, I get an error as in http://oss.oetiker.ch/rrdtool-trac/ticket/112 which is resolved in the latest source of RRDs- downloaded RRD source for 1.2.26 and did an code apt-get install build-essential code to get the C compiler etc Nope, it's still just as bad... Finally, I turned debug on for rrd in weather_rrd_update.pl and extracted the RRDs:graph call as a text file, then edited it to "rrdtool graph" format so I could re-run it outside misterhouse. running it with vmstat at the same time shows 96% system CPU usage for the full run time- not good! Some more hunting pulled up https://lists.oetiker.ch/pipermail/rrd-users/2008-February/013730.html which suggested that GPRINT (which prints max, min etc labels within the graphs) could cause long delays. Sure enough, I removed all the GRPINTs, and it completed the graph in a few seconds! Remove all the GRPINT from weather_rrd_update.pl- and it works, just a few seconds per graph!
The biggest problem right now is that if the power is cut, it needs a manual button press on the NSLU2 to bring it back up again, and also a manual button press on the USB drive to power it up. I know there is a workaround for the NSLU2 (see the NSLU2 wiki ), but any ideas for the USB to IDE hard drive would be very welcome (leaving the button permanently pressed doesn't work, it needs to transition to pressed for the drive to power up, and I'd rather avoid having to rip the caddy apart to add a 'button presser' powered from the USB power line...)
Originally installed in August 2007. Now, September 2010, it's still running perfectly, now on misterhouse-2.104. The only thing needed in that time was a new power supply, the existing one must have had some power behind it but was collapsing after a little while on load, so LEDs came on but the boot failed half-way through or after a short time running.
I have an IR 'bus' based on TSOP1838 devices around the house, feeding IR emitters (custom hardware, simple 38kHz oscillator driving an IR LED- see Nigel's IR extender page for a bit more detail). The NSLU2 wiki IR page shows simple example circuits to connect in to an NSLU2 so LIRC can use it to transmit and receive IR. I modified the design a bit to fit inside the NSLU2 instead of all being outside, my transmit side has a 1K resistor in series (so light output is very low) and the receiver TSOP1838 is mounted right beside it inside the NSLU2 case to feed the NSLU2 output onto the bus. The TSOP1838 signal (connected to CTS2) and ground pins are connected to a 3.5mm mono jack socket on the rear of the NSLU2 (just above the Ethernet socket, offset to one side to fit in some clear space!) so a 3.5mm mono jack can be plugged in and connected in to the house IR bus. Next, upgraded to lenny (see Rob Tucker's guide), which went very simply (but slowly) as etch is no longer supported (so it was not straightforward to add the lirc packages, and the upgrade needed to be done some time!) Then install lirc and its dependencies and lirc-modules-source (to get the kernel modules, selecting 'Other' for each offered option)
- sudo apt-get install lirc lirc-modules-source
- sudo depmod -a
- sudo aptitude install linux-source kernel-package
Estimated U.S. power use: $6/yr. Pete Flaherty I am currently working on making misterhouse run on a Linksys WRT160NL. I have an appropriate image built, and am working on scripting the whole thing up, so all you'll need to do is install a package :)
I have the box up and running a core version of misterhouse with CM11 (via USB Serial), and have made some overlay files to get the initial settings in place (disabling a few problematic functions, TK and GD off , as well as the beginings of a startup script). The system uses a pivot Root to mount the main file-system on a usb stick (and yes USB hubs are supported). When you have a memory stick in it will use that as the main file-system, if it is not present, the core (on system) memory is used as the file-system, and act as only a wireless router .... I will be automating the whole process with an installable package, that will (amongst other things) Pull the current subversion copy from sourceforge, adjust the ini parameters , and install the startup scripts.
Performance is pretty good, and will vary with particular modules enabled (as is with any Misterhouse installation )
- Logs and temporary files. Looks like some (if not all) will need to be copied to and from a ram file-system (so we don't toast usb flash too quickly), but the jury is still out on exactly what and even if its totally necessary, as well as rotation and update intervals.
See theBeagleBone Black