BEGIN INTEGER A,B,C,D,E,F,G,ANS'
READ A,B,C,D,E,F,G'
ANS:=(A+B+C+D+E+F+G)/7'
PRINT ANS'
END'

Can you identify the language and the computer it ran on?

1) Well written using encapsulation and other good practices
2) Able to be easily serialized to disk
3) Able to handle temporal events easily (After … At … Every …)
4) Disk serialized form must expose a property saying when it next needs to be fetched from disk to run
5) Implements hierarchical states with entry and exit actions

So I built one, and have made the source code available on Nuget so you can add it to any project easily without any extra DLLs.

Look for “AboditStateMachine” on Nuget to download it. The download includes a sample state machine documented to show off some of its capabilities.

Defining states is easy, just give them a name and specify their parent state if any:-

        public static readonly State UnVerified = AddState("UnVerified");

        public static readonly State Verified = AddState("Verified");

        // States are hierarchical.  If you are in state VerifiedRecently you are also in is parent state Verified.

        public static readonly State VerifiedRecently = AddState("Verified recently", parent: Verified);
        public static readonly State VerifiedAWhileAgo = AddState("Verified a while ago", parent: Verified);

You can use any other type that’s IEquatable as an Event type or you can use the provided Event class:

        private static Event eUserVerifiedEmail = new Event("User verified email");
        private static Event eScheduledCheck = new Event("Scheduled Check");
        private static Event eBeenHereAWhile = new Event("Been here a while");

The state machine itself is specified in a static constructor so it runs just once no matter how many instances of the state machine you create. Each method is provided with an instance of the state machine ‘m’ as well as the state ‘s’ and the event ‘e’ as appropriate:

        static DemoStatemachine()
        {
            UnVerified
                    .OnEnter((m, s, e) =>
                        {
                            // States can execute code when they are entered or when they are left
                            // In this case we start a timer to bug the user until they confirm their email
                            m.Every(new TimeSpan(hours: 10, minutes:0, seconds:0), eScheduledCheck);

                            // You can also set a reminder to happen at a specific time, or after a given interval just once
                            m.At(new DateTime(DateTime.Now.Year+1, 1, 1), eScheduledCheck);
                            m.After(new TimeSpan(hours: 24, minutes: 0, seconds: 0), eScheduledCheck);

                            // All necessary timing information is serialized with the state machine
                            // The serialized state machine also exposes a property showing when it next needs to be woken up
                            // External code will need to call the Tick(utc) method at that time to trigger the next temporal event
                        })
                    .When(eScheduledCheck, (m, s, e) =>
                    {
                        Trace.WriteLine("Here is where we would send a message to the user asking them to verify their email");
                        // We return the current state 's' rather than 'UnVerified' in case we are in a child state of 'Unverified'
                        // This makes it easy to handle hierarchical states and to either change to a different state or stay in the same state
                        return s;
                    })
                    .When(eUserVerifiedEmail, (m, s, e) =>
                    {
                        Trace.WriteLine("The user has verified their email address, we are done (almost)");
                        // Kill the scheduled check event, we no longer need it
                        m.CancelScheduledEvent(eScheduledCheck);
                        // Start a timer for one last transition
                        m.After(new TimeSpan(hours:24, minutes:0, seconds:0), eBeenHereAWhile);
                        return VerifiedRecently;
                    });

            VerifiedRecently
                    .When(eBeenHereAWhile, (m, s, e) =>
                    {
                        Trace.WriteLine("User has now been a member for over 24 hours - give them additional priviledges for example");
                        // No need to cancel the eBeenHereAWhile event because it wasn't auto-repeating
                        //m.CancelScheduledEvent(eBeenHereAWhile);
                        return VerifiedAWhileAgo;
                    });

            Verified.OnEnter((m, s, e) =>
                {
                    Trace.WriteLine("The user is now fully verified");
                });

            VerifiedAWhileAgo.OnEnter((m, s, e) =>
                {
                    Trace.WriteLine("The user has been verified for over 24 hours");
                });

        }

With your state machine defined you can now create instances of it, trigger events on them, serialize them to disk, fetch them back, carry on eventing on them, …

            DemoStatemachine demoStateMachine = new DemoStatemachine(DemoStatemachine.UnVerified);

            // At the time specified in demoStateMachine.NextTimedEventAt you reload the state machine from disk and call
            demoStateMachine.Tick(DateTime.UtcNow);

            // When the user verifies their email address you call ...
            demoStateMachine.VerifiesEmail();

            // At any other time you can examine the current state, act on the state changed event, ...

