US Home

(Last updated: Thursday, November 28, 2019)

DollHouse (dh)

I've been thinking about HA since 1978 when BSR X10 first arrived at Radio Shack. Lately I've been thinking about how I would rewrite older smart home software to take advantage of different new programming technologies and the IoT. Well other folks have done that. I started down this road a few years ago with my initial DollHouse program. It was still Perl and based on a trimmed down Misterhouse. While it worked well I still wanted to get away from the central poll loop that makes up Misterhouse. So with my work with Node.js I think I can finally be rid of the that loop and work with a more object oriented language (Javascript). So I'm rechristening this effort DollHouse 2.0.

What is DollHouse?

DollHouse (dh) is my attempt at a modern flexible HA controller for the DIYer. It is not meant to be a ready commercial competitor to the existing HA software and services. It's meant specifically for the DIYer who want to play a bit. There will be plenty of rough edges that can be worked on later but DH's primary purpose in life is to provide the glue between different HA protocols, devices, data and presentation.

Why DollHouse?

DollHouse is influenced by Misterhouse and the HCS II. Despite it's age, use of Perl and core design, Misterhouse works rather well. One of the problems I have with the HCS II is that it isn't part of the IoT. Considering that it's almost 21 years old, it has held up rather well. As far as Misterhouse is concerned it's web interface is rather tightly bound to the running code. Additionally everything exists in a polled loop. If my design around node.js turns out to be a disappointment then I can always fall back to Misterhouse.

DollHouse will be based on asyschronouse programming using node.js. While this style of programming is a bit odd to me it's not totally foreign. I am used to working with interrupt routines in the embedded controller world, with signals and the select function in Unix network programming and events in GUIs. This is taking it one step further and many things are events even the user programming language. I think home automation lends itself well to asynchronous programming as real life tends to be very unpredictable.

My initial programs, such as the irnode, node-ecm, node-hcsii and node-elkm1 had many things in common. Primarily networking, serial methods of communication and a web interface. If I minimized the web interface to the basics of configuration and debugging and move the user logic to a central control point (DollHouse) I could monitor and control these devices at one central point.


No dependency on the Internet to run. This is one of my pet peeves! I don't want to have to depend on a service that might or might not be there in the future.

I haven't quite figured out all the details at the moment. I know I want a user language (like the HCS II XPRESS), a web interface, data stored in a db to make it easy for devices, web pages and cloud services to share the information. User control of the information.

Many of the requirements will be discovered when I finish building the other devices (irrnode, node-hscii, etc.). These devices are currently defining the framework of the central HA controller.

  • Be flexible enough to monitor and control disparate devices such as Insteon, X10, ZigBee and Z-Wave devices
  • Be able to access data and programs outside the running program
  • Network accessible
    • IPv4
    • IPv6
  • Web interface for monitoring and configuration
    • User extensible web pages
  • Object oriented for the developers
  • Have a user language
    • XPRESS like (actually it will be Javascript but need to figure out how to keep it a bit secure)
    • Handle basic math
    • Be very good at dealing with strings (regex)
    • attempt to keep the user from doing dangerous things
    • Be dynamic, I don't want to reload
  • Shared data (db?)
  • Not require rebooting or restarting to add new devices and services
  • Secure - this will not be easy. As programmers we've not been very good at making things secure. This will take some thought
  • Private - again, not easy. The user should have the ability to control what information is shared and to what extent.
  • Access to cloud services. I don't know what yet but I'm sure they will develop.
  • Easy, intuitive, mobile access (not hierarchical menus). This is a given and probably where most of the could services will fall into play
  • var devObj = {
        "ready" : 0,
        "debug" : 2,
        "set" : "A1AOn",
        "get" : "A1AOn",