X10 direct interface

[brobin]

I suspect that many others including myself use their ISY as a translator so that legacy X10 controllers can be used to operate Insteon responders. Currently, the PLM receives the X10 transmission from the powerline, passes it to the ISY where it triggers the ISY to send an Insteon transmission to the PLM over the powerline.

 

The problem with this method is that it takes a lot of time and, when a string of X10 commands are sent such as in a macro, there can be conflicts with less than perfect results.

 

So, to solve that issue, how about adding a direct X10 input to the ISY, perhaps through the extra serial port or in a new model with a dedicated X10 input port? My thought is that the cable that currently runs from my Stargate to the TW-523 would instead plug directly into the ISY. In this scenario the ISY gets the X10 signals directly isolating them from the powerline so there is no issue of powerline anomolies or signal conflicts.

 

Because the ISY/PLM can send either Insteon or X10 all signals for both protocols can be sent as programmed in an orderly fashion without conflict.

 

X10 signals generated by motion detectors, mini/maxi controllers or wireless remotes would still be handled as they are today being received through the PLM.

 

I would happily pay to upgrade my ISY for this capability even if it means buying a new unit.

[MikeB]

I'm not sure I follow, but maybe that's because I don't really know what a Stargate is.

 

Are you suggesting that the ISY communicate directly with a TW-523? If so, isn't the TW-523 an X10 powerline interface? If so, doesn't that mean X10 signals would still go through the powerline, to the TW-523, then to the ISY? And the only difference would be that the TW-523 is being used instead of the PLM to receive X10 signals?

 

I could be completely misunderstanding, so please let me know.

 

I'd be a fan of an ISY that interfaced with an X10 RF receiver, like the W800, to avoid X10 RF devices from broadcasting on my powerline.

[Brian H]

TW-523 is not serial in fact it is a real dumb device. All it does is give you a optoisolated Zero Crossing Signal and a optoisolated receive signal. Just 1s and 0s. Your equipmant has to do all the decoding including timing.

On transmiting an X10 signal you again have to do all the timing and encoding to a current input to another optoisolator thet keys the X10 transmitter on. Most likely not to easy to do with an ISY-26 or ISY-99

 

Have you looked at the Simplehomenet. EZX10RF? Sends Insteon signals to linked devices from X10 RF signals.

[upstatemike]

Mike-

 

The Stargate is the single most comprehensive home automation hardware controller ever created (although the HomeVision Pro often contests that title and is also an awesome product). Think of an ISY 99 with multiple serial ports and provision for generic asccii communication, tons of built-in opto isolated inputs, analog inputs, relay outputs, an RS-485 port for thermostats, LCD keypads, LED annunciators, built-in voice response, speaker and telephone and line level audio switching, and much more.

 

You can practically control the world from within the simple point and click interface of a Stargate. Unfortunately the Stargate is not being updated very aggressively to keep pace with new technologies but there is also no new product that comes close to serving as a potential replacement anywhere on the horizon. This is why stargate users are looking for ways to extend the life of their controllers with technology adapters and translators.

 

What Brobin is suggesting is that there would be a market for an ISY interface that emulates a TW523 (aka PSC05). This interface could be part of a future ISY model OR could be a separate device that communicates with existing ISY models over the network similiar to the way an ELK M1 communicates with ISY models today.

 

This would be useful not only for stargate users but also for any alarm panel or HA controller that uses a TW523 interface to transmit and receive X10 signals. So the potential market for such an application is very broad.

 

As far as existing options; translation of X10 powerline signals, EZX10RF for RF translation, etc etc... I have tried them all. I currently use regular X10 translation for activating Insteon devices from my Stargate with great success but some applications just won't work that way. I am still forced to keep local X10 addresses in certain interior switches so they can react to X10 commands triggered by my Stargate motion sensors. Translation was just too slow for interior motion lighting so I have to continue to depend on direct X10 communication. A TW523 emulator would solve this and let me get away from having X10 signals on the powerline once and for all.

 

I'm not sure I follow, but maybe that's because I don't really know what a Stargate is.

 

Are you suggesting that the ISY communicate directly with a TW-523? If so, isn't the TW-523 an X10 powerline interface? If so, doesn't that mean X10 signals would still go through the powerline, to the TW-523, then to the ISY? And the only difference would be that the TW-523 is being used instead of the PLM to receive X10 signals?

 

I could be completely misunderstanding, so please let me know.

 

I'd be a fan of an ISY that interfaced with an X10 RF receiver, like the W800, to avoid X10 RF devices from broadcasting on my powerline.

[Michel Kohanim]

upstatemike,

 

