Introduction

See the separate page for documentation on the HouseMade software

2024

20240206:155325 Building the replacement lizard server

We (son Nathan and I) are replacing our lizard file servers with a SeaweedFS server. Rather than repurpose the existing hardware, we are creating a new server frame, populating that and getting it operational, and then migrating data from the lizard to the seaweed systems. Here's my new system (geelong) specifications:

chassis ($219)

TGC - TGC-32380: TGC Rack Mountable Server Chassis Case 3U, 380mm Depth, NO PSU, 7 x 3.5 " internal HDD drive bays, 2 x 5.25" external drive bays

power supply ($289)

MSI - MPG A1000G PCIE5 MSI MPG A1000G PCIE5 1000W Power Supply, 80 PLUS GOLD, Fully Modular, 2x EPS, 6x PCI-E, 1x PCI-E 5.0, 12x SATA, 4x Molex, DC-DC Module Design, Zero RPM Mode

motherboard

MSI B550 Tomahawk AMD Motherboard

processor

AMD Ryzen 7 5700G 8 Core 16 Thread Processor 4.6GHz Max Boost, 3,8 GHz Base

storage

4 x 18TB Western Digital 3.5in sata drives

2023

20231127:155202 Ethernet Wiring

While looking at the cellar wiring, I decided that it was time to document all the cat 5 cabling arund the house. This was completed not long after we moved back to 5 Fran Court after the house renovations, around February 2018, and documentation has languished until now. Every room in the house has at least one cat 5 connection to the cellar computer rack, and this necessitates some form of taxonomy.

Floors are labelled from 0 (bottom floor) to 2 (top floor), and rooms by the first letter of their name. The list of rooms is B (Bedroom), S (study), L (Lounge), C (Cellar), M (Meals), J (Jemima), T (Tabitha), G (Guest), D (Dining). A given type of room may appear on more than one floor, when the floor number distinguishes it.

Patch panels are distinguished as numeric (Netgear 48 port, 1G), N (Netgear 16 port, 10G capable), and TP (TP-Link, 10G capable).

(Updated 20240128:120242)

2021

20210504

The house computer (a Beagle Bone Black) has been decommissioned, and replaced by a Raspberry Pi 4, which has taken over all the house computer functions (hardware server, relay server, event server, and event scheduler - see House Computer for further detail).

This necessitated rebuilding the house computer platform to accomodate the increased number of relays configurable by the Raspberry Pi - now a total of 16 relays in all, with 2 inputs.

2016

20160406:122904 House Computer Update

Writing the section immediately below prompted me to check the previous writings and realise that much has changed since Apr 2015. What has changed?

1. The house computer is now lilydale, an Acer laptop running Ubuntu 14.04. This follows the failure of the ringwood and garedelyon systems in Jan 2015. (See the documentation for further details.)
2. All remote inputs now go through a powered USB 7-port hub, since lilydale has only 2 USB ports.
3. A new script has been written to resolve the allocation of USB devices to system ports. This is still not perfect!
4. Interfaces to drive the chicken door have been installed. Again, this is recorded on a separate page, see the chicken door documentation.

20160406:112930 Electricity Monitoring

For some years (since installing solar panels) I have been recording daily electricity consumption by reading the house meter on a daily basis. Fortunately, solar generation is recorded automatically by an RS232 connection to the solar controller. I did think that with the advent of smart meters, the need for manual reading of the meter would disappear, but no, power companies have dragged their feet on providing on-line information about domestic power consumption. (See, for example, this discussion, now somewhat dated.)

I did buy an Efergy CT clamp and transponder, which does interface to my home network, but it only interacts with the user through a web page interface. I have tried screen-scraping this to get real-tie data, but it relies upon a login protocol which I have yet to crack.

Chris Avram tells me that Zigbee is the way to go, but if you checked the second level links from that link above, you will find that there is nothing much on offer there, either.

So technology is inexorably pushing us backwards!

2015

We were away from the house during the first three months of this year, and disaster struck while we were away. Both garedelyon and ringwood died, the latter with a battery that had slowly exploded its internals, knocking out the hard drive. To some extent, this was a mixed blessing, as my son Nathan had given me two BeagleBone Blacks for Xmas, with the comment that these would allow me to replace the whole house computer system. Did he know something I did not at the time? So this year's blog starts with getting the BeagleBone replacement system up and running.

