Address grouping creates problems with repeater

I use a PowerLinc 1132U USB reporting firmware version 1.4 and Indigo 1.3.3. I also have installed a Leviton coupler/repeater in my house on a 15A 220V circuit. Using a testerlinc, I typically get a signal stregth of about 130 from anywhere to anywhere, indicating to me that I have a very reliable house. According to the Testerlinc manual, a strong signal is 90-100. My house is as close to 100% reliable as I know how to make it.

I wrote an Applescript that sets the condition of 7 lamps to various conditions based on time of day, spanning 3 house codes. For the first time, I saw the (address) show up after an on or off command. I then discovered the "Group Addresses On Transmission" command and I understand what it does.

However, my commands, when grouped, were not always triggering. Off commands work great, but on commands were failing to turn on the last address mentioned in the sequence before the on command about 40% of the time.

So, let's say I'm turning on G1, G2, and G3. Under address grouping, Indigo sends G1, G2, G3, GON. Sometimes G3 fails to turn on.

When I turn on my Testerlinc, and there is a failure of G3 to turn on, it shows G1, G2, G3, and then a BSC or BBK, meaning Bad Start Code or Bad Block. At that point, G1 and G2 come on. For some reason, the G3 and GON commands are getting confused on the power line, but are recognizable enough for the G1 and G2 to recognize it as an on command, but G3 never sees itself addressed. So, I grabbed my Maxi controller and tried to duplicate the problem. In dozens of tries, I did get it to happen once. So, I shut off the repeater, and tried it again. Sure enough, no problem exists when the repeater is off. I can't get it to fail at all from the Indigo console, but with the repeater on, group commands fail about 40% of the time.

However, issuing the commands more slowly from the Maxi controller lowers the failure rate to zero. It seems if I sent the commands slower, they'd work.

So, here are the questions:

Are the grouped address commands pushed out at a greater rate than non-grouped? I'm guessing they are, because I never see this happen with regular commands. Can you confirm?

Second, if this is in fact the problem, can an adjustment for the rate at which commands are sent become a programmable option in Indigo so those of us with this problem can raise reliability instead of disabling this mode? It really does cut down on traffic, even if the commands flow slightly slower, it still beats individual commands for long sequences.

Any thoughts?

-Dan

[matt (support)]

Hello Dan,

Thanks for the detailed info and troubleshooting on this. I wonder if this is just a PowerLinc and Leviton incompatibility or if the other interfaces also have a problem with this.

The commands are grouped if, when sending a command to the interface, there is an similar command to a different address in the queue of commands to be sent. Therefore, you only see the grouping occur if your queue gets backed up with at least one command waiting to be sent. This happens if you have an Action Group send out a list of commands. It is difficult to make happen by manually controlling devices -- you aren't very likely to end up with commands waiting in the to-be-sent queue.

Are the grouped address commands pushed out at a greater rate than non-grouped? I'm guessing they are, because I never see this happen with regular commands.

They go out on the power line faster since they don't have to have the associated function sent with every address. Indigo sends X10 data (either addresses or functions) to the interface whenever the interface is ready to accept a new command. I don't know why this problem only happens with the grouping turned on since there is not difference in the technique used to send commands to the PowerLinc in either case. The PowerLinc USB reports an all-clear code when it is done putting X10 data on the power line at which point Indigo sends the next command. The responsibility of how quickly commands are sent is on the interface, not Indigo.

Second, if this is in fact the problem, can an adjustment for the rate at which commands are sent become a programmable option in Indigo so those of us with this problem can raise reliability instead of disabling this mode? It really does cut down on traffic, even if the commands flow slightly slower, it still beats individual commands for long sequences.

I don't like the idea of adding an artificial delay (even if it is optional) that delays commands to be sent N milliseconds after the PowerLinc has reported an all-clear response. However, if this fixes or eliminates the incompatibility between the PowerLinc and Leviton, then I'll consider adding it. It sounds like it likely will, so I'll look into it some more.

Regards,
Matt

Thanks Matt. I really don't like the idea of it either -- I will talk to Smarthome tech about these two products and see if they have an opinion on wether or not a swap on the repeater or a different brand could make things work better.

-Dan

A brief update -- I spoke to Smarthome technical support, who continues to impress me. According to them, the Leviton repeater has no buffer, and it takes about 7/10s of a second to 'repeat' the command out the other 220V phase. Because it has no buffer, any set of commands sent quickly has the potential to cause this problem. The technical support person that I spoke to had this exact problem with Homeseer. He indicated that Homeseer did have a delay option built in to address the exact problems of no-buffer repeaters, and he indicated that for people that had the problem with Indigo could have it corrected if this delay existed. To be sure there was no issues with large strings of commands, he had a 2sec. gap (holy cow!) between each buffered command being sent out.

The only difference we discussed is that he would have the problem occur with any string of commands, not just grouped address commands. The only difference between our rigs was Indigo and Homeseer.

So, for people with this type of repeater, a delay option may be valuable.

Secondly, he asked me if I had a 220V outlet for a SignalLinc repeater. I said no, I had wired up the Leviton beastie specifically for this reason. He indicated that the reason it might be valuable is because the SignalLinc repeaters contain a buffer that can hold 8-10 commands before a buffer overrun occurs. Since it's sending repeated commands on the fly, running the buffer up to 8 commands pending is pretty difficult.

As luck would have it, Smarthome is having a promotion for a free SignalLinc repeater ($99) if you spend $200. I placed an order last week that went over the $200, and I put in my coupon code for my free repeater. I was going to sell it on EBay. Now, I think I'll wire a 220V outlet in place of the Leviton repeater and plug in the buffered SignalLinc to see if it works any better. I'll probably give that a roll this weekend and I will update this thread.

Thanks for the attention.

-Dan

Dan,

I have a similar setup and have had problems with reliability with the Leviton repeater (although signal quality was worse with a passive coupler). I have signal storms due to a race condition between the repeater and my X10 floodlights. I also have the occasional light that did not turn on or off, etc. I took advantage of the Smarthome offer also, so we will have another data point on their repeater in a week or so.

For now I would warn anyone who has or is considering buying the Leviton repeater to be aware of the consequences!

Matt,

This is another case where a dual interface feedback system might have prevented or compensated for the problem.

Dennis

I installed a 220V outlet on my dedicated repeater circuit and plugged in the SignalLinc Coupler/Repeater tonight. Everything works great, address grouping is no longer causing a problem.

I'd say that the Leviton repeater is not optimal for any automated controls -- manual controls could likely never overrun it, but it looks like automation can.

-Dan

Quick update: The SignaLinc died. It worked for a few hours and now although the outlet is fine, the LEDs only light up on one phase. I doubt they burn it in real well at the factory, but I'll find out when I call Smarthome. Guess I'll wire my Leviton to a 220V plug now and use it in the meantime.

-Dan

Quick update: The SignaLinc died. It worked for a few hours and now although the outlet is fine, the LEDs only light up on one phase. I doubt they burn it in real well at the factory, but I'll find out when I call Smarthome. Guess I'll wire my Leviton to a 220V plug now and use it in the meantime.

Dano,

I got my SignalLinc delivered, plugged it in and blam! The electrician wired the socket wrong which put 220V where 110V was supposed to go. I wired my old Leviton to the burned out carcass temporarily so I could plug it in until the new one my Electrician bought me arrived. I plugged in the new one, and it has been working fine for a couple of weeks. No more signal storms, and good signals between phases.

Dennis

Yep, my replacement arrived and once plugged in worked perfectly. Address grouping is solid and have not yet experienced another problem where anything fails to receive a command. I definitely recommend this over a Leviton repeater any day.

-Dan