HouseMade - The Hurst HouseHold Heater Helpmate

A.J.Hurst

Version 1.3.7

20160327:143918

Table of Contents

1. Introduction

These programs have been distilled from Nathan Hurst's original Nautilus Shell suite of programs. The main differences are a) the change of name, b) the documentation, and c) consistency in logging structures (where possible).

1.1 Overview

There are a number of programs in this suite, and they are grouped into the following categories:

The Web Interface (operational)

Provides an easy to use interface to the program suite, using two key programs: house and timer. These both invoke the house computer using the Flask protocol.

The Heating System (operational)

This subsystem controls the house heating system. Both the temperature and timing may be controlled: the temperature in steps of 1 degree Celsius, form 10 to 26 degrees, and the time in steps of 5 minutes from midnight to midnight, 7 (distinct) days of the week. Up to 7 time blocks per day are permitted.

The Tank System (operational)

Provides monitoring of the water storage facilities.

The Solar System (operational)

Provides monitoring of the solar photovoltaic systems, together with the inverter and UPS sub-systems.

The Chook Door System (operational)

Controls the opening and shutting of the Chook House Door.

The House Computer (obsolete)

Provides logging of house data, as well as an RPC interface to access the logged data. This functionality has been subsumed by being incorporated into each subsystem, and a separate logging system is no longer used.

The House Data Server and Relay Control System (operational)

Uses an Arduino driving 8 relays to switch the various circuits.

1.2 TODOs

• Write a "startEverything" script
• Fix pl60.c code to use getDevice to find the solar USB port (or rewrite it in Python).
• add simple 'flash' mode watering
• design and implement web interface to watering cron activity
• fix usbFind so that it does all the right things

1.3 History

The original House Computer was set up on an Intel 386 box, named redfern, in keeping with my philosophy of naming all my computers after railway junctions. But redfern did not have enough expansion capability, and used the rapidly dating EISA bus architecture, so it was not long before it was replaced with a larger chassis using a 486 and PCI bus. This machine was named central, and was the mainstay of the house computer system for many years.

