The Home Computer Page

Introduction

See the separate page for documentation on the HouseMade software

Blog

20160406:122904 House Computer Update

Writing the section immediately below prompted me to check the previous writings and realise that much has changed since Jan 2014! 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!

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.

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")

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

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

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!

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!!!

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.

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 device file device type purpose
1/8 /dev/sda1 1TB external hard drive /Volumes/Black5
1/7 /dev/ttyUSB3 Arduino relay control
1/6 /dev/ttyUSB2 PL2303 (RS232-USB cable) tank
1/5 /dev/ttyUSB1 PL2303 (RS232-USB cable) weather
1/4 /dev/ttyUSB0 PL2303 (RS232-USB cable) solar
1/3 spare
1/2 spare

(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
      
then (20150430:180215)
          sudo apt-get upgrade
        
which removed the public key errors.

Then (20150430:180341)

          sudo apt-get install arduino
        
which seemed to work, but I did not have time to test this thoroughly.

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!

This page is copyright, and maintained by John Hurst. 299 accesses since
23 Feb 2016
My PhotoMy PhotoTrain Photo

Local servers: Localhost Dimboola Echuca Heywood Richmond Spencer (Note that these are only accessible on my local network.)
Public Web Servers: Hurst Server ajh.co CSSE Server Internode Server (In order of preference; not all of these may be active.)
Dynamically generated at 20170526:1422 from an XML file modified on 20160406:2104.

300 accesses since 23 Feb 2016, HTML cache rendered at 20170526:1422