HouseMade - The Hurst HouseHold Heater Helpmate

A.J.Hurst

Version 3.0.4

20201229:133233

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 Beagle Bone System (operational: 10.0.0.20:9999)

The hardware interface to the relay drivers.

The Relay Server (operational: CENTRAL:8001)

Provides an RPC interface to controlling the house relays.

The Event Server (operational: <EventServerRPCaddress 8.2>)

Provides an RPC interface to controlling the various house events.

The Web Interface (operational)

Provides an easy to use interface to the program suite, using two key programs: house and timer (? check). These invoke the house computer.

The Chook Door System (operational)

Controls the opening and shutting of the Chook House Door.

The Garden Steps System (operational)

Controls the switching of the garden steps lights.

The Garden Watering System (operational)

Controls the watering of various garden irrigation outlets.

The Relay Control System (operational)

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

The Heating System (to be reinstated)

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 (to be reinstated)

Provides monitoring of the water storage facilities.

The Solar System (to be reinstated)

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

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.

1.2 TODOs

• Need interlocking so that you cannot turn on chook up when door going down and vice versa.

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 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 consists of a BeagleBone Black (the relay driving processor), which talks to 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 are slowly migrating to the house server (a large rack-based disk farm built from a variety of components). In addition, a Raspberry Pi Model 4 is being developed to handle data collection and logging.

As of Dec 2020, the new system is operational, driving the chook door, garden lights (a new addition to the controlled enviroment), and the garden irrigation system. Further development to reinstate the heating system and data logging systems is underway.

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

(v2.0.0) The new version of CENTRAL is called kerang, and is a BeagleBone running Debian 7.4 (wheezy). This has the unfortunate consequence that it is an old version (and attempts to upgrade it have consistently failed), and has no support for Arduinos, nor an operational Python3. This shortcoming will no doubt have to be addressed in future.

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

3. The BeagleBone System

There are four software components to this system:

The GPIO-Relay Device Tree Specification

Defines the BeagleBone GPIO pins configurations. See Derek Molloy's excellent tutorial page for more information.

BeagleDriver

The bottom layer software to hardware interface.

BeagleServer

An interface to the outside world, providing primitive calls to control the attached relays.

BeagleClient

A simple program to test the server interface.

3.1 The GPIO setup

See Derek Molloy's excellent tutorial page for more information. I just followed his example to set things up. The steps were:

1. Create and edit this dts file
2. Compile it using the dtc compiler to generate a dtbo file:

                 dtc -O dtb -o AJH-GPIO-Relay-00A0.dtbo -b 0 -@ AJH-GPIO-Relay.dts
               

   (The build script in boneDeviceTree/overlay does this.)
3. echo AJH-GPIO-Relay >$SLOTS
4. Copy the dtbo file into /lib/firmware on the BeagleBone.
5. In the /sys/class/gpio directory, create links to the gpio pins. For example, for GPIO23 (P8_13), an input:

                 echo 23 > export  # create the link
                 cd gpio23         # check it now exists
                 cat direction     # it should be 'in'
                 cat value         # should change from 0 to 1 when input goes high
               

3.2 Restarting the BeagleBone Server

There are two issues:

1. Setting up the device from scratch (e.g., system install), and
2. After a reboot

3.2.1 Restore the Pin Definitions

The Beaglebone is rather special in that it allows software reconfiguration of its I/O pins. For our purposes, we need to follow through on the configurations defined in section GPIO Setup, and setup the user interfaces to these hardware pins. Most of this is not necessary if the relevant programs run as root, but we change the permissions here so that users can also interact with the hardware.

The settings here are lost on a reboot, and so it is necessary to run this script after each reboot. Note that this script must be run as root.

The key thing to note is the list of pin numbers 30 60 31 50 51, 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).

Next, we define the input pins 46 47.

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

3.2.2 Restart the BeagleBone Server proper

Once the pin definitions are restored, the BeagleBone server can be restarted. This is done with a simple

            $ ~/Computers/House/BeagleServer.py &
          

3.3 the BeagleDriver.py program

This code provides a class that drives the relays directly through the GPIO pins of the BeagleBone. The init method of the class creates a file for each GPIO pin in use. This file is available for writing, and 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 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 fifth and last 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 '.'.

3.4 The BeagleServer.py program

