HouseMade - The Hurst HouseHold Heater Helpmate

A.J.Hurst

Version 4.3.2

20230722:124156

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). It has also undergone several reconstructions, most recently (as described by this document) to support a single Raspberry Pi based system (as opposed to a distributed system using a BeagleBone for the relay driver and a Raspberry Pi for all the higher level software).

1.1 Overview

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

The Hardware Subsystem

The hardware interface to the relay drivers.

The Relay Control System

Uses a Raspberry Pi to provide the underlying hardware interface to the 16 relays used to switch the various house circuits.

The Relay Server

Provides an RPC interface to controlling the house relays.

The Event Server

Provides an RPC interface to controlling the various house events.

The Web Interface

Provides an easy to use interface to the program suite, using two key programs: house and eventEditor.

The Chook Door System

Controls the opening and shutting of the Chook House Door.

The Garden Steps System

Controls the switching of the garden steps lights.

The Garden Watering System

Controls the watering of various garden irrigation outlets.

1.2 TODOs

• add button to main page to dump current events to text file
• Check that handler for Spares is working properly
• Need interlocking so that you cannot turn on chook up when door going down and vice versa.
• Investigate long-term plans for heating and cooling.
• Explore the mechanics of the HomeAssist software.

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 controlled all of the house heating, the watering system, logging and display of house data (solar, water tank), the web interfaces, and more recently, the chook house door.

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 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 were a number of significant improvements as a consequence:

1. The tank logging was 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 was 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 was implemented, and was 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 Progress since 2015

In Oct 2016 we moved house, since we had embarked upon a complete renovation of the existing house, and we needed to vacate the premises. All the house automation system had to be dismantled, since every room in the house was undergoing some sort of renovation, and the cellar was no exception. For the remainder of 2016, all of 2017, and the first few months of 2018, the HouseMade system was out of action.

Progress was slow in reinstating the system, partly because of the disruption to the cellar, and partly because most of the components were in storage. The cellar had been dug out to expand the space available, and most of our spare time in 2019 was spent in making it more habitable. A new floor went in, a baseboard for the new model railway constructed (see History), drawers and shelves installed and a new (secondhand) rack to house the house server and central replacement brought in. It made a big difference to the space! This was largely complete by mid 2020, by which time the chook door opening mechanism had been reinstated, and recabled.

A complete redesign of the system was undertaken, reusing some components from the previous design, but now based upon an event-driven server-based model. This is described below in the relevant sections. The new hardware for this version of the system was a BeagleBone Black (kerang), which ran the relay drivers, and was the only processor that talks directly to hardware. kerang provided a primitive RPC interface to turn relays on and off, and in turn was driven by a decentralized Relay Server controlling the relay driver, and a decentralized Event Server, providing generalized event services to web pages and the like. These servers have been designed and tested on my desktop, but can and have been migrated to separate systems, with the stable version being known as terang, which provided http services throughout the household network to program and control the various relay devices and the systems that they control. terang was a Raspberry Pi Model 4 running NOOBS, a Unix-like system.

This system was operational by Dec 2020, driving the chook door, garden lights (a new addition to the controlled enviroment), and the garden irrigation system. Further development plans are now at the stage of active work, and this version of the documentation describes these improvements.

As of Mar 2021, the house computer system now runs on a new Raspberry Pi Model 4B, known as reuilly, occasioned by the need to expand the number of relays that it drives (now 16).

1.5 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 (Web Page Management Software), and more lately, the solar system (Solar Panel and Battery Analysis system).

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.

The fourth principle is that, as far as possible, each system component should be independent of the others, exchanging information through well-defined protocols, and using RPC mechanisms to all components to be distributed as required. For example, although both the house and solar systems have significant web interfaces, they send information to the web server as pre-structured HTML pages, and stand-alone cgi interfaces for information flow in the opposite direction.

The third principle (web traffic) has been softened in the sense that there can be multiple web servers, but only one is seen as definitive. For example, the house controller is the definitive server for all house and solar enquiries, but other web servers can run their own house or solar platforms, as long as it is clear which is the definitive system. For example, the externally facing server (ajh.co, running on spencer) can offer house or solar enquiries, but it derives its data from reuilly, and is also limited in what changes it can make through the house computer (to avoid nefarious non-authorized changes).

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

Note that the name of house computer (which in version 4 runs all of the house software) is defined globally as CENTRAL (in honour of the original machine), but is currently located on physical machine reuilly.

The server definitions are gathered in one place here so there changes may be made expeditiously, without having to track down all instances of specific servers.

There are in fact 16 relays in the system. Relay names 11 to 15 have been commented out simply to preserve space and keep the interface as simple as possible. They can be easily reinstated as necessary.

