HouseMade - The Hurst HouseHold Heater Helpmate

A.J.Hurst

Version 2.1.5

20200920:142356

Table of Contents

1. Introduction

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

1.1 Overview

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

The Web Interface (operational)

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

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 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 House Computer (obsolete)

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

The Relay Control System (operational)

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

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

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

3.4 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 House Data Server and Relay Control System

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

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

Possibilities for the new relays:

• solarwash
• ?

4.1 Relay Server

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

4.1.1 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.2 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.3 relayserver: getState

4.1.4 relayserver: readDoor

4.1.5 relayserver: setState

4.1.6 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.7 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.8 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.9 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.10 relayserver: getTimer

4.1.11 relayserver: getSolar

4.1.12 relayserver: start

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

5. The Event Manager

This is a new section in version 2, and represents 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.

5.1 The Event class

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

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

5.4 The Event Manager class

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

5.4.2 the getNextEvent method

5.4.3 Handle an event

5.4.4 Register an Event

6. The Event Server

The EventServer is a development of the EventManager (and indeed, imports the EventManager as a class) as a means of multiprocessing the two operations of running an event manager, and providing a server interface to the data of the event manager. Most of the calling points of the event server as simply wrappers to the corresponding methods of the event manager.

Note: This code is deemed non-functional and is to be ignored for now. It fails because the event manager data structure (e in the code above) is not adequately shared across multiple processes - only the inial copy is shared, and updates are not seen by the EventServer itself.

6.1 Event Server: strEvent routine

Return a printable version of the event parameter.

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

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

6.4 Event Server: main routine

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

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 EventManager module has the responsibility for driving the chook door events. Each module requiring action at a particular time needs to register with the event manager 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.

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.

7.1 ChookDoor: misc routines

7.2 ChookDoor: class ChookDoor

7.2.1 class ChookDoor: init

7.2.2 class ChookDoor: load

7.2.3 class ChookDoor: compute

7.2.4 class ChookDoor: save

7.2.5 class ChookDoor: Open Chook Door

7.2.6 class ChookDoor: Close Chook Door

7.2.7 class ChookDoor: chookDoor

7.2.8 class ChookDoor: doorState

7.2.9 class ChookDoor: handleEvent

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

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

7.3 ChookDoor: main

8. The Garden Steps Lighting

This module follows the same model as the ChookDoor module, namely that itdefines a class GardenSteps has a run and a stop method. The run method registers the current events (turn lights on, turn lights off) with the EventManager, and the stop method is called to clean up when all events are done. The other methods included are fairly self explanatory.

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

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.

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

9.2 The HouseMade module

9.2.1 The house interface

9.2.2 Get Local Information

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

9.2.4 Legacy Code

9.2.5 The Relay Information section

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

9.2.7 define the Generate Solar Data routine

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

9.2.8 define the Generate Tank Data routine

This section now installed on lilydale.

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

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

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

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

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

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

9.3.2 Collect Parameters and Update

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

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

10.1 The C Weather Monitor Program

(Details to be recorded)

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

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

11. The Heating System

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

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

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

12. The Tank System

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

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

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

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

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

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

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

14. The House Computer

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

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

14.2.1 HouseData define getTemps

14.2.2 HouseData define maxminTemp

14.3 The startHouseData.sh script

15. Test Programs

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

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

17. Installing and Starting the HouseMade Software

17.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 Computer (currently newport, but soon to be migrated to ouyen) relay interface RelayServer.py.
3. chook door (the need for this as a standalone is currently in question).

17.2 Details

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

17.2.2 Relay Server

The RelayServer runs continously on the House computer (aka Central, currently set as newport, but about to be changed to ouyen. 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 newport/ouyen /home/ajh/Computers/House/startRelayCentral.sh
          

18. The Cron Jobs

Currently no cron jobs are required.

19. The Makefile (separate file)

19.1 RelayServer Makes

19.2 BeagleBone Makes

19.3 Makefile: install bastille

20. Document History

21. Indices

21.1 Files

21.2 Chunks

21.3 Identifiers

27 accesses since 20 Jul 2020, HTML cache rendered at 20200925:1153