Preventing looping/repeating with multiple X10 interfaces

[redbeard]

I'm trying out HB to (hopefully) replace an existing HA system in my home. I have an Ocelot with an X10 PLC interface attached to it as my main X10 transceiver. I also have an MR26A for X10 RF commands. I use PalmPads, motion sensors, etc. for X10 control.

I would like to have all RF X10 commands echoed to the power line for pass-thru controls. I tried the method in the MR26A Help file about using the X10 Composite device settings, but I get looping or repeating of X10 commands every second, which cycle on forever. I believe that once I issue an X10 RF command via the palmpad, the change in the composite device forces an X10 transmit, which the Ocelot sees, which then creates another change, etc. How do I get around this? Is there a way to have the composite X10 device change only once?

There must be a way to make this work short of creating tasks for every transition of every device/unit code... I can't seem to figure it out in the HB format. Appreciate any suggestions/help!

[ScottBot]

I believe that once I issue an X10 RF command via the palmpad, the change in the composite device forces an X10 transmit, which the Ocelot sees, which then creates another change, etc.

So do you have a wireless X10 transceiver somewhere that is also taking the X10 RF and sending it on the powerline? That would be the only explanation that I can think of about how the Ocelot would see the X10 command as an incoming command.

[redbeard]

Hi ScottBot, thanks for responding so quickly. I saw you posting over at CocoonTech, too - great bunch over there.

No, I haven't used plug-in RF receivers for years. I've been using X10 since Homeseer was only $30! hehe But I don't know enough about HB to be able to troubleshoot it. Is there a log or debugging I can turn on to see what's going on?

The thing is, I shut down Homeseer and installed HB on the same machine, so HB is using the exact same devices that HS was using. HS has no problems with this setup. Haven't had problems like this for years. Somehow HB is getting into a logic loop - whether thru internal or external I/O.

I'm using the eval version of HB, and Icreated the X10 Composite device. This is the code that I'm using, the example came from the MR26A help file:


If ('X10 Control.Composite Property' is Not Equal 'Never Match') Then

Change 'X10 Control.Composite Property' to '%%X10 Control.Composite Property%%'


In my case I created a device called "X10 Control" on the Ocelot.

So, any idea what I'm doing wrong?

Thanks...

[ScottBot]

A data trace may give you some more clues. To generate a trace file:

1. Select the Hardware Interface from the Tree View.
2. Click on the 'Hardware Module Type' button at the top of the Interface Property list.
3. Click on the 'Enabled' checkbox to turn on tracing.
4. Try and use the interface again. This should generate data in the log file.
5. Turn the tracing off by clearing the 'Enabled' checkbox set previously.
6. Looking through the log file may give you/us some clues on what the Ocelot is doing. The file can be found in the HouseBot\Logs directory.

[redbeard]

Ok, here's the trace log. I enabled logging on both the Ocelot and the MR26A to see the interaction.

I have my X10 Control device set up and enabled, but I clicked off the "Allow Same Value Changes" on the X10 Control.Composite Properties. This prevents the pass-thru and I get no reaction, as expected.

With it in this state, I hit D1 ON, then D1 OFF, then D1 ON, then D1 OFF, and got no results. But these are easily seen in the log.

Then I enabled the "Allow Same Value Changes" on the X10 Control.Composite Properties. I then hit D1 ON, and the light went on. A few seconds later I hit D1 OFF, and then the light went off, on, off, on, etc. until I cleared the "Allow Same Value Changes" again. You can clearly see the flip-flopping in the log.

As far as I can tell, the Ocelot IS seeing the MR26A and HB is acting on it... as evidenced by the "X10 Command Received" and "Read Pending..." and "Writing" lines, but I could be wrong.

The question is, how do I stop this behavior?

[ScottBot]

The trace is certainly showing the Ocelot continually sending the same command over and over. However, it is not showing that the Ocelot is receiving the commands as echos. Nor does it seem to be showing the MR26 as causing additional looping. Note that in the trace there are messages from the Ocelot about "Reading X10 Response", but these are trace messages about reading a response about the X10 command being SENT, not received.

Since you were able to effect the looping by changing 'allow same value change', my guess would be that the looping is coming from within HouseBot. I'd first suggest disabling (for diagnostic purposes) any Tasks or Scripts that use the X10 Controller Device in them anywhere. You may also want to click on the 'Tasks' node in the tree view and watch all tasks to see if you see any changing state while this is happening.

[redbeard]

Right, Scott, it appears to be just the X10 Control continually looping. Which is exactly what I thought it would do given the circumstances and the way the MR26A info was written.

Ok, let me start over. I have a device called "LR Lamps" which is tied to the Ocelot device for X10. "LR Lamps" is D1. With the MR26A in place, when I press D1 ON on my palmpad, I immediately see the Power State of "LR Lamps" turn on. Likewise, when I press D1 OFF, the Power State immediately turns off.

However, nothing is sent by the Ocelot onto the power line. I have tried different combinations of the various checkboxes to try to force it to work, but I get nothing. I've recreated the device and the hardware interface, to no avail. That's when I read the MR26A info about the "X10 Controller" and setting up a task to toggle the power state to force an X10 transmission onto the power line. The "X10 Controller" is part of the Ocelot, as the MR26A has no transmit capability.

So, how are things supposed to be set up so that when I press D1 ON on the palmpad, the MR26A hears it and tells the Ocelot to send a D1 ON over the powerline? What interface or piece am I missing? I shouldn't have to write a script for this, should I?

I do have timed events firing just fine, and I can send a man8ual X10 transmission from the device itself, so no problems with the Ocelot's PSC05 interface. There must be a logical link I'm not aware of (Power State change forces X10 transmit?).

[ScottBot]

I just retested your configuration and you are completely right. If you have the 'allow same value changes' selected (which you would want to have selected), it will repeat. The X10 Controller used to ignore the 'same value change' setting and never change if they were the same. Therefore, when the documentation was written, it was correct.... it's no longer correct.

I have a solution for you, but it's a bit of a hack. Here's what you can do.

• Create a second X10 Controller Device and associate it with the same Hardware Interface. For this example, I'll call it X2
• Create a new 'manual' Task that has once action. The action should assign the Composite Property of your original X10 Controller Device to the value of X2.Composite Property (Change X10 Controller Device.Composite Property To %%X2.Composite Property%%)
• Change your original Task that was wrong in the online help to test the value of X2.Composite property instead of your original X10 Controller.
• Change your original Task that was wrong in the online help to execute the new task you created instead of changing the property value directly.

If you were able to follow along, your reaction should be complete confusion now What this does is to break the looping by making sure that the main task doesn't contain any reference to the original X10 Controller Device. Both of the X10 Controller devices will get updated when the RF X10 is received. However, the X2 device will be used for triggering the task. By calling a task from a task, it works around the rule that causes a task to be evaluated when any of the properties in it have changed. Since the original X10 controller isn't in the task, it doesn't get evaluated.

Hope this makes some sense.

[redbeard]

No, that makes sense, Scott. It removes the direct reaction and creates a hysteresis or a one-time trigger. Initally Homeseer had the same problem but they resolved it within the interfaces. Any idea if this "proper" capability will be integrated into one or the other device (or HB itself) at some point?

[redbeard]

PS> At first glance, I thought I could create an X10 Transmit device and have that initate an X10 transmit on the Ocelot when triggered from the MR26A. But no... maybe that's what we need - a "retrigger" device.