I hope you find this new state machine implementation useful, and if you have any feedback, do please send it my way.

Click image to see it all.

The initial integration was easy, I used the new ASP.NET WebApi Core Libraries (from Nuget) together with Newtonsoft Json.Net. GreenGoose’s datetime format is somewhat quirky but hopefully they’ll move to a more standard one soon. They are, however, also about to switch to OAuth so it’s going to require some more work when that happens.

Aside from a few simple WebAPI calls and some Json parsing the rest was just a matter of connecting up the appropriate TimeSeries classes that I use to track values that vary over time, declaring a few graphs, and deciding what to log. With that in place I can now spin up a home automation ‘sensor’ corresponding to any GreenGoose sensor Id and my home automation system will add all of the relevant graphs and charts, triggers and more for that device.

What’s interesting is that a single sensor potentially serves a couple of different purposes. The dog collar sensor for example polls regularly back to the base station so it can potentially be used to sense both how much exercise the dog has had but also simply whether the dog is at home or not which could be really handy for anyone with a dog that’s learned to ignore the invisible fence! Each sensor can, through the TimeSeries objects also offer additional data and triggers that can be used elsewhere in the home, for example, an alert if the dog was walked less than half and hour each day.

What I believe we need is a hub device that connects to the internet and then really cheap wireless sensors that communicate back through it using a connection technology that requires much less power than wifi. So when GreenGoose recently announced their sensors I was one of the first to place a pre-order and this week I received one of their first device shipments. This blog post discusses some of my initial impressions.

First off I have to say I don’t like the egg shape or the color of the hub. Fortunately it’s in the wiring closet next to the router so I don’t need to see it.

The sensors themselves are remarkably small considering they claim a battery life of 1.5 years and the fact that they include both a sensor, some intelligence and a wireless transmitter. Two of the sensors were stick-on devices which I stuck on the dog and cat food containers respectively even though one was labelled food and the other treats. The other two were shaped like dog tags. Here you can see one of the stick-on sensors mounted inside the lid of a dog food container.  You can view a teardown of the GreenGoose sensors and hub on this Flickr page.

Connecting the sensors up to my account took two attempts, three sensors were found on the first try and the remaining sensor on the second try. That’s apparently fairly normal. There were a few configuration problems with my account and the iPad software (actually iPhone software in 2x mode) and the web site is clearly still under development with daily bug fixes and improvements happening each time I try it. But, I have to say the folks at GreenGoose have been incredibly responsive to my every comment or bug report.

So now I’m getting reports from the sensors on their web site and overall things seem to be working quite well. It’s certainly not 100% reliable yet in terms of capturing every event so I don’t think these are going to be the perfect home automation sensor that I’m still waiting and hoping for, but, in all fairness, the folks at GreenGoose aren’t selling these sensors as alarm panel sensors, but as more of a fun game tracking activity and reminding people to go walk the dog. I’ll update this blog when I have a better idea exactly how accurate they are at capturing activity.

The biggest gotcha however is that my original plan to use the sensors on different devices has been somewhat thwarted by the realization that each different sensor type is calibrated to detect a specific kind of motion. You cannot re-purpose them like you would a normal motion or contact sensor. So putting the dog collar sensor on my key chain isn’t producing the results I’d expected. We will have to wait for GreenGoose to come out with sensors to put on doors, cars, shoes, cellphones, iPads and whatever else we want to track. I’ve suggested to GreenGoose that they explain this better on their web site as many hobbyists will try to repurpose the sensors for applications other than the ones for which they were designed.

Another issue at the moment is that the web site forces you to assign the sensors to a specific pet and they only support one pet name. They say they’ll add multiple-pet support soon.

Next I plan to try their API and will report back on how that goes.

Bottom line: this is remarkable technology – a mems accelerometer, some computing power, a radio transmitter and a 1.5 year battery in a package the size of a stick of gum is quite a feat of engineering. Some of the software is a bit ‘immature’ but it’s improving daily. Overall this is a very affordable way to try out some ‘quantified self’ ideas for yourself, it might help you walk the dog more often (our dogs wouldn’t let you forget to do that, but maybe yours would!), and the support from GreenGoose has been great.

