galaxybus.html

<h1>Galaxy bus polling system</h1>
<p>The command line tool galaxybus starts a daemon that polls one or more RS485 buses to operate Honeywell alarm devices, including:</p>
<ul>
<li>Keypad display control units</li>
<li>"Max" reader / door control units</li>
<li>"RIO" general purpose input/output units</li>
</ul>
<h2>Command line</h2>
<p>In addition to a library there is also a command line build, this provides some diagnostics operations and useful commands for testing.</p>
<h2>Library</h2>
<p>The code defines a library that provides the data objects for such devices with suitable status bits that can be accessed using the same memory between threads. It also provides the functions to start polling a bus, and for reporting events and queuing commands.</p>
<p>The principle is that the library manages the low level devices at a logical level that handles all timing aspects, using a thread with real time scheduling. This leaves the linked in application to respond to events they arrive and take actions as necessary.</p>
<h2>Logging</h2>
<p>The system includes debug logging and event logging, all provided as part of the library.</p>
<h2>Keep alive</h2>
<p>The library includes periodic event reporting to allow a system keep-alive / watchdog.</p>
<h1>Alarm system</h1>
<p>One of the key applications will be an alarm system. It is envisaged that the application level will probably operate using a mysql back end, this would contain configuration, status, and so on, so that a simple web based front end or other systems can be used to manage the whole system.</p>
<p>Apart from responding to events it is expected the application will periodically run, and pick up things it may be expected to do - this could be a request queue in a mysql table, or things that depend on time of day, etc.</p>
<p>A key principle of the design is that timing of actions and events, like how long a key fob pressed to count as an "alarm set request", or timing the door release, etc, should all be part of the polling library - freeing the application from time sensitive operations. That said, things like a key fob event will want a rapid response to say "open door" for example.</p>
<h1>Library</h1>
<p>The library is galaxybus.o, and uses galaxybus.h for reference.</p>
<h2>Data structures</h2>
<p>Data structures exist for</p>
<ul>
<li>Bus, including the input, output and tamper</li>
<li>Keypad, i.e. allowing setting beeps and text</li>
<li>Max reader - presents some fixed inputs and outputs</li>
<li>RIO - config for inputs and outputs</li>
<li>Event</li>
</ul>
<p>A set of inputs exists as a bit map, for RIO these are the actual inputs, for Max, they are exit and door open sensors. One input is logically "present".</p>
<p>A corresponding set of tampers exists, one per inputs. The main tamper for the device is against the logical "present" input.</p>
<p>A set of outputs exists, for RIO these are the real outputs. For Max they are door open relay, LEDs and the beeper.</p>
<p>The keypad has extra settings, being the actual text on display and state of beeping - these are picked up as polled.</p>
<p>The documentation of the structures is in the include file for the library.</p>
<h2>Functions</h2>
<p>Functions allow the start and stop of a bus thread, and the addition of devices to the bus polling.</p>
<p>The functions are documented in the include file.</p>
<h2>Events</h2>
<p>An event queue uses shared memory to queue event structures. A function exists to get next event, with a timeout.</p>
<p>Events relate to change of input values, change of tamper values, and some special events such as keypad keys and max reader keyfob.</p>
<h1>Doors</h1>
<p>See <a href="doorstate.html">.</p>