HouseBot

We have a number of X10 devices in our house in Rolling Hills Estates, CA including SmartLinc 2384 Dimmer Switches and PCS SMST8 and SMST6 Controllers as well as 511 Flood Lights, etc. and what we want to do is to be able to create a model of the house for potential computer control using these specific devices including visual representations.



Your software sounds promising and we downloaded and installed it but haven't got a clue what you are trying to do with it. ActiveHome by contrast operates on the principle of:



1) Establishing Rooms

2) Adding Objects which represent actual X10 devices

3) Setting the actual X10 assignments on the software devices

4) Then attempting to play with control of the devices



Your model in your HouseBot software does not even include the most basic of X10 devices and confuses the functions of X10 by calling them 1) Controllers (which are transmitters), 2) Lamp Modules (which are RECEIVERS), and 3) Transmitters. Some X10 switches such as the SmartLinc 2380 are bi-directional controllers. Thus the correct 3 classifications for X10 switches would be:



1) Receivers (simple switches)

2) Transmitters (unidirectional transmitters such as PCS SMST6 and SMST8 devices)

3) BiDirectional Controllers (such as SmartLinc 2380)



Attempting to control devices without any context such as what room they are in makes no sense. Attempting to first define as you suggest some computer devices such as a CM11A makes little sense - who cares what devices will interface with the a computer? That just a simple check box AFTER the individual devices are created and assigned and placed within rooms.



I tried to use your Themes which should be called a Control Screen Designer and made little progress with it. I first tried to create a "Home Controls" Screen into which I tried to create buttoms that were named by rooms and then have it go to subscreens for each of the rooms but couldn't get it to do that. I then created a second Theme screen called "Garage" and attempted to import a photo of a PCS SMST8 Switch and then place control buttons next to it to describe what the real buttons do, but could get any properties assigned to the buttons that made any sense.



Your website shows devices with descriptions, but the software actually has no devices defined and it is not at all apparent how to define the real switches that would be used in a house and then represent them in the software. This needs to be enabled at the various levels of switches which at the base level are all receivers and at the higher level are transmitters (or bidirectional controllers) that send signals to the receivers such as G1 for Garage Main Lights.



What would be truly useful is a device library of known X10 devices (there really aren't that many) by specific model number with specific properties like X10 did with ActiveHome and each should have a visual representation of that device so that it looks like the real thing. Then one could simply drag and drop these objects into the appropriate rooms and have the data on the device stored in a database listing all of the electrical objects in the house which are controllable.



For instance, we have a spreadsheet which lists all 116 actual devices and what they do. I don't see how to do that with your software model. When I define a Device in your model I haven't got a clue what I'm supposed to put in the way of Description or Values or why it even matters or what it does. There should be a way to put a photo (.jpg preferrably as .BMP is utterly obsolete and always has been) of the device with each device so it resembles the real world.



One of the advantages of the CM11A is that it doesn't need to be connected to a computer to control the system - it just needs to be programmed by a piece of software such as HouseBot to feed it control sequences which it will then execute. At the moment we want the system to operate entirely without any PC control as we want complete useful distributed but granular functioning of lighting when one walks into a room by using PCS controllers that have 6 or 8 buttons instead of a single light switch for the ceiling.



Ultimately it would be amusing to have a flat-panel wall mounted color touch LCD screen with an embedded PC behind it in the wall to allow setting of all of the devices and timing sequences to be be executed. But for this to make any sense it needs to be represented based on the rooms and actual devices in the house, and absolutely not in a technical directory structure tree filled with abstract comuterese about which no normal person operating the system would care at all.



The more that I've researched attempting to remote control things like audio and video the less sense any of that makes from a real world perspective. You're pretty much going to be using the TV/VCR/DVD in the room where you're at so what possible purpose does extending any remote control have? The same is true of audio, especially in today's world where HiFi systems aren't built for the purpose of distributing stereo sound like musak throughout the house but are increasingly complicated Dolby 7.1 systems with piles of duplicate speakers being driven in a single room which is an exercise in utter stupidity. What we do is use a single Sony receiver to drive speakers in a bedroom and living room and dining room and patio and garage to distribute the music like musak throughout the house. So what value is achieved by somehow duplicating and extending remote control of video or audio? What's the purpose and point?



Lighting controls do make sense, but the difficulty of getting computer control over them in a way that would make sense and offer value in a central cute color control screen seems to be a holy grail that's pretty far away...



Best Regards,



Jim

Jim,



Thanks for all the feedback. I'll try and address your issues individually, but it seems that your main issue is with the usability of the application. I agree 100% that the user interface and the application user model needs a fair amount of work to bring it in line with other commercial products. My plan is to get version 1.x stable and feature sufficient first. Then to work on a better user interface for version 2.0.



A short history of HouseBot and how it came to be may also provide a perspective that may help you to understand why it is like it is. I wrote HouseBot solely for my own use because I couldn't find a cheap, expandable, automation controller with a good skinnable remote control solution. As with all designs, I had to decide where the 'usability tolerance line' would be. This line is the point between flexibility and ease of use. At the extreme flexibility end you would make it 100% scriptable and therefore require the user to write the entire thing (very flexible, but a huge learning curve). At the other end you provide one big button that says "do it" and it does IT (very easy to use, but can only do one thing). Since I was writing it for myself, the line was further to the side of flexibility than most applications. What I ended up with was a very flexible and extensible application that can be used to control about any equipment that can be connected to the PC (home automation or not).



Friends of mine suggested that I share it with them and then with the rest of the world. This, unfortunately, resulted in a geeky DIY'er type application with a fairly significant learning curve. I've been adding things since the initial release to make it more usable, but I still have some ways to go. Due to the steep learning curve, the on-line help is almost a necessity for starting out.



So, to address your issues:

Your model in your HouseBot software does not even include the most basic of X10 devices and confuses the functions of X10 by calling them 1) Controllers (which are transmitters), 2) Lamp Modules (which are RECEIVERS), and 3) Transmitters. Some X10 switches such as the SmartLinc 2380 are bi-directional controllers. Thus the correct 3 classifications for X10 switches would be:

