The bulk of this week's work is on designing and coding up the ECA control panel. This is where the user sets the behavior of the house programatically.

The server checks through a list of given events when a sensor unit within an item returns a state change. If any of the events match the state change, the server checks the associated firing conditions for the list of actions associated with that sensor event, and fires them if all of them are matched. That's the server side of things, while my job is to let the user specify that behavior within an intuitive UI.

The ECA stage

There are a couple of design challenges, in both visual and programming perspectives. Firstly there is a lot of information to be displayed, much more than the room and item control pages. Then the user needs to modify individual parts of the ECA object, so there are multiple forms and displays that need to be attached to each object.

3rd March scrshot01

Weekly screenshot update - ECA stage when shown

My approach to dealing with information overload is to display only the bare essentials of an event during stage load. It only lets shows users the name of the ECA which he/she had given so it should be obvious which event is which, and the only functionality exposed is adding/deleting the whole ECA object, enabling/disabling that particular event, and editing the name of the object. On the JavaScript side, the display is handled by the RuleDisplay and RuleManager classes.

Uncollapsing an event of interest reveals the actual triggering events, the conditions to check for, and the actions to execute. These are handled by EventDisplay, EventManager, ConditionDisplay, ConditionManager, and ActionDisplay, and ActionManager classes. Since the user must be able to add events, conditions, and actions as well, there are three additional classes NewEventDisplay, NewConditionDisplay, and NewActionDisplay that handles these parts of the UI.

This brings the total classes responsible for this stage to 11, more than any other. In contrast with the room/item control stages, that one only involves about 3-4 classes.

3rd March scrshot02

ECA expanded display

Each individual box within the display associated with each event, condition, action has two display modes, one which just shows the information, and the second which exposes the editing forms. The edit and cancel buttons toggle between these two modes. And that's most of the essentials about this stage.

3rd March scrshot03

ECA exposed forms

As it stands as I write this blog, I've completed the functionalities to add/delete conditions and actions. If all goes well, these server commands should be finished within a day or two. Next up would be updating the ECA stage with polling, just like the room/item control one.

Control stage

Lastly, I think I managed to fix the updating behavior for the room/item control stage when going through the week-old code, but since I don't have a way to test this I've left it as it is for now. Previously deleting a room (or an item) removes it via a method call triggered by the delete button press, so it only updates the UI for that one client.

I've kept this in mind during the design of the ECA stage so this should not be a problem.

And that's it for this week.