I am using X10 extensively to controll all of the lights in the house. At present all downstairs lights are on house code A and all upstairs lights on house code B.
I have several responses programmed to automatically control the lights triggered by both on and off responses of various PIR detectors. On responses turn some lights on after dark, off responses turn them off again after a delay.
Comfort is the only X10 transmitter on the system.
Often, when people move in different rooms at the same time, there seems to be some kind of corruption of the X10 signal, resulting in a whole batch of the lights on the same floor to suddenly go full on. Usually this is A1 through A10. The fault is repeatable.
I'm guessing that multiple X10 commands are being sent too close together resulting in corrupted X10 instructions. Is there any way this can be checked for and stopped? I understand that X10 commands are sent twice in case the first try does not reach the destination, is this a function of the X10 interface or the Comfort panel?
I could try and program something with flags and delays to stop the clashes but it would be better to fix this issue as close as possible to the source.
Comfort will check that there is no X10 signal being received on before it sends an X10 code.
Eeven if two PIRs are triggered at the same time or very close together, Comfort will queue the X10 signals and will send them one after the other so it will not send two X10 signals and cause a collision
If this is repeatable can you document what sequence causes this and which modules are turned on in relation to your program?
There is one program in particular that seems to cause this regularly, although other combinations of responses also cause the problem but less often.
One PIR is programmed to send X10 A10 ON as an on response, and X10 A10 OFF as an off response, to give a silent indication of movement by flashing the living room light. This initially caused the dimmer micro-module on A10 to re-program itself (in addition to the other problem) because it responds to several on-off sequences close together as an instruction to enter programing mode so I added a 10 second delay to the off response. This has stopped the re-programming of the module but the other fault remains.
When the fault occurs, all X10 lights on the A house code except one (12 out of 13 at present) turn instantly on, full brightness. The one that does not turn on may due to that module not being programed to respond to an all-on X10 command but I'll have to check that later.
I do have an X10 serial PC interface so I will try and get some logging of X10 events going and trigger the fault so we can see what is happening on the X10 side.
In order to easily simulate the fault (typically once I started monitoring the fault was difficult to reproduce) I set the following responses.
PIR On Response - Send X10 A10 ON
PIR Off Response - Send X10 A10 OFF
For a while the light on the A10 dimmer pulsed up and down as would be expected, however after a few minutes of dancing around in front of the PIR all of the A housecode lights came full on.
The X10 monitor showed the following at the point the fault occurred
A10 A ON A10 A ALL LIGHTS ON A OFF A10 A ON 20:06:08
A10 A OFF A10 A OFF 20:06:20
The numbers at the end of the lines are times.
So........ Something is inserting an X10 A10 ALL LIGHTS ON message into the string. I've been through every response on the system and that X10 command isn't used anywhere so it can't be a spurious response. It must be coming from Comfort.
The fault also occurs with other combinations of X10 based responses although not as readily as with this test program which is much more busy on the X10.
My Comfort firmware is currently version 5.144 although my second UCM05 has arrived today so a batch of firmware upgrades is imminent.
Hopefully you can reproduce this behaviour at Cytech and come up with a solution.
You can monitor what commands Comfort sends out using The Monitor I/O in Comfigurator. This shows all X10 commands sent out
We can try to duplicate this, but I doubt that this is due to Comfort. Comfort cannot insert a A All Lights On command by itself. The firmware to send X10 commands does the same thin everytime.
It is more likely due to the inherent problem associated with X10 ie it is subject to noise on the power line which distorts the small x10 signals and changes the command
X10 commands need to be sent two times on the power line to try to overcome this. If one of the transmissions of the two is corrupted by noise then this may be what you expect
I've finished the firmware upgrades to the main panel and all SEMs and UCMs.
I then tried monitoring both the comfort output via Comfigurator, and the X10 signals via the CM11.
Unfortunately I have completely failed to reproduce the fault since. I'm hoping that the firmware updated may have done the trick. If the fault re-occurs I will monitor both sets of data again and get back to you.
I dont know what firmware you upgraded from. The very old firmware may have X10 related bugs.
However X10 is very tricky stuff - it may be affected by other equipment or noise which was present before and is not active at present.