Note: These are just some notes I made when I was first releasing JavaHomeControl into the wild. Because of the extremely organic nature of it's development, I got it to a usable state and then started (kinda) over, actually modelling the Domain first, thus begat OOHome.
In the beginning, there was a new/old player in the home-automation scene: SmartHome. Since I was pretty well disgusted with the lack of "smarts" in X10, it was a pretty easy bet I'd be getting one of their own home control system (InsteonTM) starter kits. It pretty much hooked me instantly, for it's ease of use, capabilities, and the fact that it worked with my crappy, noisy, spiky, co-op-furnished electricity. As with any gadget-addict, that was the hook that bought the SDK (such as it is).
So, the first part was to "talk" to the dang thing. This begat the RawUI.java program. This served as the testbed/springboard into the more complex low-level port communication now in place (AbstractTransceiver and implementations thereof). From there, based on the SDK documentation, each layer of communications abstraction was applied, with the aim of providing a fairly simple API and "hiding" a lot of the house-cleaning and byte-manipulations. And take my word, the InsteonTM layers are quite a lot more sophisticated than X10 had. Needless to say, the layering and abstraction weren't there in the beginnings - there's been a lot of refactoring and tweaking to get it into it's present form.
I do apologize for the over-use of the "Manager" class name. I seem to be at a loss for a better, more descriptive name.
Eventually, the UI and "device manager" interface progressed to a point where they could be split, leaving the "dm" available as a separate library. There actually was a reason behind this: what if I (or someone else) wanted to give up this whole fat-application notion and go with a web-interface?
While that was going on, there was also a "requirement" that I wanted to be able to tell what the system was doing and send basic commands from any other computer on the local network. This involved layering in a communications system (see above). Because of this, as well as the persistence of the system objects (e.g. rooms), this caused a disconnect between the domain object implemenations. Thus, there is a bit of translation between persisted objects and network objects. I don't like having to "repeat myself," but currently there is naught for it.
The other item that is still a far-distant target is to completely separate the fully functional UI from the server portion, thus allowing the server to be run anywhere in a "true" server mode (headless and in the background). However, currently some of the operations are too complex to attempt over an asynchronous network connection (such as setting up links). It's not a very high priority, since those particular operations aren't common once the system is up and engaged. Plus, the PLC is connected to my primary workstation (so I can keep working on this project).
|