The relays are given user-friendly names so that they can be referred to easily.

2.2.1 HouseDefinitions: server connections and interfaces

These are all the definitions required to talk to the various pieces of code around the place. Several of them are not yet implemented.

2.2.2 HouseDefinitions: general routines

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.

2.2.3 the isDay function definition

The function isDay is related to the ability to schedule events differently according to the day of the week. It returns True if the nominated day of the week (d) is included in the list of days spec. spec can be a single day, a comma separated list of days, or a range of days. The BNF is

      spec = day | day ',' spec | group | group ',' spec .
      group = day '-' day .
      day = ['0' | '1' | '2' | '3' | '4' | '5' | '6' ] .
    

3. The Hardware System

There are three software components to this system:

HardwareDriver

The bottom layer software to hardware interface.

HardwareServer

An interface to the outside world, providing primitive calls to control the attached relays. This sets up a server on port HouseDefinitions.HardwareServerPort

HardwareClient

A simple program to test the server interface.

3.1 I/O Allocation for the Raspberry Pi

The relay control operations are being migrated to a Raspberry Pi (Model 4 B). One major change in this process is to add an additional 8-channel relay board, now allowing for up to 16 switchable connexions. To do this, utilize the following pinouts:

Module A Module B Relay No GPIO Pins Relay No GPIO Pins IN1 GPIO10 IN9 GPIO23 IN2 GPIO09 IN10 GPIO24 IN3 GPIO11 IN11 GPIO25 IN4 GPIO05 IN12 GPIO08 IN5 GPIO06 IN13 GPIO07 IN6 GPIO13 IN14 GPIO12 IN7 GPIO19 IN15 GPIO16 IN8 GPIO26 IN16 GPIO20

There is also a need for inputs to the system. As yet, the exact nature of these inputs is to be determined, but there are at least 2: Chook Door proof closed, and Chook Door proof open. Currently the gpio pin allocations are:

Input Number	GPIO Pin	usage
1	17	Chook Door proof open
2	27	Chook Door proof closed
3	4	request Ring Main (auto off)
4	21	request garden steps (putative, photo detector on gate, auto off)
TBA	14	DS18B20 thermometer probe
	0	(EEPROM, avoid)
	1	(EEPROM, clock)
	2	(serial, prefer avoid)
	3	(serial, prefer avoid)
GPIO 22, 18 and 15 are fried

3.2 Inverse GPIO Pin Allocation

3.3 The Device Tree

Like many such devices, the Raspberry Pi has software configurable hardware, configured by the /boot/config.txt file. We set here the hardware pullup/down resistor configuration.

For documentation on how to write configuration file entries, see the Device Tree Configuration file.

Note that the permissions on /boot/config.txt do not allow direct updating of the file. It must be edited by root. The changes that need to be made are identified at the end of the following file.

Note also that the module w1-gpio, together with w1-therm, must be added to the /etc/modules file, so that they are loaded at boot time. Do this with the following code:

        sh -c 'grep "w1_therm" /etc/modules || echo "w1_therm" >> /etc/modules'
        sh -c 'grep "w1_gpio" /etc/modules || echo "w1_gpio" >> /etc/modules'
        

3.4 Restarting the Hardware

The Raspberry Pi allows software reconfiguration of its I/O pins. These must be set before any software that controls the pins can run. As the settings require superuser privilege, this reconfiguration process must be run as root.

Note also that device settings in the hardware are lost on a reboot. Accordingly, the I/O pin settings must be redeclared on reboot. To restart the system from scratch (i.e., after a reboot), run this script:

          sudo setIOpinConfiguration.sh
        

3.4.1 Set the Pin Definitions

Note within the pin setting script, the gpio14 pin is reserved for a DS18B20 thermometer probe, and is not available as a general purpose pin. Its setting is handled by an entry in the /boot/config.txt file. See Robert Elder's page on interfacing the DS18B20 to a Raspberry Pi.

These definitions collect the Raspberry Pi's GPIO pin definitions in one place. There are two 8-channel relay modules, known as MODULEA and MODULEB, for a total of 16 independently switchable relays.

The key thing to note is the list of pin numbers MODULEA and MODULEB, which define output pins. These numbers are used to set gpio definitions, and then to set directions (outputs) and initialize these outputs to 1 (which is the "off" state for the driven relays).

Input pins need no initialization.

Finally, we set various permissions to make sure that users (and not just root) can use these definitions.

3.4.2 Restart the Hardware

Once the pin definitions are restored, the Hardware and associated servers can be restarted. This is done with a simple

            $ ~/Computers/House/HardwareServer.py &
          

            $ ~/Computers/House/HardwareClient.py virile
          