This code runs a server to interface with the relay driver code (BeagleDriver.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. The handle method returns the new state as a string representation.

There are three additional imputs that are recognized: reset, sterile, and virile. The first returns all relay states to off, and the second and third control the driver activity, as described above in <BeagleDriver.py 3.3>

3.5 The BeagleClient.py program

A simple little program to test the operation of the Beagle 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 Server

Currently a Beagle 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. (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
• ?

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

4.1.1 RelayServer: connect to the BeagleServer

This routine is a more basic BeagleBone server connection than the RelayChannel routine, described below. It does nothing more than send and received raw data from the BeagleBone server, which is responsible for actually energising the various relays. Only one item of data is received and returned for each invocation of the routine, and the received parameter can be

''

The empty string, which will retrieve the current status of the relays in the form of a string of '.'s or 'o's, with the former indicating the corresponding relay is not energised, and the latter indicating that it is. The relays are numbered zero origin from the left of the string.

dd

A pair of digits, the first of which is a relay number, and the second of which is a 1 or 0, indicating the the corresponding relay is to be turn on or off respectively.

read

The word 'read', which reads the current state of the chook door as a pair of diigits, the first/leftmost for the up proving circuit, the second of which is for the down proving circuit. '0' indicates that the circuit is proved, '1' indicates that it is not.

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

4.1.3 RelayServer: define the RPC-Server interface

This chunk defines how the Relay Server (an RPC interface server) talks to the low level 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 just a string of "bits", indicating the new desired state of the relays. This string contains '.'s and 'o's, indicating 'off' and 'on' relays, numbered from 0 from the left, up to the total NumberOfRelays (minus one, because of zero-origin indexing).

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

These RPC interfaces are:

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.

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

4.1.4 relayserver: getState

4.1.5 relayserver: readDoor

4.1.6 relayserver: setState

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

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

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

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

4.1.11 relayserver: getTimer

4.1.12 relayserver: getSolar

4.1.13 relayserver: start

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

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

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

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

The Event class provides data that defines an event in the system. There are a number of attributes, defined as follows:

month

The month of the year, and integer in the range 1-12, representing the months January-December. A value of none indicates the event occurs every month of the year.

day

The day of the month on which the event occurs, an integer in the range 1-31. A value of None indicates that the event occurs every day of the month.

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 indicates that the event occurs on every day of the week.

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, SouthVegBed, and GardenLights.

operation

The parameter for the event. This is also a text field, and currently has 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.

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.

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

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

8. The Event Server

Define the address of the EventServer port.

The EventServer is a development of the EventManager as a means of providing a generic event service.

8.1 Event Server Log Message Handling

8.2 Event Server calling points

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

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

8.4 Event Server: main routine

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

Some thought does need to be given to events that may be added to the event list between now and the scheduling time (should they be ignored, should they take precedence of the current next event, etc.). A possible solution: if the next event's time is now, then schedule it. Otherwise, sleep for a minute, and then recheck the next event. It is possible that the wait time should be less than a minute, to allow for processing time, which could see the wait time to be longer than a minute, thereby missing the scheduling time of an event.

Also, if two or more events are scheduled for the same time, only one will be scheduled. It is indeterminate which of the simultaneous events will be scheduled. This needs further careful thought.

Some thoughts. Create a 'mark now' which identifies the initial next event time. Set a pointer to mark the next event. Provide an interface to inspect the next event (but keep the same marker). Provide a separate 'move marker' to advance to the next event. This should get around the duplicate schedule time problem. But do need to check times of events, particularly that we don't fall behind in processing duplicate events.

11. 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 running on kerang, 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.

Important Note: This interface may change later, when the relay drivers are moved to the new house computer, ouyen. Then the code will be moved to a generic Relay Driver.

11.1 ChookDoor: misc routines

11.2 ChookDoor: class ChookDoor

11.2.1 class ChookDoor: init

11.2.2 class ChookDoor: load

11.2.3 class ChookDoor: compute

11.2.4 class ChookDoor: save

11.2.5 class ChookDoor: Open Chook Door

11.2.6 class ChookDoor: Close Chook Door

11.2.7 class ChookDoor: chookDoor

11.2.8 class ChookDoor: doorState

11.2.9 class ChookDoor: handleEvent

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

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

11.3 ChookDoor: main

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

13. 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. Currently there is only one sprinkler, though: the SouthVegBed. 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.

14. The Web Interface

The web interface is cgi application running on the house computer ouyen, and providing a conventional web page via a port 80 call (the http 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.

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

14.2 The HouseMade module

14.2.1 The house interface

14.2.2 Get Local Information

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

14.2.4 Get Events Information

14.2.5 Legacy Code

14.2.6 The Relay Information section

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

14.2.8 define the Generate Solar Data routine

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

14.2.9 define the Generate Tank Data routine

This section now installed on lilydale.

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

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

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

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

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

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

14.3.2 Collect Parameters and Update

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

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

15.1 The C Weather Monitor Program

(Details to be recorded)

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

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

16. The Heating System

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

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.

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

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

17. The Tank System

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

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

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

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

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

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

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

19. The House Computer

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

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

19.2.1 HouseData define getTemps

19.2.2 HouseData define maxminTemp

19.3 The startHouseData.sh script

20. The Event Manager

This section has been superceded by the EventScheduler module, and has its code sections commented out.

This was a new section in version 2, and represented a change in thinking on how best to do the timing of events in the house environment. One factor is the ability to provide trace-back analysis when things go wrong, and to maintain a permanent record of what has been happening. This means migrating a significant amount of data into files, rather than hard-coding it into programs and program structures.

The model is this:

1. The event manager runs continuously, normally asleep, and once a minute wakes up to see whether an event is ready to be invoked.
2. Each module requiring some timed activity must register its event with the event manager, along with the timing details, and a handler for when the event occurs.
3. When an event's time is reached, the event manager passes control to the event handler, which handles the event before returning control (although it could spawn a separate thread before returning control if it needs a significant amount of time).
4. The handler may do various things, including re-registering itself with the event handler for a future event.

The eventManger module provides a class to do all the management of events in the house system. It no longer maintains a file of saved events.

Thinking aloud bit: I have generated a bit of self confusion over what modes of operation should be implemented. Here is a table of what should be happening:

Because debugging is the more commonly thought-of mode of testing, it is actually a shorthand for setting both the testing and fastmode simultaneously. It is (currently) unused otherwise, but could be used in future to control other debug information.

20.1 The Event class

20.2 The Clock

The Clock routine is the heart of the Event Manager. It runs continously once the Event Manager has been initialized, invoking the handler for each event as the appropriate time arrives. It terminates only when there are no events left (which should be before the end of the day, but this is an assumption that may need to be changed).

The fastmode flag causes the clock to run 60 times faster, i.e., 1 second real time represents 1 minute of simulated time. This is useful for debugging.

20.3 Event Manager: main

main has two parameters testing, and fastmode. testing is what is normally thought of as a debug mode, and disables any actual activation of controlled operations, printing a test message instead. fastmode gives finer control over testing. When set False, events are scheduled and handled in real time, as determined by the Clock routine. When set True, events are processed in sequence, with no waiting between each event, other than the raw time taken by each event.

In the True scenario, if more time is required between each event, then either include a specific 'sleep' in each event, or add a generic 'sleep' in the while True loop above.

20.4 The Event Manager class

20.4.1 the sortEvents method

sortEvents sorts the events into chronological order, assuming (for now) that all the events are taking place today, and determines what is the next event to occur. This is so that a timer thread may be started, which will wake up when the event is to take place. To this end, the time difference between now and the next event time is computed.

20.4.2 the getNextEvent method

getNextEvent scans the current list of events, looking for the next event from the current time. If found, that event is returned, along with the number of seconds to go before the event, and the number of events scheduled after this event.

Otherwise, None is returned to indicate that all events have been scheduled.

The EventManager entity self.nextEventNumber keeps track of which number the next event in the list of events should be examined. This is done to speed up the search.

20.4.3 Handle an event

20.4.4 Register an Event

21. Test Programs

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

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

23. Installing and Starting the HouseMade Software

23.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 Beagle subsystem software, involving a relay driver BeagleDriver.py, a relay/chook door state request server BeagleServer, and the BeagleBone 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).

23.2 Details

23.2.1 Start the Beagle Server

The BeagleServer (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 BeagleBone server (kerang), and can be started with the make call:

            make start-beagle
          

This make call just invokes the following script (after making sure that its code is up-to-date) on the BeagleBone (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/BeagleServer.py
          

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

24. The Cron Jobs

Currently no cron jobs are required.

25. Makefile

25.1 RelayServer Makes

25.2 BeagleBone Makes

25.3 Makefile: install bastille

26. Document History

27. Indices

27.1 Files

27.2 Chunks

27.3 Identifiers

118 accesses since 20 Jul 2020, HTML cache rendered at 20210125:1633