MH Weather Alert

Original motivation and basic research links are in the first project blog entry. There have been several updated blog posts since then in the same Project blog.

Status

The project is currently in the prototype phase. There are 4 different design areas where prototypes are in development or planned. Using separate prototypes breaks what is a relatively large design problem into separate, smaller design problems. This is beneficial in that each problem can be solved independently, early prototypes can be functional while the overall project progresses, and each block can be used as independent functionality for other projects.

• Prototype - NOAA Poller" class="wiki wiki_page">NOAA Poller
• Concept - MH Distributed Speech
• Concept - MH Persistent Process
• Concept - MH Process Object Communication

Introduction

This project will add a NOAA CAP (www.weather.gov/alerts-beta/) poller to Misterhouse that will issue TTS messages to xAP speech clients on the local LAN for severe weather events. There are a number of challenges that must be overcome. The primary challenge is the rate of polling. Most MH scripts start a new process_item each time an Internet source is polled; this is needed to keep blocking processes (e.g. retrieving a URL) from causing pauses in the polling loop. In the case of a NOAA CAP alert system the rate of polling may be rather high (e.g. every minute). In this case starting a new process every minute or so could be a burden on the system. This project will attempt to create a long running process_item that does not intentionally exit; this may require new functionality to support monitoring, restarting, and killing a process_item. Another design challenge with Misterhouse is that separate processes do not have a built-in method for communicating with the main polling loop. To overcome this the project will use xAP messaging to communicate MH object updates; one nice advantage of this approach is that the NOAA poller will not need to run on the same hardware as the main MH polling loop.

Software Architecture

Speech event delivery is still TBD

The architecture consists of a poller that runs as a process_item that will never exit. The poller retrieves CAP feeds from the NOAA weather alert servers. The poller will then send xAP speech/wav messages for NOAA CAP alerts that have been filtered for location and severity. The poller is also capable of sending other xAP messages that can be used to synchronize CAP objects visible to the MH polling loop. This allows Misterhouse to react to CAP events. For instance Misterhouse could change the default page to display the most recent CAP "alert" with a radar image for weather events.

Design Discussion

The overall architecture is not fully defined yet. More research is required for the Misterhouse xAP internals. The biggest design choice revolves around how speech events are delivered. There are currently two choices for architecture.

1. The most straight forward way is for the NOAA poller to send Misterhouse object updates to MH using xAP. Common code in the main polling loop would then react to the object state changes and call the MH speak() function. MH will then use any configured speech routine and can send xAP tts.speak events to xAP clients on the network.
2. The second method is for the NOAA poller to send MH object updates to MH using xAP and directly send xAP tts.speak events to the xAP clients on the network. When using this method, the normal MH speak() function can not be used because it would duplicate the xAP tts.speak events. It is not clear how the MH internal speak routines can be activated using this method. It is possible to have MH recognize externally generated xAP tts.speak events and execute the internal routines, but this may require development.

Of the methods the second one is preferred because it shortens the path from alert to audible speech removing potential points of failure and complexity.

Major Functional Blocks

Each of the 4 major subsystems and their prototypes are summarized below along with links to pages that detail each the design and implementation.

• NOAA Poller" class="wiki wiki_page">NOAA Poller - The NOAA poller will eventually be a standalone CPAN module that can poll, parse, and present NOAA CAP 1.1 alert events. The poller is built on a Perl class module that remembers published alerts so that the CAP entry is only pulled once. This process only requires periodic polling of the relatively small forecast zone ATOM feed.
• MH Distributed Speech - xAP is used to distribute the alert speech events and play introductory warning tones. A recent update to the xAP speech schema includes a parameter for an introductory sound. This is perfect because it solves the problem of playing an alert tone prior to speaking the alert. There are now two components that need to be designed, an xAP speech module for the weather alert script and a xAP speech client for Windows. It may be possible to use one of the existing clients if one can be found that supports the sound= parameter. This project will build a new client because none of the existing implementations are open source.
• MH Persistent Process - The NOAA poller needs to run at a fairly high rate i.e. every 2 minutes. This project will spawn a process that sleeps between runs but otherwise stays in existence. This should have a much lower overhead than starting a new process item for every polling period. There are many design challenges with this approach because MH doesn't currently provide much in the way of process control and monitoring; MH will require additional functionality to to monitor the process and restart it if it dies.
• MH Process Object Communication - xAP is used for communication between the main MH polling loop and the weather alert process. This will permit exchanging control data and alert object data with the main MH polling. An alert object for MH tracks the current alert state. Other parts of MH can base their behavior on this object. For example the main MH web page might display the alert text and a radar image during an active warning.

Overall Project Requirements

This section lists the overall project requirements from a user's perspective. It does not define the implementation other than to specify Misterhouse as the overall automation vehicle. The key word "should" implies design goals and potential future functionality. The key word "must" implies hard design requirements for the first complete release. Software will remain in beta until all of the "must" have requirements are implemented.

1.0 - General Requirements

1.1 - The system must be integrated into the Misterhouse automation system
1.2 - The system must support Windows XP and Debian Lenny
1.2.1 - The system should support any Windows version and Linux distribution
1.3 - The system must support Perl 5.8
1.3.1 - The system should support any Perl release greater than 5.8

2.0 - Alert Polling

2.1 - The system must support alert notifications from the US NOAA alert servers
2.1.1 - The system must support all alerts defined by NOAA in addition to weather
2.2 - The system should minimize the delay between alert updates by NOAA and announcements
2.3 - The system should minimize the polling impact on the NOAA servers
2.4 - The system should minimize the performance impact on the polling hardware
2.5 - The system must support polling more than one forecast zone for each alert agency
2.6 - The system may support polling more than one alerting agency
2.7 - The software architecture, data structures, and procedures should support a structure that permits polling of more than one alerting agency
2.8 - The software architecture, data structures, and procedures should support a structure that allows easily adding additional alerting agencies

3.0 - Alert Filtering

3.1 - The system must provide mechanisms for filtering alerts so that user selected alerts can be ignored
3.2 - The system must provide mechanisms for filtering alerts based on NOAA forecast zone
3.2.1 - The system should define forecast zones generically so that the concept applies to other alert systems from other agencies and countries
3.3 - The system must provide user configurable alert actions
3.4 - Alert actions should include text only display, text to speech, and warning sounds followed by text to speech

4.0 - Alert Announcements

4.1 - The system must support broad distribution of alert notifications
4.2 - The system must support text to speech
4.3 - The system must support configurable alert sounds prior to text to speech
4.3.1 - The system must not issue more than one alert sound per polling interval
4.3.2 - The system must select the alert tone from the most critical event for that polling interval
4.4 - The system must support configurable repeat intervals for active alerts
4.5 - The system must support prioritization of speech events so that notifications for the most critical events are delivered prior to less critical events

5.0 - Configuration

5.1 - Actions for every unique alert must be user configurable
5.2 - User supplied warning tones must be user configurable
5.3 - Forecast zone selection must be user configurable
5.4 - Alert repeat intervals must be user configurable
5.5 - User options should be configurable within the Misterhouse web interface

6.0 - Test

6.1 - The system must support test notifications that verify the overall speech delivery

7.0 - User Interface

7.1 - The system must provide a Misterhouse web page listing the currently active alerts and showing the alert text
7.2 - The system should provide a table in a Misterhouse web page where the user can reconfigure existing alert actions and add new alert types
7.3 - The system must provide instructions in the web interface for selecting and configuring the forecast zone