X10 Programming and Response Time

[vmiller]

I'm having some trouble with my x10 setup and hoping that some of you can help me out.

I have a loop where I repeatedly do the following for each x10 controlled device.
1. decide if it should be on or off.
2. get the current status of the x10 device (on or off)
3. if 1 and 2 have different results:
3a. set the x10 address
3b. switch the device.

The problem is after this loop has been running for several hours, the x10 response rate is very bad. For example, I'll send a command to turn on a heater, and it will never happen. Because I'm using 2-way modules, the command is repeated until successful. Sometimes this takes 10 seconds, sometimes 5 hours.

I know this has nothing to do with the lights because it happens regardless of the lights being on or off.

I am using the jpeterson java x10 api.

Thanks,
Vin

[George Azar]

how often the loop is run? 100 times a second?
I would make it pause for 30 sec before it runs again. You may be saturating the power line bandwidth!

[vmiller]

It runs only a few times a minute.

[bstreib]

Hi,
Well I don’t know exactly what is going on in your system but I had a similar experience several years ago. I don’t profess to be a programmer but the ones I worked with had some of the same problems. They blamed it on the hardware, I tested it every way I could and couldn’t make the hardware fail until we went automatic under the software control.

To get around the problem I went back to relay ladder logic and a modified X-10 device. My program doesn’t ask the devices to report their status but I sense the status of the devices discretely. The more important the device being controlled the more sensors that are used to determine its status and condition of operation.

For example a pump providing closed loop circulation has a fairly high priority in my system. So the X-10 device that controls a device controls a relay; I also use a current detector to determine if the pump motor is using power and flow detector to determine whether or not water is being pumped by the pump. The logic then reads if the X-10 is ON and the current detector is ON and the Flow detector is ON then turns ON the backup control relay. When the backup control relay is ON, the backup system is in standby. Should the electricity fail, pump motor fail, the pump impeller breaks comes loose the standby relay turns OFF the battery back up becomes active and warning system enunciates.

Hope this helps. Bill

[vmiller]

Bill,

What do you mean by 'relay ladder logic and a modified X-10 device'? I'm using the CM11A transmitter and 2 way appliance modules.

Are the power and flow detectors x10 devices? If so, where did you get them?

Thanks,
Vin

[bstreib]

Hi Vin,
I modify the X-10 devices myself so the output is not enabled until the logic conditions are met. This is done by braking the downstream hot leg of the device. Ladder logic is the logic used to program PLC’s and in older equipment the intelligence is controlled by relays.

The current detector is a DIY device. My current flow meter is a surplus industrial one currently although I am working on a DIY magnetic stack flow meter.


The above is example of some simple relay logic. The first line reads that if the main pump is drawing current “AND� the flow detector detects water flow from the pump; turn on control relay CR-12. The second line reads if control relay CR-12 contacts are not on, turn the battery backed up pump motor M4 on.

With ladder logic you can build some very complex logic statements. I use this for automated water changing and tidal surge circuitry. Some of the plans for these mods and devices can be found in my book being hosted on the Infinity Soft website under the automation tab. www.infinitysoft.net

Hope this helps Bill

[bstreib]

Sorry the embedded jpeg did not post. E-mail me if you have any questions. Bill

[vmiller]

Solved.

After unplugging practically everything in the house, I figured it was not an interference problem and must have been my code.

I found a method in the api I am using that needs to be called after transmiting a command. It causes the calling code to wait until the command is actually transmitted. After adding this method call, the x10 response time improved from a best of 10 seconds with many commands not happening at all to a reliable 1 or 2 seconds. Much better. :)