(20230702:162737) A new script testIfRunning.sh has been added to simplify restarting the HouseMade. This checks each piece of software in order to see if it is running, and if not, to (re)start it. It is important that each software process is stable before starting the next one.

3.5 the HardwareDriver.py program

This code provides a class that drives the relays directly through the GPIO pins of the HardwareBone. The init method of the class creates a file for each GPIO pin in use. This file is available for writing or readiOutputPinsng, as appropriate. For relays, by writing the appropriate value, 1 for on or 0 for off, to the file turns the nominated relay attached to the corresponding GPIO pin (labelled gpiopin number) on or off.

The second method, switch, turns a single bit/relay on or off. The input request is a pair of digits, the first of which defines the relay number to be used (0-origin), and the second digit of which defines the on (1) or off (0) desired state of this relay. Note that the file has to be flushed after writing, for the new data value to be transferred immediately. We preserve the new state in the class entity values.

The third and fourth methods access the Raspberry Pi inputs. test access the given input and returns a 1 or 0, as apprpriate. read accesses all inputs and returns a composite string with one character (0 or 1) for each input.

The fifth and sixth methods control the activity of the driver. It can be switched into an ineffective mode, called sterile, by invoking the method makeSterile, and conversely, made active by invoking the method makeVirile. The flag entity virile controls this activity, and simply enables/disables the file writes in the switch method.

The __str__ method renders the current saved state into a character string, which is used to return the new state to the calling environment. An 'o' in this string indicates that the corresponding relay is enabled, and inactive relays are shown as '.'. (An equivalent method for inputs is the read method. Perhaps this should be integrated into the __str__ method?)

3.6 The HardwareServer.py program

This code runs a server to interface with the relay driver code (HardwareDriver.py). It imports the driver class, and creates a TCP socket server that reads and passes a relay state string directly through to the driver. This is done for reasons of simplicity and reliability. Calls on the server handler handle take one of the following parameters:

virile

set the server to make active changes according to the requests of subsequent calls

sterile

disable any subsequent calls from activating changes

reset

turn all relays off

settings

return the current state of the relays as a string of 1s and 0s

inputs

return the current state of the inputs as a string of 1s and 0s

readDoor

return the current state of the ChookDoor as one of the set ['open','closing','closed','opening']

If the call on the server is empty, then return the current state as a string representation of 1s and 0s (equivalent to 'settings').

The readDoor request returns the state of the Chook Door, as determined by the previous and current states. To do this, it maintains a global variable DoorState, which can have one of given four states, depending on the following conditions:

open

the chook door proof input is low

closed

the chook door proof input is low

opening

both proof circuits are high, and the chook DoorState was previously closed.

closing

both proof circuits are high, and the chook DoorState was previously open.

3.7 The HardwareClient.py program

A simple little program to test the operation of the Hardware relay software. It reads a pair of digits from the invoking CLI line, and passes them through to the relay driver via the server.

4. The Relay Driver

This is a new development (as of 20220320:153553), which is to replace both the HardwareBone (kerang) and Relay Server/Event Scheduler/Event Manager (terang) system with a single Raspberry Pi 4 Model B system running all of those system components. The main reason for this is the rationalization of the hardware interface (previously done by kerang) into a replacement terang system, now know as reuilly. terang will be kept as a backup system, as it is identical to the new reuilly, but will be kept running until the new system is fully implemented and debugged.

But first, the new relay driver subsystem.

There are three methods in the relay driver class: init, write, and read: init sets up the Raspberry Pi to perform the various I/O operations; write sets a given output pin to high or low; and read returns the value on an input pin.

4.1 RelayDriver: init method

4.2 RelayDriver: write method

4.3 RelayDriver: read method

4.4 Relay Pinouts

The matching of GPIO pins (General Purpose I/O pins) to actual pin numbers on the Raspberry Pi is not intuitively obvious, so here is the mapping to be used:

And now inverted:

5. The Relay Server

Currently a Hardware Bone Black (see previous section) is used to interface to the house relays, and as general data logger and server for the various house functions.

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

There are currently 8 relays wired for operation, but only 5 in use. Possibilities for the new relays include:

• SolarWash

The Hardware Bone also uses a number of inputs. There are 6 inputs currently wired, but only 2 are in use.

(n.o. = normally open)

5.1 Relay Server Code

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.

5.1.1 RelayServer: connect to the HardwareServer

This interface to the Hardware Server is now deprecated - use the relayChannel call instead <relayserver: define the RPC-Server interface 5.4>.

5.1.2 Define the convert State to String function

This short routine converts the internal representation of the current state of the relays into a string form suitable for printing.