1) Receivers (simple switches)
2) Transmitters (unidirectional transmitters such as PCS SMST6 and SMST8 devices)
3) BiDirectional Controllers (such as SmartLinc 2380)

Don't get too caught up in my terminology. In HouseBot, any X10 Receiver can be created with the "X10 Appliance Module" or the "X10 Lamp Module". The only difference between the two is that the Lamp Module includes dimming Properties. In HouseBot, the Receivers are actually 2-way (commands can be sent AND received in HB). The Transmitter Device is pretty much the same as your definition. The Controller is a special Device that does not actually map to any specific X10 device in the home. It simply provides a quick and easy way to send an X10 command to ANY X10 device and/or monitor all X10 activity.

Attempting to control devices without any context such as what room they are in makes no sense. Attempting to first define as you suggest some computer devices such as a CM11A makes little sense - who cares what devices will interface with the a computer? That just a simple check box AFTER the individual devices are created and assigned and placed within rooms.

If you want to create logical groupings of Devices based on the rooms of a house, you can use Device Groups.

I tried to use your Themes which should be called a Control Screen Designer and made little progress with it. I first tried to create a "Home Controls" Screen into which I tried to create buttoms that were named by rooms and then have it go to subscreens for each of the rooms but couldn't get it to do that. I then created a second Theme screen called "Garage" and attempted to import a photo of a PCS SMST8 Switch and then place control buttons next to it to describe what the real buttons do, but could get any properties assigned to the buttons that made any sense.

"Theme" may not be the very best term for this, I agree. I'm not clear on exactly why you could not assign the buttons to Devices and Properties. You might want to download the two Theme samples from the web site to get a general understanding of what you can do with Themes.

Your website shows devices with descriptions, but the software actually has no devices defined and it is not at all apparent how to define the real switches that would be used in a house and then represent them in the software. This needs to be enabled at the various levels of switches which at the base level are all receivers and at the higher level are transmitters (or bidirectional controllers) that send signals to the receivers such as G1 for Garage Main Lights.

The system comes pre-configured with only a single "System Time" Device. Since each installation is unique, each user will have to setup their own Devices. For example, to control an X10 light switch (A1), simply create a new "X10 Lamp Module", name it something that helps you to identify the switch "like Hall Light", associate it to the X10 hardware interface in the PC, enable the Device, and you can then control the switch by setting the "Power State" Property to On or Off.

What would be truly useful is a device library of known X10 devices (there really aren't that many) by specific model number with specific properties like X10 did with ActiveHome and each should have a visual representation of that device so that it looks like the real thing. Then one could simply drag and drop these objects into the appropriate rooms and have the data on the device stored in a database listing all of the electrical objects in the house which are controllable.

I went with the simple approach of having just a few X10 Device types that can be used for any type of X10 device (since all of the equipment uses the same small set of X10 commands). I agree that it would be better to list each and every Device separately.

When I define a Device in your model I haven't got a clue what I'm supposed to put in the way of Description or Values or why it even matters or what it does. There should be a way to put a photo (.jpg preferrably as .BMP is utterly obsolete and always has been) of the device with each device so it resembles the real world.

The Description should be something that you can use to identify the equipment. If its the outside motion detector, call it "Outside Motion Detector". This same description is then used throughout the system to select the device. Generally, the Property Values are pre-set by the system. Valid values are usually presented in the user-interface when they need to be entered. I don't have a great answer for the bitmap support other than that is the format that the Windows API supports natively. It would be really nice to support jpeg and other formats. I have that on the list for a future enhancement.

One of the advantages of the CM11A is that it doesn't need to be connected to a computer to control the system - it just needs to be programmed by a piece of software such as HouseBot to feed it control sequences which it will then execute. At the moment we want the system to operate entirely without any PC control as we want complete useful distributed but granular functioning of lighting when one walks into a room by using PCS controllers that have 6 or 8 buttons instead of a single light switch for the ceiling.

You may be able to use other software to program the CM11A while still attached to HouseBot (I've never tried this). For HouseBot to work effectively as an automation controller that integrates multiple control interfaces it really needs to know what is happening so it can respond accordingly. I'm sure there are many situations where it would be fine to have the CM11A (or Ocelot) running all on its own, but then you have multiple applications/systems in the mix.

Ultimately it would be amusing to have a flat-panel wall mounted color touch LCD screen with an embedded PC behind it in the wall to allow setting of all of the devices and timing sequences to be be executed. But for this to make any sense it needs to be represented based on the rooms and actual devices in the house, and absolutely not in a technical directory structure tree filled with abstract comuterese about which no normal person operating the system would care at all.

The general idea is that the HouseBot server be flexible in configuration even to the sacrifice of usability. However, the Software remotes should allow customization to provide the perfect usability for the user and situation. It is the intention to have one or more touch panel remotes that all connect to the single server. Each has its own user interface for its location and function. The user interfaces are 100% skinnable allowing you to diagram a floor plan or make it functionally specific for a particular task.



Hope this helps,

Scott