The earliest evidence for the operation of these two systems is a file dated 23 May 1999, which I believe was written for the central system. Whatever, by mid 2001 the central system was certainly running, which makes me think that redfern dates are from early 1999, while central was probably commissioned in late 1999 to early 2000. Central was a single system, and ran a suite of programs known as Nautilus (aka "Water Shell", originally because it was a "shell" controlling just the garden watering operations), serving both the web page control systems (through Apache and locally written cgi scripts), as well as the various logging subsystems (temperature, humidity, solar panel insolation, and rainwater tank levels.

Central's disk system was the weakest link in the system, since it died in June 2012, some 12 years after commissioning. This is regarded as a fairly robust operation, and set the benchmark for future systems.

Before it died, however, work had been underway to replace the logging operations through a low-power mini-controller 486 based system, known as garedelyon, with the original intention to move all functionality to garedelyon. However, garedelyon's operating system was not up to running a full web server, and so it became just the data logging component of the system. Garedelyon had several RS232 and USB ports, and took over the responsibility for performing all the logging operations. A remote RPC mechanism allowed the web server system to communicate data between the two systems. Once central had died, the web serving functions were moved to various other machines, ending up on an old PowerBook Apple laptop, known as ringwood.

In January 2015, while we we away overseas, ringwood's battery died, taking the system, including the mini-controller garedelyon and weather station, with it. While I had a spare mini-controller, it was not worth replacing the laptop, and it was decided to move the entire system back to a single controller, based upon the new Beaglebone Black that I had acquired while overseas. This new machine was known as orsay.

In the meantime, while the hardware for orsay was being developed, my Acer laptop known as lilydale was pressed into service, this time running a limited number of functions. Part of this limitation was due to there no longer being any way to communicate with RS232 ports, as used by the weather/tank/solar logging systems on garedelyon. A major part of the hardware redesign occasioned by the switch to using a Beaglebone was the need to run a USB Hub, and to connect all the RS232 ports via RS232/USB dongles.

The re-design of the system was sufficiently complete by mid April 2015 to bring it on-line. Major changes include moving all functionality to the one system (thus reverting to a similar framework to the original Central/Nautilus system), and a shift to using Flask as the main web interface. This major rewrite was renamed HouseMade because of its much wider functionality, and now controls all of the house heating, the watering system, logging and display of house data (solar, water tank), the web interfaces, and most recently, the chook house door. Documentation for this system is this current document.

Unfortunately orsay was a little unreliable, crashing more frequently than it should, and eventually dying altogether in mid Jun 2015 (exact date not recorded). The replacement machine (known as bastille) suffered similar problems, and failed on 10 Jul 2015. The reasons for these failures are not clear, but are thought to be related to power supply instabilities.

Rather than risk another $100 piece of hardware, I have reverted (ostensibly temporarily) to using my Acer laptop, running Ubuntu 14.04, "Trusty Tahr". This did require a few days work to get it going properly, but there have been a number of significant improvements as a consequence:

1. The tank logging has been migrated to a Python program, thus creating the potential for some more smarts in that subsection.
2. The USB issues previously identified have been resolved. See section USB Resolution. These issues were all a consequence of the need to eliminate all RS232 code, and switch to a USB only system. The Beaglebone Black is known to have a significant bug in its USB subsystem, and this may have contributed to the unreliable behaviour reported above.
3. The chook door mechanism has been implemented, and is operational.
4. The hostname had been hardcoded into the code, since I did not expect that it would be changing so rapidly. It has now been factored out, and replaced by the abstract title of central, a tribute to the original system which lasted for some 12 years.

1.4 Philosophies

The house computer complex is just that - complex. Some design principles are in order. One of the difficulties of design has been the need to maintain several different systems, for different reasons. The main systems are (in abstract terms): the data logger, the house controller, and the house web server. Currently the system is structured so that all of these functions are undertaken by the machine lilydale (see previous section History).

The first principle is then all data logging to be handled by the data logging system (as far as possible). Where this is not possible, the system responsible for collecting the data should transfer it to the logging system as soon as possible, and the logging system should be regarded as the definitive source for any data requests. While this principle was originally framed to permit it to be handled by a separate machine, it can reside anywhere on the house network.

The second principle is that any request to change the state of the house must be passed through the house controller, even if it is not the final direct control mechanism. The state of the house is defined by the state of the (currently) 12 relays controlled by the controller system. Again, there is no requirement that this functionality be co-located with the others.

The third principle is that all web traffic is handled by the web system. A key factor in deciding how this functionality is handled is whether the web server is secure enough (can external users change the heating or open the chook door, for example), and secondly whether it could handle the additional traffic imposed by an externally available web server.

2. Key Data Structures

2.1 Edit Warning

Provide a simple inclusion to flag that all derived files are extracted from this file, rather than stand-alone.

2.2 House Definitions Module

The house definitions module, HouseDefinitions.py, gathers together in one place those constants that are common to all systems. Note that no shared variables may be handled by this module, since it is not shared across the various systems as a single instance. (All declared "variables" are actually constants, but python does not allow explicit constant declarations.)

Following a second failure of a Beaglebone, the house computer has reverted to the Acer laptop. This is now possible because of all the work done in getting the USB data inputs working. But it has also forced my to rethink the heavy use of hardcoding the machine name into all these script, hence the new definition of CENTRAL (the name is taken from the original house server).

The routines setColour and setTemperature are defined to localize these two calculations for the house and timer modules. They will be revised once the temperature adjustment system is rebuilt to its full potential.

3. The Web Interface

The web interface is Flask application running on the house computer lilydale, and providing a convential web page via a port 5000 call (the Flask port number), and interfaces to the house and timer modules through house and heating respectively. The figure '10' in setTemperature is just the lowest temperature that is displayed by the timer web interface.

To preserve security of the system, and prevent unauthorized access, this web server will only operate house functions if it is invoked from a machine on the 10.0.0 network (the private house network). In the longer term, username/password authority may be added.

3.1 The Flask Application

3.1.1 Define the Various Flask URLs and Calls

These two routines define the principal house web pages: house is the general house page, and timer is the heating timer control page. Note that timer has now (v1.3.0) been replaced by heating.

3.1.2 Define the Showpage Routine

The following routine provides a general purpose webpage server

The showpage routine does a similar task to that of my index.py routine in the Apache web servers that I run. It determines the type of file to be served, and in the case of XML files, calls the xsltproc processor to convert them to HTML.

3.1.3 Start the Flask application

3.1.4 Watchdog program for Flask

The flask application seems rather unreliable, and keeps freezing. In an effort to avoid this causing glitches to the access of the HouseMade system, this watchdog program has been implemented. Its operation is to request a download of the house web page, and if this times out, then a restart flask is issued. Essential to its correct operation is that it must be run as root, so that the restart flask operation runs correctly. Hence it must have its sudo sticky bit set, viz sudo chmod 4711 watchFlask.sh - a reminder of this is given by the Makefile (q.v.).

Note that the status returned by curl must be captured, as it is used several times subsequently, and the $? variable gets overwritten.

3.2 The HouseMade module

3.2.1 define the Generate Weather Data routine

This routine collects up the climate/temperature/heating data and builds a web page to display it. The web page is returned as a string, allowing it to be directly called by the Flask module.

The maxminTemp() call will return an empty dictionary if it cannot find the maximum and minimum temperatures, so we need key ckecks to avoid run time errors.

3.2.2 define the Generate Solar Data routine

Collect the solar power information for display and generate the related text.

3.2.3 define the Generate Tank Data routine

This section now installed on lilydale.

3.2.4 Collect Date and Time Data

The date and time at which this program is run is useful for logging, so collect it at the start of operations. The variable jobtime is intended to check how intensive use of this code may become.

3.2.5 Check the Client Connection

This page is intended to be world-wide-web accessible, and hence we must establish the credentials of the client. If it is on the local network, no problem, but external users must authenticate (username/passwd) before being allowed to alter any parameters.

The IP address is used in the first instance, as given by the environment variable 'SSH_CONNECTION'. If we can extract the 4-block IP address, well and good, otherwise make it the local mask. IP addresses on the local network (10.0.0.*) are allowed, as is the IP address of my work computer. All others pay money, and their names are taken.

3.2.6 Generate the Web Page Content

This is where the framework of the web page is generated. Most of the content is generated elsewhere as strings to be inserted into this template, hence the global dictionary call on vars at the end, with variable content being added via %s formatting imperatives.

3.2.7 Make the Temperature Panel (not currently used)

This code is separated out because of the complexity of loading the colours of each of the demand buttons. Each button gets a graduated colour from blue through to red, except for the currently specified temperature, which is shown with a yellow background. Temperatures are rounded to the nearest integer in order to determine which button is so highlighted. Temperatures above and below the selectable range highlight the HOTTER and COOLER buttons respectively.

There is a slight glitch with the operation of this form, in that when no specific temperature button is selected (such as when a text value of temperature is entered, the first button is selected (which would normally be COOLER). (See <house get calling parameters >.) To avoid this, a dummy blank button (value="") is built in at the start of the table list, and when this blank value is recognized, the text value is used instead.

3.3 The HeatingModule module

This web page provides a user-friendly interace to setting the automatic heating on/off times, and the temperatures over the course of a day (this latter function not yet operational). The week is divided into 7 days, each with its own programme.

Each day can have up to 7 blocks of time, where the start time of the first block is midnight (00:00 hours), and the end time of the last block is the next midnight (24:00 hours). The end time of each block can be altered, and the number of blocks is determined by the block that has end time of 24:00.

On saving, if the last end time is earlier than 24:00, a new block is added (up to 5 blocks). If seven blocks are in use, and the last end time does not end at midnight, the program will be incomplete and the actual behaviour is not defined.

The desired temperature of each time block can be set independently.

3.3.1 Define the heatingData Class

This class deals with all the logic needed to load and save the heating data, stored in a separate file. It handles conversion from external stored time data in hours:minutes format, converting it to internally stored minutes only (from the start of the day), and reconverting it back again on saving.

It also provides a few simple conversion routines for switching between the formats.

3.3.2 Collect Parameters and Update

3.3.3 Build Widths for Web Page Table

This code fragment checks to see if the client IP address is on the local network, and sets clientOK to True if it is, False otherwise.

4. The Weather System

The heart of the weather system is an electronic weather station with RS232 output, that is continously monitored by the garedelyon server. Once a minute, this server logs the current inside and outside temperatures, humidity and dew points. This information is stored in a logfile, temp.log in the directory /logdisk/logs/, and accessed by the heating and web systems.

4.1 The C Weather Monitor Program

(Details to be recorded)

4.2 The Python Interface to the Weather System

This is a simple python module that accesses the monitor progam and makes the data accessible as python structures. There is one substantive class, weather, instances of which entities containing the appropriate data.

The null classes environment, wind, rain, and pressure provide further localization of the data values.

environment

defines values for temperature, humidity, and dew point;

wind

defines values for wind gust, wind gustdirirection, avgerage wind speed, avgdir average wind direction, and wind chill factor.

4.3 The Weather Logging Process

This code is run once a minute by the EveryMinute.sh script, and simply outputs the inside temperature, the outside temperature, the inside humidity, the outside humidity, and the outside dew point data to the log file.

5. The Heating System

5.1 AdjustHeat

This script runs every minute on lilydale, to see if the heating should be adjusted. An entry in EveryMinute.sh invokes this program. It has recently (v1.3.0) been revised back to the original concept of allowing an arbitrary desired temperature to be specified, and it records its decisions in the log file heating.log (which see <EveryMinute.sh 15.1>.

Note that the variable hysteresis defines how far from the desired temperature the current temperature must depart before the heating will change state.

A suggested improvement is to check the current state of the heating (via the relay controller) to see whether the heating is currently on or off. If the demanded state is the same as the current state, then there is no need to explicitly call for the setBit operation.

5.2 checkTime.py

The responsibility of this program is to periodically (currently every 5 mins, see cron files) check the programmed temperature, and update the demand heating file on garedelyon.

The location of where it runs determines which server is in control of the heating (currently flinders, but this may change in future).

The basic logic of this program is to read the programmed temperature changes from the file tempProgram.dat (set by the flinders cgi script heating.py), and adjust the desired temperature to match the programmed temperature.

The key requirement to this logic is that changes should only be made at the appointed switch time.

There seems to be some sort of race condition in the switching logic. The trailing message has been added to try and identify the circumstances under which the planned temperature and desired temperature disagree.

5.3 TempLog

This script logs the house temperature. It runs every minute to maintain a minute-by-minute log. It must be run on garedelyon, since that is where all logging is collected (the log file temp.log is kept in the directory /logdisk/logs).

6. The Tank System

Define here those program components concerned (solely) with recording and suppling water tank information.

6.1 Water Tank Logging

The water logging code has been re-written from C to Python, to bring it in line with the rest of the system, and to (hopefully) improve the reliability of the logging. The Python code has been added to the existing code to manage the tank system, namely tank.py

6.2 Start the Tank Logging

The tank logging is performed slightly differently from the other logging operations, as the tank level transducer operates in a free-running open loop mode. Approximately once a second it sends a burst of data down its RS232 connection, and so it is necessary to have the logging program running constantly to hear those data bursts. This is the purpose of the tank.py program.

The rest of this code is concerned with logging the process ID of the logging program itself, so that it can be started and stopped reliably, without interference from any previous instance.

6.3 Tank Module Functions

The tank module tank.py incorporates some significant legacy code from Nathan's original Nautilus system design. In particular, the read_tank_state and readraw are Python transliterations from Nathan's C code. It is planned to rewrite this module in the near future using a more object-oriented approach.

The code now handles the logging function directly. When called as a main program, it enters an infinite loop, reading and logging the tank transponder, and output a log message once a minute.

When used as an imported module, tank.py defines a number of constants, and provides functions to access tank data and perform temperature compensation (see compensate).

Note that this code is under review, and will be cleaned up in the near future.

The temperature compensation values were worked out from a pair of observations:

• On 16 Jan 2014 at 0800, the tank level raw indicator was 73035, while the (outside) temperature was recorded as 28.2
• At 1200 (midday), the tank level was 73248, and the temperature was 41.5 (yes, it was hot!)

We further assume that these two values themselves are linearly related as the tank level falls, and they themselves should be linearly adjusted by tank level, to get a generalized compensation calculation.

Further work remains to be done on this aspect of tank logging, in particular, how the temperature and raw level data are retrieved and correlated.

7. The Solar System

This is almost verbatim from the central version, although some modifications have been made to correct what appeared to be the presence of obsolete code in read_register.

This code is responsible for building the solar.log file. It is to be run every minute on garedelyon (c.f. EveryMinute.sh), and makes calls upon the pl60 module (a C program) to read the solar data from the solar controller, register by register (Need a link to the solar controller manual here). The log entry is then printed to standard output for logging, and to the file solarState which records the most recent value.

These are the registers of the pl60:

17	Battery Vmax
20	Charge AH
24	Load AH
32	Input Current
34	Battery Voltage

Note that the values returned by these registers (may) need recalibration. Others not mentioned are not used.

7.1 logsolar.py

There is no need to explicitly start this program running, as it is called once every minute by the EveryMinute.sh cron script.

7.2 solar.py

Provide definitions and access functions for the solar controller.

Note that this code is intended to be imported as a module to python programs that need access to the solar controller. It may be called as a stand-alone program, when it simply prints key data and exits.

8. The Chook Door

The chook house (described separately in the Chickens page) has a door that is automatically controlled, and opens and shuts in accordance with sunrise and sunset times throughout the year.

important note! The chook door proving system has recently been changed from a micropython board to a Beaglebone Black. Consequently some of the following is out-of-date. It will be updated as soon as possible. In the interim, a breadboarded system is running the proving subsystem, and it is not fully integrated into the rest of the system.

There are three programs in this suite:

1. ChookDoor.py This code provides a module for managing the chook door operations.
2. checkChooks.py This code updates the houseState file with the current state of the chook door, by calling on the readChook.py code.
3. ChookProve.py This code reads the single bit value that proves that the chook door is shut, and writes the current state as a text line containing either 'closed' or 'open' to the file /home/ajh/Computers/House/status. It must be run on the Beaglebone system (auteuil) as root, in order to be able to access the (privileged) GPIO pins.

To use this module, import ChookDoor into your code, and create an instance of the class ChookDoor. Data computed by this class is stored in a persistent form in the file chookFileName='/home/ajh/Computers/House/suntimes.txt'. The following methods and entities are available:

load()

Initialize the instance with data from the persistent record.

compute()

Recompute the data in the persistent record (but don't store it).

save()

Save the persistent data (if necessary).

sunrise

Today's sunrise time.

sunset

Today's sunset time.

dooropen

Today's door opening time.

doorshut

Today's door shutting time.

opendelay

minutes after sunrise that the door is to be opened (default is 60 minutes).

shutdelay

minutes after sunset that the door is to be shut (default is 20 minutes).

current

The current state of the door, either 'open' or 'shut'. (Setting this variable has no effect on the door: it is set only as a side effect of the compute() method.)

If the module is invoked as a main program, it performs a load and print operation, unless the -c option is supplied, when it does a recompute of the ephemeral data (and opens/shuts the door if required).

8.1 ChookDoor: load

Read the persistent data from the external file. This is to allow queries of the data without necessarily recomputing the ephemeral data.

8.2 ChookDoor: compute

Check if the current time requires a change in the door status. If so, open or close the door as required.

8.3 ChookDoor: save

8.4 ChookDoor: compute ephemeral values

Use the Python Ephemeral package to compute sunrise and sunset times for Melbourne. Note that the interfaces call for the previous and next times, not today's times, and hence there is a bit of computation needed to work out today's times, regardless of whether the actual sunrise/sunset time is before or after the current time. The times are all computed in UTC, and hence there is a necessary adjustment for local time. Note that daylight saving time is not taken into account!

8.5 checkChooks: update the current chook door state

This code runs every minute, and inspects the current state of the chook door as given by the door proving subsystem. It uses this to update the general house state file, houseState, as otherwise maintained by <currentState.py 9.1>

8.6 Chook Door Proving Subsystem

Another attempt has been made to employ a Beaglebone system, this time just to run the hard subsystems. The first piece of hardware to be incorporated is the Chook Door Proving Circuit. This is a completely separate circuit (shared a common ground, though) that uses a separate microswitch to detect when the door is properly closed. The microswitch closes on shutting, and the Beaglebone GPIO pins are used a) to read the microswitch, and b) to light some indicator LEDs to show the door state. Red is used to indicate open, Green for closed.

Important Note: It would make sense to combine these two scripts, and eliminate the extra latency occasioned by having to write the status to a file. However, the need for the first script to run as root might complicate matters somewhat.

This is a simple program that sets up the GPIO pins, then reads the input to check the door stete, lights the appropriate led, and write a simple status into a file.

8.7 Chook Door Proving Server

This is an RPC-based server, based upon the <RelayServer.py 10.2> system, that provides a single procedure getDoorState which returns the current state of the chook door, as measured by the proving circuit.

9. The House Computer

9.1 The Current State Interface

The currentState routine provides an easy access mechanism to get the current state of various house values, as computed by the various routines. This is in the form of a module that is to be imported by any routine changing the value of a key variable, and provides persistent storage of that variable, until the next time it may be updated.

9.2 The HouseData Server (obsolete)

Defines an RPC server to provide details of the current house state (e.g., the contents of the heating file, the log files, etc.), and to update data as required..

Most of this code was stolen from the Python Library Reference document, and revised from the SimpleHeatExchanger.

This code has been decommissioned, as the server (garedelyon) is defunct. All of these functions are now available through the main house server (lilydale).

Note that the water log should be moved from the root directory to the /logdisk/logs directory to be consistent. Also, we should find a way to manage the bound on the size of the log files (getting the maximum is O(n), for example, whereas it should be O(hours)).

9.2.1 HouseData define getTemps

9.2.2 HouseData define maxminTemp

9.3 The startHouseData.sh script

10. The House Data Server and Relay Control System

Currently, the laptop lilydale is used as both relay controller (through an Arduino circuit) and as general data logger and server for the various house functions. (An exception is the Chook Proving system, see section Chook Door Proving system.)

In this table, the relays are numbered left to right on the computer house panel. Bit 0 is the most significant (or leftmost) bit.

Possibilities for the new relays:

• solarwash
• ?

10.1 The Relay Controller Code

This is a simple standalone program used by cron jobs to turn on relays at various times (mainly watering) for fixed periods of time. It calls the RelayServer via RPC calls to actually drive the relays, and really serves only as a CLI parameter handler. The relay name, and the time it is to turn on are supplied by two CLI parameters. If other than two parameters (besides the program name) are supplied, a default is used.

10.2 Relay Server

The relay server runs all the time, offering a RPC interface to the relay driver. The relay state is represented as a n-element list, where each element represents the relay state as an integer 1 (relay on) or 0 (relay off). It can be controlled either by passing a full state list, or by turning individual bits on and off. The latter is to be preferred, to avoid parallel interaction conflicts.

10.2.1 HouseData define getTank

Here we make a stab at applying a temperature compensation to the water level. It assumes that the compensation is linear in both temperature and level, a somewhat bold assumption.

10.2.2 relayserver: getTimer

10.2.3 relayserver: getState

10.2.4 relayserver: setState

10.2.5 relayserver: setBit

This new routine is intended to coalesce the operations of setBitOn and setBitOff, by passing in an extra parameter newValue.

setBit sets the relay control word to its current state, and with bit number bitNo set to newValue. This new word is written to the relay driver, via the relayChannel routine and the Arduino controller.

An additional piece of logic checks to see if this is actually a change of state, and if it is not, avoids logging the superfluous set operation, but rather increments a counter which is output when the bit is actually changed. Note that this only affects logging - the controller is still updated with the new (unchanged) state.

10.2.6 relayserver: setBitOn

setBitOn sets the relay control word to its current state, and with bit number bitNo set to a 1. This new word is written to the relay driver, via the relayChannel routine and the Arduino controller.

10.2.7 relayserver: setBitOff

setBitOff sets the relay control word to its current state, and with bit number bitNo set to a 0. This new word is written to the relay driver, via the relayChannel routine and the Arduino controller.

10.2.8 relayserver: start

10.2.9 relayserver: countDown

The purpose of auxilary process countDown is to maintain the count of how long each relay is to be held closed, if it was started with a start call. Note that it is possible to also set relays on and off without a time (using the setBitOn and setBitOff RPC calls), in which case the time remaining is shown as 0 (zero). Such calls will not be automatically turned off, since they do not set the list of nonZeroTimes.

Once a second, the process awakes, and decrements any non-zero counts. These non-zero counts are indicated in the list nonZeroTimes as a partial optimization to avoid testing all relay counts, and to avoid ambiguity about which relays are independently turned on.

10.3 Start the Relay Controller

This short script encapsulates all that is necessary to (re)start the relay server. It records the process ID in the file relayProcess so that when it is restarted, any previous invocation is removed properly.

10.4 The Old Relay Setup

These are the connections for the old I2C setup that used to run off central, and now decomissioned. They are recorded here to aid in back-tracing legacy connections.

10.5 The Arduino Interface

10.5.1 The Arduino Start Script

Run this script in the /home/ajh/Computers/House/RelayDriver8way directory on bastille. The setup file sets a few key environment variables.

The make upload command should upload the driver program, and make the arduino ready to accept commands from the command line and the RelayControl.py script. To test that this is working, try:

            echo 001000000000 >/dev/ttyUSB0
          

11. Hardware Issues

11.1 USB Issues

One of the big headaches in getting this system operational has been the mapping of USB devices to the correct hardware ports. This is clearly a long-standing issue, as many experimenters have posted questions about this on the web.

One of the key software tools to aid in this process of finding the correct mapping is the lsusb command under Linux. Here is the output from it on bastille at 20150426:110547 timestamp (reordered to place items in bus/device order):

ajh@bastille /home/ajh/Computers/House 517 $ date;lsusb
20150426:110547
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 2109:2812  
Bus 001 Device 003: ID 2109:2812  
Bus 001 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 001 Device 005: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 008: ID 0bc2:2320 Seagate RSS LLC 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
       

This is my translation of what these actually are:

Note that at the moment several devices (some of which are not in use) on bus 1 cannot be resolved, as they use the same brand of USB/RS232 cable connectors, and there appears to be no serial number information. Note that the IDs are the same as well.

Micheal Ludvig's very helpful page at http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/ shows how to setup persistent names for these USB-serial devices, but unfortunately it relies upon having unique IDs/SerialNumbers for each device on the bus. You will note that the two ATEN devices have the same Vendor/Product pair, and NO serial numbers, so that they cannot be distinguished at this level. I have posted a comment about this, and will revisit it when/if I receive a reply.

Here are the udev rules I have set up in /etc/udev/rules.d/99-usb-serial.rules to handle my devices:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="arduino"
SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2302", SYMLINK+="tank"
        

(20150606:152721) Note: the Seagate disk has been recording disk errors, which occasionally cause the system to hang. Hence the disk has been removed.

11.2 USB Resolution

Aha! I have finally worked out a solution to the problems outlined above. This article in the Linux FAQ provided the key, and I have extended the ideas outlined in that article. The key point is the fact that the port numbers allocated are ordered in the order of the devices plugged into the hub. I am using a 7-port VIA Labs Hub, and by keeping a list of the devices and port numbers, I can use this together with the information returned by udevadm to map devices to /dev/ttyUSB device files. The page Writing udev rules also gives helpful advice.

That mapping is saved in a file /home/ajh/etc/usbPorts.txt, which is generated by the python program usbFind.py.

I have since discovered similar information resides in the directory /dev/serial/by-path/. I record these here for future use, but for now, things are working so I won't change them! Here are the entries in that directory:

        lrwxrwxrwx 1 root root 13 Jul 10 11:59 pci-0000:00:14.0-usb-0:2.4:1.0-port0 -> ../../ttyUSB3
        lrwxrwxrwx 1 root root 13 Jul 10 15:21 pci-0000:00:14.0-usb-0:2.1.2:1.0-port0 -> ../../ttyUSB1
        lrwxrwxrwx 1 root root 13 Jul 11 11:52 pci-0000:00:14.0-usb-0:2.3:1.0-port0 -> ../../ttyUSB0
        lrwxrwxrwx 1 root root 13 Jul 11 16:11 pci-0000:00:14.0-usb-0:2.2:1.0-port0 -> ../../ttyUSB2
      

Now for my mapping file. The columns are hub port number, device name, USB number. Note that the last column is not necessary (use dashes if not known), and is (re)computed by the usbFind.py program.

Now for the usbFind.py program, which is written as a module which provides a USBclass, with methods to access and update the usbPorts.txt file. If called as a main program, it does exactly that, and regenerates the mapping file from scratch.

A key method is the get routine, which translates a device name into a USB device port. This is utilised in the getDevice program, installed as part of the bin library.

11.2.1 usbFind: USBclass.load

11.2.2 usbFind: USBclass.compute

11.2.3 usbFind: USBclass.device2port

11.2.4 usbFind: USBclass.save

Call this routine as getDevice arduino, where arduino may be replaced by some other device, as listed in the table in <usbPorts.txt 11.1>

11.3 Current Patchboard Wiring

11.3.1 Cellar Computer Board

These are all numbered top to bottom in each block.

11.3.2 Cellar Door Board

These are all numbered top to bottom in each block.

11.3.3 House Corner Board

These are all numbered top to bottom within each block.

11.3.4 BBQ Board

These are numbered left to right.

11.3.5 Restructure Plan

There are some photos of the current state of play, which I will post here soon. In the meantime, there are plans to restructure the relay wiring, using the following colour coding:

I have to admit, I'm not entirely sure this is the best idea ...

11.3.6 Power Bus

Given the frequency with which alterations are made to the control panel, and the need for power sources without interrupting other devices, it is suggested that the power rails be split along the following lines:

Variations on this are possible - for example, combining the 4- and 8-way relay supplies.

11.4 Current Cat5 Ethernet Wiring

There are n switches around the house, known by a single letter name. These are:

11.4.1 Cellar Patch Board

There are two components: a 24 port patch panel, and a 24 port 100Mb switch.

Note that most of these are direct connexions to the corresponding patch panel port.

11.4.2 Study

There are two switches located in the study: a Netgear DGS1008D 8-port 1000Mbs (known a S, Study), and a Netgear ProSafe 5-port 1000Mbs (known as D, Desktop)

There are also 2 wall plates, each with 2 ports, known as L1, L2, R1 R2 (Left and Right)

Netgear DGS1008D 8-port 1000Mbs Switch S

Netgear ProSafe 5-port 1000Mbs Switch D

Study Wall Plates L and R

11.4.3 Family

Netgear 8-port 1000Mbs

12. Test Programs

12.1 Check RPC Operation

The following short fragment of code is intended to check the operation of the RPC mechanisms on both garedelyon and lilydale. It provides the user with one RPC object, o (bastille), which can be used to invoke the RPC interfaces. Several such (information supply only) interfaces are invoked as examples.

Usage is to import this code into an interpretive invocation of python, viz from testRPC import *.

Note that the data logging operations are not currently available.

13. The Log Files

Here is a summary of all the log files maintained:

RelayServer.log

lilydale:/Users/ajh/logs/RelayServer.log logs activity of the relay controller, recording relay sets and resets.

cron.log

bastille:/home/ajh/Computers/House/cron.log logs behaviour of the AdjustHeat.py program, responsible for adjusting the heating on or off, depending upon the current temperature and the desired demand temperature. (This should probably be moved into the logs directory and renamed to heatadjust.log)

housedata.log

garedelyon:/logdisk/logs/housedata.log logs calls on the garedelyon RPC server, along with some debugging information (which should probably be removed).

maxmins.log

garedelyon:/logdisk/logs/maxmins.log logs the maximum and minimum outside temperatures for the last 8 days.

relay.log

garedelyon:/logdisk/logs/relay.log

solar.log

garedelyon:/logdisk/logs/solar.log

tank.log

garedelyon:/logdisk/logs/tank.log

temp.log

garedelyon:/logdisk/logs/temp.log

14. (Re)Starting the Server

14.1 Introduction

This has been a somewhat fraught area of development. Issues with identifying what USB ports are connected to what devices, Arduino startup issues, and just plain knowing the current state of the system is when starting various services, have made this area less than reliable. However, steady progress has been made, and currently the startup scripts are being moved to utilise the UpStart software used to manage all Ubuntu services.

This is a list of all the processes that need starting:

1. usb - to ensure that all USB connexions are identified correctly
2. flask - to provide a web server and house interface
3. arduino - to control the relay drivers
4. relayserver - to interface to the Arduino
5. tank logging - to record tank levels
6. solar logging - to record insolation
7. weather station - to provide temperature data
8. chook door

14.2 Non-Upstart Method (more reliable!)

14.2.1 Sort out USB allocations

The USB allocations change on each reboot, and anytime that a USB plug is removed or added, or the USB hub power cycled. Hence when restarting the house system, it is wise to make sure that all USB allocations are known. A script called usbFind.py checks all 7 ports of the hub, and writes the allocations into the file /home/ajh/etc/usbPorts.txt.

          $ + /home/ajh/Computers/House
          $ usbFind.py
          $ -
        

Check the file /home/ajh/etc/usbPorts.txt. It should look like this:

          00 -       -
          01 arduino 0
          02 -       -
          03 -       -
          04 wx200   1
          05 tank    2
          06 solar   3
        

14.2.2 Start the Flask Server

Starting the flask server is simple:

          $ + /home/ajh/Computers/House
          $ startFlask.sh
          $ -
        

Do not worry if you get a message saying that such-and-such process does not exist. That simply reflects the fact that the previous flask server has been killed in some way (for eaxmple, by a reboot).

14.2.3 Start the Arduino Driver

Usually straightforward.

          $ + /home/ajh/Computers/House/RelayDriver8way
          $ . setupMake.sh
          $ make -f arduino.mk upload
          $ -
        

Check that the USB port used matches that identified in the /home/ajh/etc/usbPorts.txt file.

If this process appears to fail, you can check that the Arduino is working by manually sending it a relay state word:

          echo 001000000000 >`getDevice arduino`
        

You should see the relay state change.

14.2.4 Start the RelayServer

Should be straightforward:

          $ + /home/ajh/Computers/House
          $ startRelayServer.sh
          $ -
        

Again, you can ignore messages about non-existent processes.

14.2.5 Start the Tank Logger

          $ + /home/ajh/Computers/House
          $ startTankLog.sh
          $ -
        

The USB port is automatically determined by the startTankLog.sh script. Ignore missing process messages.

14.2.6 Start the Solar Logger

This script is slightly different, as the regular logging is performed by the EveryMinute.sh script, which runs once a minute. Until the USB device is discovered automatically, you need to check the pl60.c script in /home/ajh/Computers/House/pl60-ubuntu-1.0/ uses the correct USB port. Recompile with the correct value (make pl60) and copy the result into the bin directory, so that EveryMinute uses the correct program.

14.2.7 Start the Weather Station Daemon

The weather station uses a daemon to read the weather station data, and make it available to the user level scripts. The daemon is started with:

          $ + /home/ajh/Computers/House/wx200d-ubuntu-1.1
          $ wx200d -s /dev/ttyUSBn
        

where n is the usb number given by the /home/ajh/etc/usbPorts.txt file. Check that this is working correctly by running

          $ wx200
          $ -
        

which should display a heap of weather information. If it doesn't, try power cycling the weather station itself (pull out the power cable, wait a few seconds, and replace it). You will need to reset the date and time, and units.

14.2.8 Start the Chook Door Server

The chook door server provides an RPC interface to interrogate whether or not the chook door is closed, according to the proving microswitch. This circuit is independent of the actual closing and opening process, and provides a safety check that the door is actually closed, once the close command has been issued, and the door has had time to close. It runs continuously on a BeagleBone server (auteuil), hence:

          auteuil $ python /home/ajh/Computers/House/ChookDoorServer.py
        

Since this program runs continuously, it should be started in a separate terminal window, which is then hidden from view, but left running.

14.2.9 Start the Chook Door Prover

The chook door prover is a small program that runs continuously on a BeagleBone server (auteuil), and monitors the state of the proving microswitch. It drives a pair of leds to indicate the state, and also writes the current state to a file status. It must run as root, hence to start it:

          auteuil $ sudo bash
          auteuil # python /home/ajh/Computers/House/ChookProve.py
        

Again, this program outputs the status everytime it changes, so it should be started in a terminal window which is then minimized and left running.

14.3 The New UpStart Configuration

Like its Unix counterpart init.d, the init directory contains scripts to start and stop each component of the HouseMade system.

Here is a list of the relevant files:

1. /etc/init/chookDoor.conf
2. /etc/init/flask.conf
3. /etc/init/relayserver.conf
4. /etc/init/usbPorts.conf

The upstart software requires that startup scripts are located in /etc/init. This is where the following startup scripts have currently been placed for testing purposes, but the intention is to move them to a separate user area.

The different services provided are outlined in the following subsections.

14.3.1 USB Allocation

Run the command

          $ start usbPorts
        

This generates a list of the USB devices found in port order in the attached 7-port USB Hub, and identifying, for each list tuple:

0. Hub socket number;
1. USB sequence number;
2. device name;
3. USB device

These values are recorded in the file ~/etc/usbPorts.txt and are used by subsequent programs in the startup sequencing.

14.3.2 Flask Server

Run the command

          $ start flask
        

It normally generates no output, unless the previous invocation failed in some way.

14.3.3 Arduino

Start the Arduino. Best to do this while in the Arduino subdirectory, so cd to that:

+ ~/Computers/House/RelayDriver8way

            /home/ajh/Computers/House/RelayDriver8way/startArduino.sh
          

echo 001000000000 >`getDevice arduino`

No, not quite. If you find that the device is locked, look in directory /run/lock/ for a lock file LCK.. that matches your locked device. Removing this file will generally fix the locked device.

14.3.4 Relay Server

Start the Relay Server (first go back to the House directory, do a - to get there):

startRelayServer.sh

14.3.5 Tank Logging

Start the tankLogging:

startTankLog.sh

14.3.6 Solar Logging

Ensure the solarLogging is running. This requires that the C code routine pl60.c is compiled and placed in the home bin directory (/home/ajh/bin/) so that it can be executed by the solar.py module when called by the EveryMinute.sh script.

14.3.7 Weather Station

The weather code relies upon the weather station daemon, wx200d. Firstly, make sure that the weather station port is correctly assigned:

            $ getDevice wx
            /dev/ttyUSB1
          

            $ ll /dev/wx200 
            lrwxrwxrwx 1 root root 7 Dec 17 16:43 /dev/wx200 -> ttyUSB1
          

Once this is in place, start the daemon itself with

            $ /home/ajh/Computers/House/wx200d-1.1/wx200d
          

Check the operation of the weather station by running

            $ /home/ajh/Computers/House/wx200d-1.1/wx200
          

14.3.8 Regular Service Activity

15. The Cron Jobs

See the cron.xlp file for the actual code. There is just the single interface to cron: the script EveryMinute.sh which is run once a minute.

Note that this script gets executed every minute, as the name suggests. However, some tasks do not need such frequent service, and hence the calculation of minutes mod 5 so that the adjustHeating is only run every 5 minutes.

16. The Makefile (separate file)

16.1 Makefile: install bastille

17. Document History

18. Indices

18.1 Files

18.2 Chunks

18.3 Identifiers

49 accesses since 04 Sep 2018, HTML cache rendered at 20180703:1425