5.1.3 RelayServer: define the RPC-Server interface

Note that this interface is the preferred form of communication with the HardwareServer, and replaces the serverSend function, now deprecated.

This chunk defines how the Relay Server (an RPC interface server) talks to the low level Hardware Server (a raw HTTP server). The Relay Server provides high level operations, that allow individual relays to be turned on and off, while the low-level server has an interface that is more primitive.

This allows other programs to talk more directly to the low-level relay interface, without needing the complexity of the RPC interfaces.

These RelayServer RPC interfaces are:

digit+ (0|1)

Set the relay identified by the digit string to the state indicated by a 0 or 1.

readDoor()

Reads the state of the chicken door.

getState()

Returns an array of bits (0,1) indicating the current state of the relays, as defined by the low-level interface (and thus allowing for asynchronous interactions with the relays).

setState(newState)

Resets the relays according to the bits in the array newState, where a '0' indicates the relay is (now) to be turned off, and a '1' indicates the relay is (now) to be turned on. (deprecated)

setBit(relay,newState)

Set the relay identified by relay (numbered 0 and up) to the new state newState.

setBitOn(relay)

Set the relay identified by relay (numbered 0 and up) to 'On'.

setBitOff(relay)

Set the relay identified by relay (numbered 0 and up) to 'Off'.

5.1.4 relayserver: getState

The getState function returns the current state of all relays as a word of zeroes and ones, counting relay 0 as the MSB and showing a 1 where the relay is currently on.

5.1.5 relayserver: quiescent

quiescent returns True if there is currently no timers running.

5.1.6 relayserver: readDoor

readDoor returns the state of the ChookDoor, as a string drawn from the set ['open', 'closing', 'closed', 'opening']

5.1.7 relayserver: setState

The setState function is deprecated, as it now requires too many redundant calls to the Hardware Server to change bits that are not changes. It is preferred that the setBit, and its two subordinates, setBitOn and setBitOff are used instead.

5.1.8 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 is done simply to keep the currentState variable up-to-date: the actual change is made by a call to the HardwareServer to set relay n to 0 or 1.

5.1.9 relayserver: setBitOn

setBitOn sets the relay specified by bit number bitNo to 1 (on).

5.1.10 relayserver: setBitOff

setBitOff sets the relay specified by bit number bitNo to 0 (off).

5.1.11 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.

5.1.12 relayserver: getTimer

5.1.13 relayserver: resetTimer

5.1.14 relayserver: getSolar

5.1.15 relayserver: start

5.1.16 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.

5.2 Starting the Relay Server

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.

It is invoked by the make script as make start-relay.

5.3 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.

This program is used only for testing the Relay Server, and is not used by the HouseMade system per se.

6. The Events Module

This module contains definitions of the Event and EventList classes, suitable for importing into other modules. At the moment, there is no standalone (main) function.

6.1 The Event Class

A significant shift in the design (from HouseMade v2.2.0) is the introduction of the Event class, to encapsulate data pertaining to an event. An event can now occur at any time in the future, and is day of the week aware, as well as time of the year. This has implications for seasonal variations, such as sunrise/sunset times, and for summer/winter changes.

From version 3.0, events are also defined by a dictionary model, using the class dictionary as a vehicle for swapping between the two representation. This is because when events are being passed to and from the EventServer, the rpc mechanism requires a dictionary representation of events.

The Event class provides data that defines an event in the system. There are a number of attributes, and an event can be accessed either as an Event object, through its entities, or as a dictionary, accessed through its keys. The method dictRep allows conversion from the entity-based representation to a dictionary, and the dictn optional parameter allows creation of a new event from the dictionary representation.

The attributes are defined as follows:

weekday

A value in the range 0-6, where 0 represents Sunday, and 6 represents Saturday. This is for events that only occur on specific days of the week. A value of None (or '*') indicates that the event occurs on every day of the week. (currently only '*' implemented)

time

A value in the form HH:MM, representing time in a 24 hour format, and defining the time of day at which an event occurs.

device

The name of the device for which the event occurs. This is a text field, and currently has the values ChookDoor, NorthVegBed, SouthVegBed, and GardenLights.

operation

The parameter for the event. This is also a text field, and has the format

operation=text [',' text]*
text=<any string of characters except ','>

text is defined by the handler routine, but is normally one of the values on, off, up, down, or a string of digits, representing an integer value.

Note that an event can be created with zero or more initial values for these attributes through the use of optional parameters. The optional parameter dictn can be used with a dictionary of values (with keys as for the fields defied above) to initialize the event. These values override any defined with the other values, since the dictionary is evaluated after the static representations are initialized.

