ver0776
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...
Vaughn
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...
Vaughn