To make this easier I decided to add a simple state machine class to the Abodit utilities provided with my NLP Engine. There are, of course, a plethora of existing state machines on the web. Some of them are based on older .NET technology lacking use of generics and functional programming techniques. Others go overboard with fluent-style interfaces when a simple inheritance-based approach from an abstract base class would actually be simpler, less code, and more powerful. Most of them I didn’t discover until after I’d built this one. In any case, it’s always a good learning exercise to try to build something from scratch, so here goes …

First let’s take a look at the result. Here’s how you can define a state machine that derives from this new StateMachine class:

      public class LoginOutStatemachine : StateMachine<LoginOutStatemachine>
    {
        public static void ReportEnter(LoginOutStatemachine m, Event e, State state)
        {
            Console.WriteLine(m.User + " entered state " + state + " via " + e);
        }

        public static void ReportLeave(LoginOutStatemachine m, State state, Event e)
        {
            Console.WriteLine(m.User + " left state " + state + " via " + e);
        }

        public static State Initial = new State("Initial", ReportEnter, ReportLeave);
        public static State LoggedIn = new State("Logged In", ReportEnter, ReportLeave);
        public static State LoggedOut = new State("Logged Out", ReportEnter, ReportLeave);
        public static State Deleted = new State("Deleted", ReportEnter, ReportLeave);

        private static Event eLogsIn = new Event("Logs In");
        private static Event eLogsOut = new Event("Logs Out");
        private static Event eDeletesAccount = new Event("Account Deleted");

        static LoginOutStatemachine()
        {
            Initial
                    .When(eLogsIn, (m, s, e) => { Console.WriteLine("Logging in " + m.User); return LoggedIn; })
                    .When(eDeletesAccount, (m, s, e) => { Console.WriteLine("Deleting account " + m.User); return Deleted; });
            LoggedIn
                    .When(eLogsOut, (m, s, e) => { Console.WriteLine("Logging out " + m.User); return LoggedOut; })
                    .When(eDeletesAccount, (m, s, e) => { Console.WriteLine("Account deleted " + m.User); return Deleted; });
            LoggedOut
                    .When(eLogsIn, (m, s, e) => { Console.WriteLine("Logging in " + m.User); return LoggedIn; })
                    .When(eDeletesAccount, (m, s, e) => { Console.WriteLine("Account deleted " + m.User); return Deleted; });
        }

        public User User { get; private set; }

        public LoginOutStatemachine(State initial, User user)
            : base(initial)
        {
            this.User = user;
        }

        // Expose the events as public methods

        public void LogsIn()
        {
            this.EventHappens(eLogsIn);
        }

        public void LogsOut()
        {
            this.EventHappens(eLogsOut);
        }

        public void DeletesAccount()
        {
            this.EventHappens(eDeletesAccount);
        }
    }

As you can see, you define the states and the events for the state machine using static definitions. (Events trigger state changes and associated actions). Typically I’ll make the States public but the events private and instead provide method calls for each event that is allowed.

Each state can also have an Action that fires on entering the state and an action that fires on leaving the state and each action is provided with all of the parameters it might need (the state machine instance, the state it is going to or from, and the event that caused the transition to happen). In this case all of these entry and exit events are linked to the same method that simply reports what happened.

To define what happens when an given event is received by the state machine you create the static constructor as shown and then, using a fluent interface you define for each initial state, the transition to a new state by calling the When method passing it the event and the action to take when that event happens from the initial state specified. At the end of the method you must return the new state:

Initial
  .When(eLogsIn, (m, s, e) => { Console.WriteLine("Logging in " + m.User); return LoggedIn; })
  .When(eDeletesAccount, (m, s, e) => { Console.WriteLine("Deleting account " + m.User); return Deleted; });

The (m, s, e) parameters give you the state machine itself, the state you are coming from and the event that has been received. By passing your method all of these values I make it easy for you to access any properties of the state machine itself (e.g. a User object) and also allow you to write a single method that handles more than one event type or more than one initial state but which can still be parameterized by those values.

The other minor trick is that the StateMachine class is a generic in the state machine class itself. A small trick that allows access to `T` as the type of the inherited state machine class and thus to any additional properties you define there.

Note how your state machine class can have properties like `User` which allows the transition code to access any additional data it needs. You create an instance of the state machine for each user (all the heavy lifting is done in the static definition so the state machine remains a light-weight object).