I only needed one BBB for this purpose, so one was duly installed in place of garedelyon and ringwood, and named orsay (after the Gare d'Orsay in Paris, another railway station, but unlike garedelyon, now defunct - get the irony?) The other spare system was called bastille, an also defunct railway station in Paris, and which is used as a bench test system for experiments off-line.

The BBB comes with only a single USB server port, so I used a powered 7-port USB hub to provide power and data to all the serial devices needed for the house computer. Currently these are:

(bus/port 1/1 is the 7-port hub itself.)

The first task was to get the Arduino connection working to driver the 12-relay board.

20150430:174231 arduino

There was no arduino application on the BBB, so time to install one:

        apt-get install arduino
      

But it gave a number of errors, suggesting that my system was not up-to-date, so I tried: (20150430:175112)

        sudo apt-get upgrade
      

This gave a number of errors, viz:

        W: There is no public key available for the following key IDs:
        9D6D8F6BC857C906
        W: There is no public key available for the following key IDs:
        7638D0442B90D010
        W: There is no public key available for the following key IDs:
        7638D0442B90D010
      

According to http://www.linuxquestions.org/questions/debian-26/there-is-no-public-key-available-for-the-following-key-id-705108/ , you should then (20150430:175907)

        sudo apt-get install debian-keyring
        sudo apt-key update
      

          sudo apt-get upgrade
        

Then (20150430:180341)

          sudo apt-get install arduino
        

20150501:102459 hardware clock

Along the way, I discovered that my hardware clock was wrong, so I reset it using (20150501:102459)

        sudo hwclock --set --date="2015-05-01 10:24:00" --localtime
        sudo hwclock -r
      

The first command sets it to 10:24 am on 1 May 2015, and the "--localtime" option forces it to regard this time as a localtime value. The second command then reads the hardware clock as a check. To check that localtime is indeed being used, run: (20150501:102715)

        more /etc/adjtime
        3764748.465676 1430439840 0.000000
        1430439840
        LOCAL
      

and the "LOCAL" confirms that local time is indeed used.

I installed "locate": (20150501:154752)

        sudo apt-get install locate
      

I installed "emacs": (20150501:160513)

sudo apt-get install emacs

Now back to the Arduino testing! I created an enviroment setup script "setupMake.sh" with contents (20150501:160710)

        cat >setupMake.sh
        export ARDUINODIR=/usr/share/arduino
        export BOARD=atmega328
        export SERIALDEV=/dev/ttyUSB3
      

I downloaded arduino.mk from http://ed.am/dev/make/arduino-mk/arduino.mk and placed it in the arduino program directory

Running the make program then succeeded in compiling my arduino code: (20150501:161908)

        ajh@bastille /home/ajh/Computers/House/RelayDriver8way 104 $ make -f arduino.mk
        mkdir -p .dep/./
        /usr/bin/avr-g++  -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=100 -DUSB_VID= -DUSB_PID= -I. -Iutil -Iutility -I /usr/share/arduino/hardware/arduino/cores/arduino -I /usr/share/arduino/hardware/arduino/variants/standard/   -c -MMD -MP -MF .dep/RelayDriver8way.ino.dep -o RelayDriver8way.o -x c++ -include /usr/share/arduino/hardware/arduino/cores/arduino/Arduino.h RelayDriver8way.ino
        /usr/bin/avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p RelayDriver8way.o .lib/arduino.a -lm -o RelayDriver8way.elf
        /usr/bin/avr-objcopy -O ihex -R .eeprom RelayDriver8way.elf RelayDriver8way.hex
        rm RelayDriver8way.elf

        ajh@bastille /home/ajh/Computers/House/RelayDriver8way 105 $ ll
        total 48
        -rw-r--r-- 1 ajh ajh  1379 Feb 19  2014 RelayDriver8way.ino~
        -rw-r--r-- 1 ajh ajh 16835 Apr 30 17:34 arduino.mk
        -rw-r--r-- 1 ajh ajh    91 May  1 16:00 setupMake.sh
        -rw-r--r-- 1 ajh ajh  1386 May  1 16:10 RelayDriver8way.ino
        -rw-r--r-- 1 ajh ajh  3796 May  1 16:10 RelayDriver8way.o
        -rw-r--r-- 1 ajh ajh 11902 May  1 16:10 RelayDriver8way.hex
      

This was progress indeed!

Week of 20150503

I did not write up this blog during this week, as it turned out to be one of the most frustrating weeks in the story so far. However, I shall endeavour to reconstruc things as I recall them.

On the Saturday (2 May) I noticed that the system had died at 06:26. Well, it hadn't actually died, but it had hung in some way with the CPU activity light permanently on. It had been hanging or dying at various stages in the past, but this was the first time I noticed the exact time at which it died. I looked back at the logs for the previous day, and found that that was the exact time at which it had died as well. My first thought was that it was one of my cron jobs, but I had no cron job starting at that time. I puzzled over this until the following morning (3 May), when it died again at 06:26. All too much of a coincidence. I dug into the system cron jobs, and there, in cron.daily was the culprit time, 06:26. I changed it to 07:26, and waited.

Monday came and went, no crash. Tuesday, ditto. Wednesday, ditto. Thursday, eureka, crash at 07:26! It was the cron job, but why? And why the 3 days of no crashing?

The Friday (8 May) it crashed again at 07:26. I decided to remove some of the cron.daily jobs. This is easily done by simply turning off the execute permissions, so I disabled the ones that seemed least likely to affect the proper functioning of the system: apache2, aptitude, locate, logrotate, man-db. apache was chosen since I now had flask running effectively, and there was no need for a separate web server. I also ran apache2ctl stop just to make sure. My theory at the time was that it might be some conflict that arose between a flask activity and a concurrent apache one. Nathan offered another theory that it might be a disk error being generated by one of these cron jobs.

It is now Wed 13 May, and the system has not missed a beat since. Today I re-instate two of the cron jobs, logrotate and locate, and see if they cause any conniptions tomorrow.

20150513:145857

Now that I have several days of contiguous solar logging, I thought I would rev up the solar plot. Very little change was need. I re-inserted the image link into the solar section part of the house web page, and revised the filenames in the solarplot.py code, then added it to EveryMinute.sh in the 5-minute section. And off it all went, with nary a glitch!

2014

20140128

Finally! We have a working cron job watering system! The hassle with the cron jobs not working was that I was defining a number of variables to specify the various directories in use. Turns out that you cannot use variables to define new variables, as the substitutions are not made in the definitions. So HOUSE=$HOME/Computers/House does not work - it just gives HOUSE=/Computers/House, which is clearly wrong. No error messages given - clearly a trap for young players (and even old players!) Sometimes Unix (this was actually Darwin!!!) can be very frustrating.

20140125

Managed to rebuild flinders apache server, and get all cron jobs and the like running again. Spent some time installing the Oldfield make script on flinders, and finally got it to load and run the Blink program!! However, no joy with the relay driver, which uses the serial port interface, and I could get no sense out of it. It was clearly talking to the Arduino - every time I sent something to /dev/ttyUSB0, the relays would all turn off, then all on again, as tho' it was doing a reset cycle. But nothing better than that.

So to plan D. Using the new ACER laptop with an up-to-date Ubuntu install (and, perhaps significantly, the Arduino IDE). It works! So I have mounted it where central used to be, wired it and the relays in, and we now have working programmable watering systems! Yay!!!

20140124

Absolute disaster today! I killed flinders by crapping on one of the libraries, while trying to upgrade it with the arduino software.

Decided to string a USB cable from flinders through the ceiling fan to the Arduino, now mounted on the house computer panel. That meant getting the make files working on flinders, and I thought I could get away with copying the files from wolseley. But I did not take enough care in copying the library files, and overwrote some key system libraries.

I have since re-installed the flinders system, but there is still a long way to get it back to where I was at 3pm today. And I was this close to getting the Arduino driver running!

20140115

Managed to install gtkterm on montparnasse, but I get:

        ajh@montparnasse /home/ajh 1 $ gtkterm
        (gtkterm:2708): Gtk-WARNING **: cannot open display:
      

Cannot see at the moment how to redirect the display

20140114

Managed to upgrade to 4.0 relatively OK, but it did not solve the problem - which is that the package requires the perl Serial device module, and I cannot successfully download it. The downloading worked OK for wolseley (Ubuntu 13.10), but seems to fail on montparnasse (Debian 4.0)

Tried building a ubuntu 12.04 system to boot from USB stick - fails at boot time.

Looked at booting from network - complete misalignment between manual and system (e.g., no /etc/dchp3/dhcpd.conf file!)

This web page is promising: http://blog.mypapit.net/2008/05/how-to-use-usb-serial-port-converter-in-ubuntu.html

20140113

Successfully build a non-GUI way of loading and running an arduino script from wolseley. I used a blog commentary by Martin Oldfield (http://www.mjoldfield.com/atelier/2009/02/arduino-cli.html) It was not so straightforward getting it to work on montparnasse, since it did not have all the relevant software. So the next step is to upgrade the OS (Debian 3.1, aka "Sarge")

20140107:230504

today several significant steps were made:

1. The new house.py "HouseMade" cgi script generates a web page (on wolseley).
2. the weather station data is being collected (on wolseley) via the wx200d daemon.
3. heating logging and plotting is working
4. There were serious problems with the wx200 front end. Firstly, something happened to the long usage print strings, and they do not get processed correctly. Secondly, remote calls via a web page were being misinterpreted, for reasons unclear.

20140106

Success! The weather station is now talking to wolseley. The problem was that the serial port was buffered, and it should be unbuffered.

This page is copyright, and maintained by John Hurst.		809 accesses all since 02 Feb 2022
Local servers: Localhost Newport Burnley Geelong Jeparit Reuilly Spencer (accessible only on local network.) Public Web Servers: ajhurst.org ajh.co ajh.id.au (not all may be active.) Dynamically generated at 20240418:1715 from an XML file modified on 20240206:1128, by index.py version 1.6.5.