Compare this event against another. For comparison purposes, only the times are relevant. If this event occurs first, return -1. If it occurs at the same time as event a, return 0. Otherwise, return 1.

6.2 The EventList class

The EventList maintains a list of events, sorted chronologically. Past events are possible, and are ignored for scheduling purposes.

When adding an event, it is placed into the list according to its time attribute, so that the preceding event has a time value that is the same (see <Event class: compare two events >, and the following event has a time that is the same or later.

The dupl parameter, when True, allows duplicate events to be added. Normally, duplicate events cannot be added when this parameter is False. A duplicate is defined as matching on a set of given attributes, given as a list of attributes. If this parameter is an empty list or None, then the match is defined only on device and operation, NOT time.

The add interface returns the index of the new event in the event list if successful, None otherwise.

Remove a given event from the list.

(Re)sort the event list. This is done with an insertion sort, to ensure that the list is recreated in the same order as when events are added one by one.

Return the first event in the list with time equal or later to the given time stamp now. This has been complicated by the fact that in version 4.1, events can now be specified by day of the week. If the day of the week parameter is '*', then all days of the week are involved. For any other value drawn from the set ['0','1','2','3','4','5','6'], then only that day of the week is to be scheduled (0=Sunday, 6=Saturday).

Return None if there are no such events. (This is a change in the definition - previously the last event would be returned in this case, which violates the postcondition.)

Load events from a file. Existing events are retained, and new events are inserted to preserve the chronological ordering.

Save all current events to a file, which may be later reloaded with load. Be aware that on reloading, any existing events with the same parameters will become duplicate events.

6.3 Events: main routine for testing code

A new feature - each module in this suite is to have a main routine that provides testing facilities for the defined features of the module. This main routine creates Events and EventLists, populates them, and runs a test of each method in the classes.

7. The Event Server

The EventServer is a development of the EventManager program (versions 3.0 and previous) as a means of providing a generic event service. A key difference is that the EventServer provides a remote procedure call interface to the key data structures identifying the events that are managed by the HouseMade system. These events can be accessed and managed through identified RPC interfaces, thus preserved the integrity of the data.

7.1 Event Server calling points

The add event interface is complicated by the fact that complex data structures (such as an event) cannot be passed directly over the RPC interface, but must be converted first to a dictionary representation. Hence the copying of attributes/dictionary entries as the first step. Once the event has been reconstructed, it is added to the event list through the eventlist call el.add. dupl is a boolean flag that identifies (if True) that the new event may be duplicated if it matches another event in the event list, otherwise it will be ignored. The index into the list of the newly added entry is returned.

The remove interface removes event number evn from the event list. Although the code suggests that the event to be renoved can be specified verbatim, this has not yet been proved to be necessary. It may well be removed itself at some stage.

In this model, the setNext interface proved to be somewhat difficult to implement. This version defers most of the hard work to the event list class, and all that happens here is that we make sure that the calling parameters are set correctly. The curday parameter is a case in point: it can either be '*', meaning any and all days participate in the operation, or it may be a specific day of the week (see code fragment <EventList class: nextEvent 6.8>), when only those events scheduled for that day are considered.

Note that advanceNext takes no notice of the day of the week (unlike setNext), but simply steps through the complete list event by event. It is up to the calling environment to decide if the next event is what is wanted.

These are the entry points for calls on the EventServer. The logMsg are commented out until I can work out how to output messages from a server subprocess (it involves using a Queue or a Pipe, see The Python3 Library).

7.2 Event Server: serverprocess routine

The serverprocess routine is the heart of the event server. Its role is to package up the separate process of running the server, while allowing the event manager to manage its events. Not sure about the KeyboardInterrupt, though.

7.3 Event Server: main routine

8. The Event Scheduler

This program takes the place of the old EventManager, and uses the EventServer to maintain the collection of events to be scheduled. Its basic algorithm is much the same: look at the next event from the current time, wait until its time to be scheduled has arrived, and then schedule it.

Events may be added to the event list between now and the scheduling time. Providing that the scheduled time is in the future, the es.showNext call (which is dynamically computed) should collect it. If the added event time is in the past, then it is ignored. If the added event's time is now, then it is indeterminate (a race condition exists) as to whether the event is scheduled, and no guarantees are made.

Each of the devices controlled by the Scheduler have a dispatcher entry point which is called when an operation on that device is scheduled. These are known as the handleEvent methods attached to each device. It has the responsibility for determining exactly what the 'operation' scheduled by the event translates to, whether it be 'off' or 'on', 'up' or 'down', etc..

Most of this is straightforward, except for those events that vary with the seasons. Both the ChookDoor and the GardenSteps are affected by the hours of daylight, and hence the timing of the events need to be computed by the appropriate module. This is performed by a call to 'collect (device) times'.

8.1 EventScheduler: collect ChookDoor times

The EventScheduler has to collect from the ChookDoor object the current opening and closing times, which are computed at ChookDoor initialization. We check the current event list to see what door times are recorded, updating them if they exist, and creating new ones if they do not.

8.2 EventScheduler: collect GardenSteps times

The EventScheduler has to collect from the Gardensteps object the current opening and closing times, which are computed at GardenSteps initialization. We check the current event list to see what times are recorded, updating them if they exist, and creating new ones if they do not.

8.3 EventScheduler: main loop

The main event scheduler loop scans over the event list in chronological order, calling the event server as events become due.

If two or more events are scheduled for the same time, we must be careful that both do get scheduled. Hence the outer loop has responsibility for advancing over the list of events, and only in the case that the next event is not scheduled for the current time (while nowTime!=etime) do we allow the clock to be advanced.

9. The Event Editor

This is a new component to the HouseMade system. It provides a web interface to the EventServer, allowing the user to view and edit the current list of events.

Define global stuff, then the various routines to perform the EventEditor operations.

Now collect the events from the server, and the edit parameters from the URL form.

Examine the request, and perform the appropriate task. add adds a new event to the table, using the current event as the default value. edit updates any edited information, and delete deletes the given element.

9.1 The EventEditor Instructions

9.2 EventEditor: get current events routine

9.3 EventEditor: Make Home Page

9.4 EventEditor: Make Edit Page

10. The Chook Door

This section is being rebuilt, and obsoletes the old section of the same name. The philosophy used is quite different, and is based on an event handling model. This module is the first to be rebuilt according to this model.

This code has been migrated from HouseMade and slightly modified to now work with the EventServer model. The original has been changed to ChookDoor to avoid confusion. Currently (version 1.0.4) the interface does not handle sunrise and sunset times.

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.

The EventScheduler module has the responsibility for driving the chook door events. Each module requiring action at a particular time needs to register with the event scheduler with a request to be alerted when a particular time is reached. This may be a time of day, or every minute, or every hour, or even a day of the week.

This ChookDoormodule just acts as a passive interface, providing the necessary code to actually perform the chook door operation. The are two base level operations: openDoor and closeDoor, with obvious meanings. They communicate by means of a socket connection on port 9999 to the relay server, accessed through the generic interface serverSend.

A third operation chookDoor(p) uses a parameter p to indicate whether an open or close operation is required. Either of 'open'/1 can be used to invoke the opening, or 'close'/'shut'/0 to close the door.

A fourth operation, doorState, can be used to interrogate the current door status.

The routine handleEvent, is the generic interface to the EventScheduler, and bundles all the driver routines.

10.1 ChookDoor: misc routines

10.2 ChookDoor: class ChookDoor

10.2.1 class ChookDoor: init

10.2.2 class ChookDoor: load

10.2.3 class ChookDoor: compute

10.2.4 class ChookDoor: save

10.2.5 class ChookDoor: Open Chook Door

10.2.6 class ChookDoor: Close Chook Door

10.2.7 class ChookDoor: chookDoor

10.2.8 class ChookDoor: doorState

10.2.9 class ChookDoor: handleEvent

10.2.10 class ChookDoor: run

The run routine serves only to create the two main chook door events, opening and closing, registered with the event manager em passed as a parameter. It is intended to be called from the event manager at the start of each day.

10.2.11 class ChookDoor: stop

The stop method is called when all events for the day have been completed. This gives a chance for any event driven module to clean up and save any relevant information before the EventManager terminates and no control thread exists any more.

10.3 ChookDoor: main

11. The Garden Steps Lighting

This module follows the same model as the (revised) ChookDoor module, namely that it defines GardenSteps.handleEvent method that interfaces to the EventScheduler.

12. The Garden Watering System

This module follows the same model as the (revised) ChookDoor module, namely that it defines GardenWater.handleEvent method that interfaces to the EventScheduler.

A major difference with the GardenSteps module, however, is that there is more than one sprinkler. Hence the sprinkler involved has to be passed as a parameter to the event handling routine, and the on/off routines. There are two sprinklers: the SouthVegBed and the NorthVegBed. The dispatcher in the EventScheduler defines a handler for each distinct water section, even though in each case the handler is the same (GardenWater.handleEvent). The distinction between the different watering sections is through the device name, passed as a parameter through the handleEvent methos.

12.1 Garden Run

The run routine registers the various event handlers for the Garden Watering System. At the moment, some default entries for on and off events are registered, although it is not clear that these are necessary for the proper functioning of the module, since the registerEvent routine should be called by the event registering process at the startup of the EventScheduler.

At the moment, it is a case of "if it is working, don't change it".

13. The Ring Main Relay Handler

This module follows the same model as the GardenSteps method that interfaces to the EventScheduler. It is provided to interface the ring main to the automatic system.

See section Event Scheduler for details of how this module is used.

14. The Spare Relay Handler

This module follows the same model as the GardenSteps method that interfaces to the EventScheduler. It is provided so that all the spare relays identified may be tested.

15. The Web Interface

The web interface is a cgi application running on the house computer reuilly, and providing a conventional web page via a port 80 call (the http port number). This web page provides mechanisms to control the house relays manually, and to schedule events that control them automatically.

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.

15.1 The house.py cgi application

This cgi script simply collects a few parameters, and then passes control to the house interface in the HouseMade module. The latter module has the responsibility of generating the web page, which is returned as a string to be printed (rendered) by this cgi script.

15.2 The HouseMade module

This module defines the key elements for the HouseMade system. They are the various subsections that concern the data generating functions: solar, weather, tank, and heating (although some of these are currently decommissioned). Each of these is accessed through a specific routine, called by the last component, the house.py routine, which is the web interface called as a cgi script.

15.2.1 The house interface

{Note 15.3.1}

these idempotent assignments are because MServer/ThisServer are not local variables, and we have to get their content into local variables for use in the next 'u' link!

The house routine has the responsibility of generating the HouseMade web page. There are currently four key sections: local, relay, events, and other. (The latter covers legacy software that may at some stage be re-instated.) Each of these is handled by a code section that returns a variable populated with web-page ready XML code. These are then assembled by the final assignment to the variable housepage, which is returned as the value of the procedure, passed back to the module, and from there accessed by the actual cgi script house.py (q.v.).

15.2.2 Get Local Information

15.2.3 Get Relay Information

The relay information is currently provider by the server running on kerang, which at the moment only relates to the chook door opening and closing. This will be made more generic in the near future.

15.2.4 Get Events Information

15.2.5 Legacy Code

15.2.6 The Relay Information section

15.2.7 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.

15.2.8 define the Generate Solar Data routine

Collect the current day's solar power information for display and generate the related text.

d

the date (format YYYYMMDD)

t

the time (format HHMMSS)

b

battery percentage charge

bc

battery charge (watts, +ve charging, -ve discharging)

Sp

Solar Edge panel generation (logged separately from Fronius)

Fp

Fronius panel generation (logged separately from Solar Edge)

p

total panel generation (sum of Sp + Fp)

f

feed in to grid (+ve export, -ve import)

Sl

Solar Edge load (as logged by Solar Edge software)

Fl

Fronius load (as logged by Fronius software)

l

total load (sum of Sl + Fl)

s

power balance (p-bc+f-l) - this should be zero

minb

the minimum battery charge

15.2.9 define the Generate Tank Data routine

This section now installed on lilydale.

15.2.10 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.

15.2.11 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. (Currently not implemented.)

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. All others pay money, and their names are taken.

15.2.12 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.

15.2.13 Make the Temperature Panel

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.

15.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 6 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 6 blocks total). If six 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.

