I've just started using HouseBot and find it very flexible and intriguing (my previous home control system was a small nest of perl scripts which migrated from unix to windows). I've not explored all of housebot yet, and my current setup is not too fancy, but I am looking forward to integrating my one-wire network of temperature sensors
Feature-wise, housebot is great for me, but I'm wondering if there might be any plans to change the fundamental design such that the event/task processing could run as a stand-alone windows service ? Thus the management UI would be a separate program run by allowed user accounts that communicates with the service engine. Yes, I'm a Windows 2k/XP user and not Win9X, and I'll be the first to admin I'm not sure if such a split design is easily supported for all windows OSs. However, managing a true service on a windows server (including embedded XP) seems much easier to maintain/monitor/restart after crash, power reboot, or automatic OS patch application, therefore the overall home control system would tend to be more robust (?)
My original design was similar to your suggestion in that the configuration UI was a separate executable from the 'runtime' engine. Since all of the configuration data is stored in a database file, it provided good functional separation between the two components.
However, when it came to implementation, it was easier to build it all together. The advantage of this was to not have to figure out how to notify the runtime engine and have it re-query the DB every time a configuration item was changed (it's much easer to just send the configuration changes to the DB and update the objects that are loaded).
I still like that design over what I currently have, and may get to reworking it at some point. My formula for prioritizing features is pretty much the classic (value/keystroke=priority), and I currently have a number of larger features that I still want to implement.
Thanks for the suggestion, I'll add it to the list.
