Part description

This software package includes the lower level functionality of the software stack as well as a shell-based interface to the home automation stack.

Concepts

Single devices (end devices, e.g. light switches or output channels) are identified by the CAN device address and the I/O number on that CAN device. To these I/O identifiers, clear text names like "living room, TV set outlet" can be assigned. The ha_named can do a lookup in the configuration database and fill in a device information structure from either the I/O identifier or the plain text name.

I/O devices can be grouped together for (pseudo-)simultaneous addressing by higher-level software. The interpretation of group definitions and the enqueueing of the devices contained therein is done by ha_control.

Input devices are linked to output actions - the easiest example being a light switch directly linked to the respective output control channel. Input devices can also control groups of output devices. They are also managed by ha_control.

Input activity or other event sources (like sensor readings, time of day, or even a pseudo-random number generator) can also trigger complex actions, which are defined as macros. These are written in a simple macro language, allowing output actions to be executed in several ways. Macros, again, are managed and executed by ha_control, which may fork subprocesses for the actual execution of the macro commands.

Monitoring of the said sensors, by the way, is not needed as these are to report to the controller when they find something of interest. How exactly this is implemented is depending on the type of sensor in question, but the definition of actions on certain sensor reportings is also a matter of ha_control. How it does all this, and how it's architecture looks like, is documented in HomeAutomation/ControlConcepts and HomeAutomation/SoftwareArchitecture.


Revisions

HA-P03.01

Current development revision.

Dependencies

This revision depends on some Python modules not included in the base library. The FreeBSD port names are given in parentheses.

ha_calc

(C, <okay> )

This helper application calculates bus numbers, device addresses and, if required, message type identifiers from a given numeric CAN ID:

> ha_calc 
Usage:
  ha_calc CANID
  ha_calc BUS DEVID [MTID]
> ha_calc 771
CANID 771: bus 0, devid 3, mtid 6
> ha_calc 0 3
CANID 3: bus 0, devid 3, mtid 0

ha_common

(Python, <wip> )

In these Python modules, a general framework for the upper layers of control software is implemented. /Objects, /Events, /Actions, and /Rules are defined here and can be imported from several modules.

Also it provides the Resolver class that can do lookup calls to ha_named and return a devinfo dictionary containing information neccessary for identifying and communicating with the given device:

rsv = Resolver(''hostname'', ''port number'')
devi = rsv.devinfo(''DDD.II'' | ''device alias string'')

devi := { \
  'devaddr': (INT), \
  'ionum': (INT), \
  'attrs': [(STRING), (STRING), ...], \
  'name': (STRING), \
  'status': (STRING) \
}

attrs := IN_VALUE | IN_SWITCH | OUT_VALUE | OUT_SWITCH
status := EMPTY | FOUND | NOTFOUND

ha_control

(Python, <blank> )

Here is the documentation for the actual implementation of the ha_control program. A general explanation about how the system handles input and output is on another page, HomeAutomation/ControlConcepts. ha_control basically reads the layout of the HomeAutomation system from configuration files, verifies the integrity of the systems attached, and runs an instance of the /HAControl object, which is responsible for /Rules management.

ha_dispatchd

(Python, <blank> )

This daemon is just a protective layer between the user interface programs and the ha_control daemon. It contains little logic in itself, but does check for authorization on incoming requests for action before handing these to the control daemon.

ha_iod

(C, <test> )

This daemon opens and maintains the serial connection to the CAN bus interface, it buffers and serializes all bus transmissions (incoming and outgoing). ha_iod provides an interface to the rest of the software stack by means of TCP connections.

ha_iod contains little logic besides the device management and message buffering, messages passed to it must be preformatted for more or less direct transmission to the bus interface, and messages being passed to the software stack by it are little more than raw CAN datagrams.

ha_named

(Python, <test> )

Provides resolver services for BusAddress.IONumber combinations to human-readable names and vice versa.

hashell

(Python, <wip> )

The command line interface to the rest of the software stack will be used in development of software and hardware, and may later serve as debugging interface and to access certain administrative or low-level functionality - or just to control the system from non-graphical terminals.


CategoryElectronics


THIS DATA IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DATA, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

All product and brand names mentioned on there pages and in the source code are registered names and/or trademarks of the respective owner and are mentioned for identification purposes only.

For a full copyright notice, please see this link. For imprint and contact information, please see http://www.thiemo.net/.

HomeAutomation/Parts/HA-P03 (last edited 2012-05-18 21:39:08 by ThiemoNordenholz)