|Parish | Peculiar | Pedantry | Personal | Photography | Photos | Plateways | Positronics | Post | Professional | Programme | Programming | Places|
See the separate page for documentation on the HouseMade software
Long time no blog. 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, at 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).
Patch panels are distinguished as numeric (Netgear 48, 1G), N (Netgear 16, 10G capable), and TP (TP-Link, 10G capable).
|0L0||17||16||Seniors' Lounge TV||1D4||41|
|direct||16||Cellar House Computer|
Writing the section immediately below prompted me to check the previous writings and realise that much has changed since Apr 2015. What has changed?
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!
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/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|
(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.
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 updatethen (20150430:180215)
sudo apt-get upgradewhich removed the public key errors.
sudo apt-get install arduinowhich seemed to work, but I did not have time to test this thoroughly.
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!
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.
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!
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.
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!!!
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!
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
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
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")
today several significant steps were made:
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.||20 accesses all since
17 Apr 2022
(accessible only on local network.)