Weather Station Part 3 - Event Communication

This is the third post in a series discussing the development of a home weather station using Storyboard as the embedded user interface.

To recap: The first post provided a general overview of the product we want to build, the second post contained a rough block architecture diagram of the software components and their communication paths.

With the communication paths established, we can define the set of Storyboard IO events that will contain the actual data we want to communicate.  These event definitions are what will enforce the separation of the user interface from the system (sometimes called business) logic in our MVC style design.  The event definitions provide an API contract that gives us a certain freedom of choice about how we ultimately feed information to our user interface.

We will define the events using the same module names as in the architecture block diagram.  All Storyboard events are named and contain a payload definition so that we can start using them in Storyboard Designer right away without knowing how the final client implementations will supply that data.

Temperature
Name: temperature_change
Format: 4s1 degrees
Description: Reports the current temperature in degrees celsius

Barometer
Name: barometer_change
Format: 4s1 pressure
Description: Reports the current barometric reading in kilopascals

Wind Information
Name: wind_change
Format: 4s1 speed 4s1 direction
Description: Reports the current windspeed (in knots) and the direction in degrees (0-360)

These events are all received by the Storyboard based user interface (UI) process.

The frequency at which these events are generated will be controlled by the implementing driver, but should be no more frequent than every 1Hz (one event per second second).

Remote Feed
Name: location_configure
Format: 4s1 action 1s0 name
Description: This event is used to indicate the addition or removal of a location by name to the remote feed monitor.
The actions are currently defined as:

0x0: Add a location to the monitored set
0x1: Remove a location from the monitored set

The name is a null terminated string with the city or location name

Name: remote_temperature_change
Format: 4s1 degrees 1s0 name
Description: Reports a change in temperature of a remote location

The remote feed information will initially be targetted at a single location, but in the future monitoring of multiple locations should be possible.

We also need to determine how we want to incorporate long term forecast information. In some cases we may want multi-day forecast information (ie 5 or 7 day) and in other cases we may simply want extended forecast information (morning, afternoon, evening). There are a finite number of combinations so we could easily incorporate them as flags into the location_configure event and create a new forecast event that contains a UTC timestamp indicating the forecast predition information. For now we will leave this out of our event definitions, but remain confident that adding it in at a later point won't derail the current design.

Now with the events defined, we can incorporate them directly into the Storyboard model and start building the user interface around the data that these events will produce. We don't need to know how the events will be generated, and for test purposes we can synthetically generate Storyboard IO events with a simple test script, written in either C/C++ or Lua.

In the next post we'll start looking at the user interface's data bindings and we'll start putting together a rough mock-up of those bindings using Storyboard Designer ... all still without any hardware or operating system selection having been finalized!

Thomas