We would be amenable to any integration with almost any product. Our main issue is lack of resources (and enough time in the day). Do you know of anyone who'd be able to take on the development on the Stargate side (if any)?

 

With kind regards,

Michel

[upstatemike]

For the reasons I noted above, I would not suggest that any effort be expended for a Stargate only integration. What is being suggested is a generic TW523 interface that could be plugged into ANY legacy X10 device in place of its current TW523 interface module. The legacy device would think it is still talking to a TW523 module so no integration effort would be required on that side. The ISY side would just be communicating the TW523 signals to the ISY either over a network connection or through a hardware port. This is a one time effort that would apply to any TW523 based X10 device. The ISY already processes X10 information so this is primarily new hardware interface, not a new feature set.

 

Personally I think a separate device that communicates to an ISY over a network link makes the most sense. That way existing ISY units could be made to work with nothing more than a firmware upgrade. (And UDI adds another product to its current offerings).

 

upstatemike,

 

We would be amenable to any integration with almost any product. Our main issue is lack of resources (and enough time in the day). Do you know of anyone who'd be able to take on the development on the Stargate side (if any)?

 

With kind regards,

Michel

[brobin]

UpstateMike understands what I'm proposing. The TW-523 is a device that takes the X10 information sent by a controller or alarm panel and creates the X10 transmissions. By taking the INput to the TW-523 into a port in the ISY directly, the ISY would be the receiver and the X10 signals would NOT go to the powerline unless programming in the ISY directed an X10 transmission through the PLM. IOW, the Stargate or other controller/alarm panel would not put any signals onto the powerline thereby eliminating the possibility of collisions between the two.

 

The purpose of the TW-523 was to create a simple method to interface a controller or alarm panel to generate X10 signals without having to create the hardware or get a UL listing. The specs on how to to interface are here:

http://www.smarthome.com/manuals/MAN-1136.pdf and with that info, the ISY would recognize the incoming X10 transmission and either create an X10 or Insteon powerline transmission to the PLM.

 

Since UD is obviously an Insteon Developer, I'm sure there must be access to some code to interface with the TW523/PSC05.

[MikeB]

Ahh - I understand now. Thanks for the clarification, guys.

[Michel Kohanim]

upstatemike,

 

Got it ... we'll see what we can do to make this happen.

 

With kind regards,

Michel

 

For the reasons I noted above, I would not suggest that any effort be expended for a Stargate only integration. What is being suggested is a generic TW523 interface that could be plugged into ANY legacy X10 device in place of its current TW523 interface module. The legacy device would think it is still talking to a TW523 module so no integration effort would be required on that side. The ISY side would just be communicating the TW523 signals to the ISY either over a network connection or through a hardware port. This is a one time effort that would apply to any TW523 based X10 device. The ISY already processes X10 information so this is primarily new hardware interface, not a new feature set.

 

Personally I think a separate device that communicates to an ISY over a network link makes the most sense. That way existing ISY units could be made to work with nothing more than a firmware upgrade. (And UDI adds another product to its current offerings).

 

upstatemike,

 

We would be amenable to any integration with almost any product. Our main issue is lack of resources (and enough time in the day). Do you know of anyone who'd be able to take on the development on the Stargate side (if any)?

 

With kind regards,

Michel

[brobin]

Michael,

 

I am VERY happy to hear that. That one item would make the ISY virtually perfect as a translator as the collisions would be eliminated. The legacy controllers and alarm panels that we have will remain useful and you'll sell a lot of new product!

 

BTW, I'd be very pleased to be a beta tester of this new feature. You're welcome to come watch it in action here in Hawaii.

 

Aloha, Bruce

[upstatemike]

If the translator is a separate device communicating with the ISY over the network then it could be supported by both Insteon and UPB versions. the translator could use a common communication method and the different ISY controllers can handle the communications differently as appropriate to each protocol.

[Michel Kohanim]

Hi Bruce/upstatemike,

 

I totally understand ... the good thing is that we are still in the design phase and thus all this input is quite invaluable to us. Thanks so very much.

 

With kind regards,

Michel

Michael,

 

I am VERY happy to hear that. That one item would make the ISY virtually perfect as a translator as the collisions would be eliminated. The legacy controllers and alarm panels that we have will remain useful and you'll sell a lot of new product!

 

BTW, I'd be very pleased to be a beta tester of this new feature. You're welcome to come watch it in action here in Hawaii.

 

Aloha, Bruce

[brobin]

If the translator is a separate device communicating with the ISY over the network then it could be supported by both Insteon and UPB versions. the translator could use a common communication method and the different ISY controllers can handle the communications differently as appropriate to each protocol.

 

Absolutely correct, however, I'm not sure that UPB and Z-Wave would be affected as much or at all by competing X10 signals. Insteon devices have the benefit of being able to use X10 signals but that introduces the problem of interfering with one another.