15.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.

15.3.2 Collect Parameters and Update

check that the arguments are non-empty, then process each argument according to its key k.

15.3.3 Web: heating: handle each argument

In the for loop to handle each http calling argument, each key is checked for validity, and the appropriate action taken.

15.3.4 Build Widths for Web Page Table

15.3.5 Build the web page

16. External Hardware

There are a number of additional elements to the HouseMade system, consisting of various subsystems and the wiring connecting them all. This section documents those elements.

16.1 The ChookDoor Controller

See separate documentation relating to the chook house door controller.

16.2 The Proving Circuitry Monitoring System

(TBC)

17. Test Programs

17.1 Check RPC Operation

The following short fragment of code is intended to check the operation of the RPC mechanisms on the Relay Server. It provides the user with an RPC object, which can be used to invoke the RPC interfaces. Several such 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.

18. The Log Files

The log files for HouseMade.xlp have now been coalesced into one file: /home/ajh/logs/housemade/house.log. All others are obsolete.

19. Installing and Starting the HouseMade Software

19.1 Introduction

This has always been a somewhat fraught area of development since the earliest versions of this software. That is largely due to the variety of both hardware and software in use, and the various idiosyncracies involved. This section attempts to address these issues.

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

1. The Hardware subsystem software, involving a relay driver HardwareDriver.py, a relay/chook door state request server HardwareServer, and the HardwareBone GPIO setup AJH-GPIO-Relay.dts.
2. The House Data Logging Computer relay interface RelayServer.py.
3. chook door (the need for this as a standalone is currently in question).