In the case of the NLP engine you can pass an `IListener` in to the state machine constructor also so that you can `Say` messages back to the user. Since the state machine is such a light-weight object you can afford to create it for each message interaction with the user and the information you need to persist is just the current state (which I will soon make into a string lookup).

If you want to use the actual state machine in any of your own projects (gratis), here’s the current code:

    /// <summary>
    /// A state machine allows you to track state and to take actions when states change
    /// This state machine provides a fluent interface for defining states and transitions
    /// </summary>
    /// <remarks>
    /// Nasty generic of self so we can refer to the inheriting class in here
    /// </remarks>
    [Serializable]
    [DebuggerDisplay("Current State = {CurrentState.Name}")]
    public abstract class StateMachine<T> where T:StateMachine<T>
    {
        public State CurrentState { get; set; }

        public StateMachine(State initial)
        {
            this.CurrentState = initial;
        }

        /// <summary>
        /// An event has happened, transition to next state
        /// </summary>
        public void EventHappens(Event @event)
        {
            this.CurrentState = this.CurrentState.OnEvent((T)this, @event);
        }

        /// <summary>
        /// An event that causes the state machine to transition to a new state
        /// </summary>
        /// <remarks>
        /// Defined as a nested class so that this state machine's events can only be used with it
        /// </remarks>
        [DebuggerDisplay("Event = {Name}")]
        public class Event
        {
            public string Name { get; private set; }
            public Event(string name)
            {
                this.Name = name;
            }
            public override string ToString()
            {
                return "~" + this.Name + "~";
            }
        }

        /// <summary>
        /// A state that the state machine can be in
        /// </summary>
        /// <remarks>
        /// Defined as a nested class so that this state machine's states can only be used with it
        /// </remarks>
        [DebuggerDisplay("State = {Name}")]
        public class State
        {
            /// <summary>
            /// The Name of this state
            /// </summary>
            public string Name { get; private set; }

            public Action<T, State, Event> ExitAction { get; private set; }
            public Action<T, Event, State> EntryAction { get; private set; }

            private readonly IDictionary<Event, Func<T, State, Event, State>> transitions = new Dictionary<Event, Func<T, State, Event, State>>();

            /// <summary>
            /// Create a new State with a name and an optional entry and exit action
            /// </summary>
            public State(string name, Action<T, Event, State> entryAction = null, Action<T, State, Event> exitAction = null)
            {
                this.Name = name;
                this.EntryAction = entryAction;
                this.ExitAction = exitAction;
            }

            public State When(Event @event, Func<T, State, Event, State> action)
            {
                transitions.Add(@event, action);
                return this;
            }

            public State OnEvent(T parent, Event @event)
            {
                Func<T, State, Event, State> transition = null;
                if (transitions.TryGetValue(@event, out transition))
                {
                    State newState = transition(parent, this, @event);
                    if (newState != this)
                    {
                        // Entry and exit actions only fire when CHANGING state
                        if (this.ExitAction != null) this.ExitAction(parent, this, @event);
                        if (newState.EntryAction != null) newState.EntryAction(parent, @event, newState);
                    }
                    return newState;
                }
                else
                    return this;        // did not change state
            }

            public override string ToString()
            {
                return "*" + this.Name + "*";
            }
        }
    }
}

For further reading on State Machines I recommend this Wikipedia Article.

Whilst my natural language engine can’t understand every possible date time expression (e.g. the second Wednesday after the first Friday in May 2010) it does handle a huge variety.

Clearly the .NET provided DateTime class is wholly inadequate to express the kinds of date/time expressions your users might enter. To deal with that I’ve created my own classes that represent items like a specific Time of day, a DateTimeRange, a DateTimeRangeCollection, …

TemporalSets are the most general result of parsing a datetime expression since they can represent any date time expression. Broadly they split into two categories: finite and infinite expressions. “Tuesday at 5pm” is an infinite time expression. “Tuesday at 5pm January 2012″ is a finite time expression. Sometimes you will want to accept an infinite expression and interpret it as a future or past finite occurrence. For that I have a MergePreferPast and MergePreferFuture method that operate on a TemporalSetCollection. The demonstration code on BitBucket shows this in action.

TemporalSets also have unique capabilities around both providing query expressions (for database searches) and generative expressions (for adding dates to a calendar).