[upstatemike]

 

Absolutely correct, however, I'm not sure that UPB and Z-Wave would be affected as much or at all by competing X10 signals. Insteon devices have the benefit of being able to use X10 signals but that introduces the problem of interfering with one another.

 

I understand but I was speaking from the aspect of making the device have the widest application with the least amount of duplicated effort. The TW523 side is fixed so that would only need to be designed once. If it communicated over a LAN using a set protocol then that would also be fixed and would not need any ongoing support effort. The only variable then becomes the firmware in the ISY model receiving the LAN communications from the translator. That effort can be folded into the general roadmap for any particular ISY model and additional models or features can be added without having to rework the translator itself.

 

The paradigm I am suggesting is to get the information onto the LAN using a standard protocol and then any ISY model can use the signal as appropriate to the lighting technology it is supporting.

[Michel Kohanim]

upstatemike,

 

That makes perfect sense and we are "almost" in synch.

 

With kind regards,

Michel

 

 

Absolutely correct, however, I'm not sure that UPB and Z-Wave would be affected as much or at all by competing X10 signals. Insteon devices have the benefit of being able to use X10 signals but that introduces the problem of interfering with one another.

 

I understand but I was speaking from the aspect of making the device have the widest application with the least amount of duplicated effort. The TW523 side is fixed so that would only need to be designed once. If it communicated over a LAN using a set protocol then that would also be fixed and would not need any ongoing support effort. The only variable then becomes the firmware in the ISY model receiving the LAN communications from the translator. That effort can be folded into the general roadmap for any particular ISY model and additional models or features can be added without having to rework the translator itself.

 

The paradigm I am suggesting is to get the information onto the LAN using a standard protocol and then any ISY model can use the signal as appropriate to the lighting technology it is supporting.

[timlacey]

I am also a Stargate user and would like to be able to send Insteon commands from Stargate. Many here are suggesting a device to simply replace the TW523 and allow us have the ISY react to X10 signals by either sending X10 signals or translating them to appropriate Insteon groups or commands.

 

I think my needs would be satisfied by simply sending ascii commands directly to the ISY. I would simply replace all my X10 lighting commands with ascii strings to the ISY COM port and I could have an unlimited number of "macros" in this manner.

 

Is the ISY com port designed for this level of interaction? Can the ISY be programmed to act certain ways upon receipt of information through the serial port? Is there a protocol we can follow to do it this way?

 

I guess the solution to replace the TSW523 is good, except that I can send ascii strings faster than I can send X10 commands. So if I wanted to control a lot of different things, I'd simply send a set of ascii strings to the ISY. Otherwise, I'm transmitting piles of X10 and waiting the associated amount of time. Unless I assign unused X10 codes as macros for the ISY to interpret, which would allow me to send fewer X10 codes.

 

My primary reason to switch to Insteon is for faster and more accurate lighting control (plus my old Switchlincs are failing and needing replacements). Using X10 to talk to Insteon seems like a slow hack.

 

I guess it's a matter of finding the best workaround since JDS has no plans or means to offer Insteon support. it's possible that JDS could offer Insteon support if it interfaced natviely with a device like the ISY.

 

Thanks for listening to me ramble on - I just thought I'd express my thoughts rather than ask for anything specific, if it helps Universal Devices decide if and how they can help the Stargate community. If it matters, I'm also a Homeseer user, but I've always handled lighting in the Stargate because it's faster and most reliable. I have the option of simply having the Stargate trigger events (by setting a variable in the Stargate and monitoring the same variable in Homeseer) in Homeseer to initiate lighting events.

 

Tim

[upstatemike]

Remeber the slow transmission of X10 is due to the powerline portion of the transmission, not the TTL signals going into the TW523. I do not think you can transmit ascii over serial faster than translated TTL codes over ethernet.

 

Also you will use up your stargate memory a lot faster sending ascii instead of using the X10 command set already included in the Stargate ROM.

[timlacey]

Does the TW523 generate the X10 signals or is the timing and signaling created by stargate and the TW523? I read earlier in this thread that made it sound like the X10 signaling took as long as it took for the signals themselves. if i am wrong, then yes, a TW523 interface would be great. Especially is the ISY could interpret the signals and know which to transmit and which to translate.

 

Your point about the Stargate ASCII memory usage is a good one. But I don't know if it would be an issue for me. I only use Stargate to control lighting by zone, so the number of commands is not too bad. And sicne I would want to send ASCII macro codes, I could send something like "MSG050" as a way to activate 6 or more switches at specific dim levels. So the ASCII load is low, but the result is a lot of commands.

 

Tim