19.2 Details

19.2.1 Start the Hardware Server

The HardwareServer (aka the chook door server) provides an RPC interface to a) interrogate whether or not the chook door is closed, according to the proving microswitch, and b) drive the relay switching.

The proving circuits are 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 HardwareBone server (kerang), and can be started with the make call:

            make start-hardware
          

This make call just invokes the following script (after making sure that its code is up-to-date) on the HardwareBone (known by its network name kerang). The script can also be invoked directly on the kerang machine from the command line.

If this doesn't work, or you need a more direct interface, then in a window on the kerang machine itself:

            kerang $ /home/ajh/Computers/House/HardwareServer.py
          

19.2.2 Relay Server

The RelayServer runs continously on the House Data Logging computer (currently set as terang. It can be started with a make call:

            make start-relayserver
          

If this doesn't work, or you need a more direct interface, then

            (any machine) $ ssh terang /home/ajh/Computers/House/RelayServer.py
          

20. The Cron Jobs

See the Cron Job page for details.

21. Validation and Maintenance Scripts

This shell script compares the nominated generated file with the installed file in reuilly/newport. Useful to check that versions are aligned, and are up-to-date with local code.

A script to identify any process that is part of the HouseMade system and is currently running. It returns a list of process IDs.

Show the HouseMade programs that are currently running. In normal usage, these should be:

• HardwareServer.py
• RelayServer.py
• EventServer.py (2 instances)
• EventScheduler.py

A script to terminate all processes associated with the HouseMade system.

I found while testing that it was usually convenient to keep the HardwareServer running (especially as it lock up the RPC address until it timed-out), and that only the non-Hardware components needed restarting. Hence this script. Thus the usual development/debug cycle is

        (edit source code)
        make code
        killNonHardware.sh
        testIfRunning.sh
        (explore running system)
        (repeat from step 1) 
      

A script to check if all the relevant programs are running, and restart then if not.

22. Makefile

There are many things that might need to be "make"d. Here is a tentative list, bearing in mind that both the repository and delivery sites may vary over time, and hence hard-coding machine names needs to be avoided.

First of all, a classification of the system components:

Class	Components
Servers	EventScheduler.py*	EventServer.py*	HardwareServer.py*	RelayServer.py*
Modules	ChookDoor.py	Events.py	GardenSteps.py	GardenWater.py	HardwareDriver.py	HouseDefinitions.py
	HouseMade.py	RelayControl.py	RelayDriver.py	RelayTables.py	RingMain.py	Spares.py
Scripts	AllHouseMadePIDs.sh*	compareLoc2Rem.sh*	killAllHouseMade.sh*	killNonHardware.sh	setIOpinConfiguration.sh*	startEvents.sh*
	startHardwareServer.sh*	startRelayServer.sh*	testIfRunning.sh*	testRPC.py	whatsRunning.sh*
cgi-bins	house.py*	eventEditor.py*
Maintenance	config.txt	HardwareClient.py*	HouseMade.html	HouseMade.tangle	HouseMade.xlp	HouseMade.xml
	Makefile	manifest	Versions0-1Modifications	Version2Modifications	WebInterface.xlp

Note that executables are marked with an asterisk (*)

<Servers 22.2> =

install

install all essential components <Makefile: install all 22.8> =

install:HouseMade.tangle install-modules install-cgis install-servers install-web touch install

Chunk referenced in 22.1

make house

install all support components <Makefile: install support components 22.9> =

install-modules: HouseMade.tangle

Chunk referenced in 22.1

make cgis

make executable, and install all cgi-bin components
<Makefile: install cgi-bins 22.10> =

executable: chmod 755 $(executables) install-cgis: install-cgis-newport install-cgis-reuilly cp -p $(cgi-bins) /home/ajh/public_html/cgi-bin # NEEDS TO BE FIXED! install-cgis-newport: HouseMade.tangle executable if [ `hostname` = 'newport' ] ; then \ cp -p $(cgi-bins) /home/ajh/public_html/cgi-bin/ ;\ else \ cp -p $(cgi-bins) newport:/home/ajh/public_html/cgi-bin/ ;\ fi install-cgis-reuilly: HouseMade.tangle executable if [ `hostname` = 'reuilly' ] ; then \ cp -p $(cgi-bins) /home/ajh/public_html/cgi-bin/ ;\ else \ cp -p $(cgi-bins) reuilly:/home/ajh/public_html/cgi-bin/ ;\ fi

Chunk referenced in 22.1

make servers

make executable, and install all server components

make web-components

23. Document History

24. Indices

24.1 Files

24.2 Chunks

24.3 Identifiers