AHAA Design question/help


Active Member
Device addressing was simple until Insteon. A device had an address and when anything was sent or received from that address, you could update the status of that device.

Insteon switches can have an Insteon address and an X10 address and sometimes it will receive commands from either. So I have added a secondary address field so a device can have both addresses and will update off of either. So far so good.

Question 1: Since I don't use HS, or any other commercial HA software, I am wondering if they are capable of maintaining status updates on Insteon devices despite the mixing of X10 and Insteon commands? Do they all translate to something like "Kitchen Light OFF" despite which code was used so it is transparent to the event system?

Now for wrapped devices like my Phidget sensors, I am tieing them directly to my event system, and tieing those events to virtual X10 devices (so on screen, like my bathroom M3, it looks like an X10 device, but really has no X10 address)

I have seen a HS screenshot where they use virtual address like *M so it does not tie up real X10 addresses for non-X10 devices.

Question 2: Should these virtual codes have their own address space like the Insteon addresses do, or should I just stick them in the X10 code field?

One Design layout looked like:
Device Type, Device Address, etc...

Now it looks like:
Device Type, X10_Code, Insteon_Address, Virtual_Address, Zigbee_Address, etc

That way a device could have 2, 3 or however many addresses that would be used in a preferred order, but I much preffered the simplicity of "here is the device type and here is the address."

With the first design option, plugins for new devices would not require a code release and database changes... But the second is more robust...

ARGH, sometime my brain hurts. I hate to spend 3 days on database layout changes then change my mind so was wondering if anyone has any feedback in this area...

If not, that's ok, I just love talking to you all and like babbling in posts... I can't wait to get my public liscense so I can just share everything and post database diagrams, etc...

I am not a programmer so I don't know if I understand the issues you are trying to resolve. As a user though I have to say that things should be simpler with insteon, not harder. With Insteon you have a truly unique address for each device where X-10 allows multiple devices to have he same address.

If your have a Lamp and an overhead light both set to X-10 address A1 than what do you put in your database for device A1? When you poll A1 and get an ON status does it refer to the lamp or the ceiling light? With Insteon you have a true 1-to-1 correlation between devices and addresses.

I would treat X-10 addresses more like scenes than a device addresses since they can be assigned to multiple switches and modules.

If you have a Living Room lamp controlled by an X-10 module A1 then logically you have non-addressable device that responds to scene A1 commands. So to control it you create a scene called Living Room Lamp that transmits A1 commandas and you control the scene (not the device). You can have as many X-10 or Insteon devices as you want with the A1 "scene address" and it won't mess up your schema.

Pure X-10 devices would have a device address of 00.00.00 (to indicate they are not uniquely addressable. There should be an X-10 address field to indicate it reponds to A1 scene commands but programmatically it is treated like any other scene for tracking device state.

Of course this assumes your primary key is the device object name and not any kind of Insteon or X-10 address since you can have multiple modules with the same X-10 address, or no X-10 address, or no Insteon address. In other words you have to get rid of the model that Homeseer follows in trying to assign every object an X-10 like address as a primary identifier.

Does this make any sense at all or am I way off base?
It makes a lot of sense. I guess my problem with Insteon is the use of remotes, etc. I have to use X10 remotes because there is no such thing as an Insteon remote. So from the software I control 00.0C.BB, but from a remote it is C2. That C2 is unique and has no sharing issues. So whether I use C2 or 00.0C.BB, the bathroom light has to respond and my software has to keep track of the device's status.

The real confusion is Plugin Devices that don't have an address at all. I guess I am leaning towards a Virtual Device Address/Label and keep it seperate from X10 addresses. I think it will leave me having to put out code updates when new technologies like UPB are added, but as long as it works well, I can live with code updates.

I may just plan ahead and make address colums for UPB, Z-wave and the such even though I don't currently support them and then once I do, everyone's client would be ready for them....

Anyways thanks for the big post, I will re-read it again tonight beofre I do my table re-designs.

I guess what I was getting at, in a round about way, was that you don't need virtual addresses if you don't use the address as the primary identifier for the device. Why not make the device name the primary identifier and the address is just an attribute defined by device class? So your table becomes:

DEVICENAME (which must be completely unique as it is the primary identifier)

DEVICECLASS which determines what attributes can be assigned to the device. New classes can be created as needed for new technologies or new plugins. Plugin author can define a DEVICENAME and associated schema within a plugin.

ATTRIBUTES which are defined by the DEVICECLASS schema. The Insteon DEVICECLASS would include both an Insteon address that must be unique but is still just an attribute, as well as an X-10 address which does not have to be unique and could be blank, etc.

The point being if I have a device called Hall Light, then that is the only identification for the object. It is not the "label" for device $9 or some such, it IS the device. If there needs to be an attribute that needs to be assigned to it such as $9 or A1 or 0C.14.88, or whatever then that requirement will be defined in the DEVICECLASS.

Just trying see if you can get away without the virtual address type identifier.
Making the device name the unique key is very logical. My template system was unique and it made a lot of sense to me to configure the devices around the signals I see the devices send or receive. I linked the device's address and the command to a template record and then associated that to an event record then a trigger record. The name was never used.

I did this because I did not have to worry about entering addresses into an event or trigger, also did not matter what features the device supported, if I saw it, I could link it in... I just went to the template screen clicked on the devices and command and then selected and Event to go with it.

This is flawed because whenever a virtual device creates an event, there is no template! I think I can fix it and center it around the Device Name like you are suggesting. It will piss the girlfriend off cuz now I have another rush code job that is going to eat up another Friday night ;-)

I have to do some work work now but I will work on it tonight. I will put a screenshot of the database diagram for this part up too. Explaining it all in english is hard and I have admittedly poor communication skills =)

That is excellent info though, thanks for helping.