If you’d like to try out the latest date / time expression parsing code in my Natural Language Engine you can visit the demo and try typing “define” followed by a date / time expression.

If you find any expressions that ought to work, please feel free to email or Tweet them to me.

Here’s a sample session:

define june 23rd 2010
Absolute:[DATETIMERANGE 6/23/2010 at 12:00 AM to 6/23/2010 at 11:59 PM]

define January 19th
Future:[Thursday 1/19/2012], [Saturday 1/19/2013], [Sunday 1/19/2014], [Monday 1/19/2015], [Tuesday 1/19/2016], [Thursday 1/19/2017], [Friday 1/19/2018], [Saturday 1/19/2019], [Sunday 1/19/2020], [Tuesday 1/19/2021]
Past: [Wednesday 1/19/2011] ...

By building a simple in-memory graph of all these relationships my engine can now use them to infer interface types on objects. To define an interface corresponding to a Wordnet synset like a mammal (wn30:synset-mammal-noun-1) you simply define an interface in the namespace ‘Noun’ having a name of ‘mammal1′. Through the type inheritance specified in the Wordnet file all mammals now inherit that interface automatically and you can write natural language rules that ask for a mammal and they will get any type of mammal defined in Wordnet.

For example:

db.customers.find( { name : { $regex : '^acme', $options: 'i' } } );

But what if you want to do the inverse of this? i.e. to search the database for the keys that are themselves substrings of the search string? For example, suppose you are trying to parse a block of text and you want to find phrases in the database that match the start of the current block of text. In SQL you would be dead in the water but with MongoDB you can create a RegEx that matches either the first word, or the first two words, or the first three words, … and so on.

We can construct a regular expression to do this, it might look something like: ^word1($| word2($| word3$))

Here’s a C# method that can create the necessary regular expression:

        /// <summary>
        /// This generates a regular expression that matches as much of the given phrase as it can from a string
        /// i.e. a reverse prefix search where you want the database to supply the prefix and match it against your query
        /// useful for matching 'as much as possible from a given input'
        /// </summary>
        private string generatePrefixRegex(string phrase, bool atStart)
        {
            string[] bits = phrase.Split(' ');
            string result = bits[0];

            // At the start of a sentence, if the first character is upper cased, we should also be looking for a lowercased verson of it
            if (atStart && char.IsUpper(result[0]))
            {
                result = string.Format("(%0|%1)%2", char.ToLowerInvariant(result[0]), char.ToUpperInvariant(result[0]), result.Substring(1));
            }

            // Each additional word - either we end the string before it or we must include it

            foreach (var bit in bits.Skip(1))
            {
                result = result + "($| " + Regex.Escape(bit);
            }

            result = result + "$";                      // last word must end string

            foreach (var bit in bits.Skip(1))
            {
                result = result + ")";                 // close the expression
            }
            return "^" + result;                        // Must start at the start of a Name
        }

Most traffic reports (on the radio or in text message alerts) are fairly useless. Like weather reports they contain lots of irrelevant information that could be eliminated with just a bit of extra context. In fact, most of the information they deliver is completely irrelevant to you as an individual located in one spot and hoping to get to another spot. Furthermore they aren’t actionable – telling me the traffic is slow on SR-520 and on I-90 isn’t interesting unless you can tell me which is the best way to go given where I am now and where I want to be.

So this weekend I added a new feature to the home automation that uses the WSDOT’s excellent traffic feed API to calculate a traffic report just for me. Recently I’ve started driving from the north end of Bellevue to the south end of Sammamish during rush hour. There are two very different paths I can take: SR-520 or I-405 to I-90. If either route has a problem I should take the other. So now I get an XMPP (chat) message from 4PM to 6PM whenever the optimal path changes from one route to the other. It’s the absolute minimum information I need and it’s 100% actionable.

For the moment the calculation is fairly simple, I simply maintain a list of the FlowDataID values along each route and then calculate a total ‘slowness’ factor based on the sum of those segments. If one way is much better than the other it generates an alert. If it goes back to being roughly equal the alert is cleared.

Since the calculation is purely relative (route A vs route B) it’s also fairly immune to day-of-week / school-holidays and other factors that have a significant impact on traffic but no impact on the only actionable decision I need to consider.

One other interesting point from the graph is just how spiked the traffic is on SR-520 compared to I-90.