I am planning out my new home HA system, and one of the requirements is to have a light switch status, or more precisely, change in status, communicated back to the ELK system I will be using. It dawned on me that my plans to use X10, INSTEON, or Z-wave may not RELIABLY provide this capability. I had been thinking that if I changed the light in question via IR, that the communication of status would work, but not so if the switch itself was used. Has anyone any real life experience with communicating switch status using any of these protocols?
There are X10 light switches made by Leviton and others that transmit their status when turned on locally. There are also switches that are transmitters only, and send a command to a another module located at the light that actually controls the current. Your ELK can intercept the transmitted commands from these switches.
All of these switches cost significantly more than the typical X10 wall switch.
Smarthome-manufactured two-way X-10 switches and modules transmit (preset Dim codes) when there is a change. Insteon switches and modules can also be programmed to transmit on a status change - you need to program your controller to receive/report them.
I'm not as familiar with UPB but believe they can also transmit on a status change.
Some Leviton switches and some X-10 made modules transmit when there is a change but they send extended X-10 codes and not all software can handle that.
I'm not familiar with the various ELK systems so cannot say whether they can handle preset and/or extended X-10 codes or whether their Insteon and UPB add-on modules can be programmed to receive the changes.
I was aware of the two way appliance modules, but did not remember seeing wall switches of the two way variety. I'll do some more research. Since the XTB design does not support amplifying these signals, the reliability is still a question?
Thanks for the input. I was under the impression that the reliability of the X10 and INSTEON units was quite questionable. The timeliness of the Z-Wave signal, if your just talking about 5 seconds or less, isn'tan issue, if the signal can be counted on getting there. Since I am not interested in fancy lighting effects, but just simple on/off condition dependent triggers, I am wondering if I am looking at the wrong group of lighting controls. I even thought that a rack of relays controlling the 110V lights, and triggered by momentary switches in each room, Through the ELK control panel would meet the need, but it seemed there should be a better solution.
The quality of the Smarthome devices has improved and they offer excellent warranties in those cases where there are problems.
You should investigate Z-Wave thoroughly before committing to it. They operate sequentially with node A sending to node B, node B sending to node C, etc. It takes a finite amount of time for each hop. The return signal takes the same path and time. There is a maximum number of hops so a signal originating at node A cannot go beyond node E. There is a minimum density required - I expect you will need a nodes within 20' of each other for reliability. I do not know whether switches signal when operated locally. There are some limitations on which controllers "hear" activity. You really need to address your specific questions to someone who works with it (e.g. Dean Roddey uses it in his small apartment.) but I would take anything said by dealers with several tons of salt. The devil is in the details. I asked one of the dealers about how long it takes a signal to traverse the network and he got an answer from one of the Zensys engineers. IIRC it takes about
250ms from A-E and another 250ms from E-A assuming there are no glitches that require retransmissions. But Dean Roddey seemed to indicate it was really much, much slower than that.
You also need to investigate whether the ELK hardware you plan to use can "hear" the extended codes sent by the Leviton switches. While Leviton calls them preset dim they are not the same as the standard preset dim defined by X-10.
Smarthome does use the standard preset dims for reporting status so most X-10 software will report them.
If your powerline interface is located near the distribution panel, it should hear the transmitted commands just fine. They only have to propagate down that one circuit. The signal level problem comes when a signal first propagates to the panel, and then has to be sent out all the branch circuits. The signal on the branch circuits can be pretty low, especially when signal suckers are in the loop.
We don't use any of the 2-way Leviton switches here, but we do have their wire-in 16400 transmitters. Those send out standard X10 commands on up to 4 sequential addresses on the same housecode. We use them for exterior lights, irrigation, and triggering macros in the Ocelot. There are also single paddle Decora transmitters that can toggle a single X10 address ON/OFF.
I have INSTEON and an Elk M1G but am running INSTEON under Homeseer and have also used SmartHome's HouseLinc software which makes setup simple and ends for all time the tedium of codewheels and mechanical configuration.
HouseLinc reports status of switches if queried.
Homeseer monitors without any prompting and reports status as % dim at the last change (= current status) in day:mo:yr & hr:min:sec format regardless of whether the change was under computer control or manually at the switch.
I have not monitored to see INSTEON/Homeseer reporting/logging is 100% accurate.
Other than sometimes having a collision of commands if I push the buttons on two dimmers in the same switch box exactly simultaneously (one finger on each button), INSTEON has been working flawlessly in a house in which X-10 was perennially flaky despite considerable investment in time, circuit reconfiguration, monitoring equipment, filters, and coupler/amplifiers.
The " two-switch glitch " apparently occurs because one of the dimmers is a Slave (located at the top of the stairs) that sends a signal to the actual Master dimmer (at the bottom of the stairs). If these were two Master dimmers, it is likely that the failure of the dimmer to respond would not occur, but that the inevitable collision might/would mean that one or both of the state changes would not get received by the INSTEON interface and therefore not be logged. I'll check this out tomorrow and report back.
This collision problem is much more severe with X-10 than INSTEON because of X-10's much slower data transmission rate.
I've been working on a "polite" mode for the XTB-II where it will sense a collision immediately, abort the transmission, and re-transmit when the line is clear.
While some report significant collision problems, I wondered why we don't see that problem here. Pushing the numbers, it appears that collisions should not be much of a problem unless the installation includes X10 motion detectors in high activity areas.
As most of you know, it takes almost a second for a typical X10 transmission. Our installation runs about 200 transmissions a day. All but a few come directly from the Ocelot. So, a collision would only show up if one of the manual transmissions managed to occur during an Ocelot transmission.
Our motion detectors are either hard-wired directly to the lights, or to the Ocelot. So their random nature is not a factor. In our case the powerline is carrying X10 traffic less than 0.2 percent of the time (using the number - gap - function model). That, and the fact that the RR501 is supposed to avoid collisions, is probably why we don't have the problem here.
Adding wireless motion detectors in high activity locations interfacing to the line through a dumb TM751 paints a different story. Those motion detectors can add hundreds of more X10 transmissions to the mix. Many people opt for the less expensive TM751, which does not include collision avoidance. So the chance of a collision might approach 1% or more.
The bottom line is that collisions can be largely avoided by using a RR501 in place of the TM751, and having most X10 commands be issued by one primary controller.
To clarify: the INSTEON collision I described occurs when there are two dimmers side-by-side at least one of which is a SLAVE (hot and neutral connections only) that are physically pushed (manually) simultaneously (< ~1/5th second difference).
Granted, I am doing something with INSTEON that ABIK cannot be done at all with standard X-10 dimmers, namely, communicating from SLAVE to MASTER Dimmer without using physical ("traveler") wires as standard X-10 3-way switches do and without recourse to an intermediary controller (Ocelot, Elk, Homeseer, etc).
All that is needed is a hot and a neutral for any INSTEON switch/dimmer to control any other INSTEON load in the system.
This is a powerful tool that is not only convenient and adds great flexibility, but can save many $ and grief when the inspector says you need a second light switch to an existing load. With X-10, this can be done through a custom-programmed, proprietary computer/controller with all the attendant issues -- as well as the minimum ~2-second delay for even a single command to be sent and relayed -- and assuming no collisions. (I also have a few Leviton X-10 keypads that can be used for this sort of thing that will be in my porch sale.)
Note too that if one has deterministic commands in one's controller that specify multiple instructions at the same time, something will have to give. In the case of both X-10 and INSTEON, it is typically that the instructions are not put on the AC line at the 'same' time. In many/most cases this lag is not significant if , as in Jeff's case, collisions do not occur. But in some cases, long, multiple lags resulting from separate commands to multiple devices may be undesirable if one is trying to create a lighting effect.
For example, the variable time lag of X-10 rendered next-to-useless a nifty feature of the Savoy CyberHouse software I used for years. What Savoy dubbed "lighting vectors" and others have described as "lighting paths" (having lights turn on in sequence in response to motion detectors) depends on timely response to the occupancy sensors. The time lag of X-10 is/was such (in my case) that it jist didn't work well enough. (I also had another, non X-10 source of lag owing to the slow response of NAPCO relays to sensors.)
The scenario I was looking at was turning on a light with the local switch, and having the M1 receive the state change so a rule could be triggered. If it's not to much trouble, could you try setting up a rule in the M1 to see if this would work using the insteon hardware. .
I was unable to get either two adjacent INSTEON ICON dimmers or two V2 dimmers (acting as MASTERs) to exhibit any 'glitches' despite repeated attempts.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.