Some of you know I have been working on an enhanced repeater version of the XTB-II. I was derailed in this effort while taking advantage of the beautiful early spring weather here in the Southwest. Now that temperatures are pushing 100, I'm back to coding. I am aware of some of the special cases, and will be trying to handle them in an elegant manner. However, I would appreciate any input you might have regarding the unit's capabilities. Here is a link to that unit's development:
I'd like to have leads out to a Sonalert so if there is ever a broadcast storm for any reason it would beep. It would be very useful to know about it when happened rather than the *next* time I sent an X-10 command and it failed to fire. I just had an old BSR w/ultrasound crap out on me and I wasted a lot of time looking for the usual culprits, the PalmPads! Had the repeater beeped as soon as I hit that key and it stuck, I would have known right where the problem was.
I know you can lock down the repeater and prevent it from repeating the storm, but I think it would be very useful to be able to know exactly when that key got stuck and the X-10 PLC network "locked up." Even something that would simply close some relay contacts whenever an unending stream of X-10 commands was detected would be useful.
Unfortunately, that would require a hardware change. The XTB-II and the XTB-IIR will share the same V1.1 PCB. The board is populated with a few additional components for the enhanced repeater, and there are some value changes, including a different PIC. I already have the boards.
Your point on the broadcast storm is well taken. The present firmware includes an undocumented option that prevents the ping-pong that can happen when using multiple repeaters. That can be modified to also recognize a broadcast storm. However there is nothing the present hardware can do to issue an audible alarm or a contact closure when that happens. Sorry...
As someone else pointed out, reception of that command transmitted on the powerline may be questionable.
What would be easy to do would be to send a X10 coded command out the TW523 digital port. So an automation controller could log that event, possibly with a time stamp.
I'm not sure why you think that lets you off the hook on your first suggestion.
A transmission storm is usually from either a stuck button on a controller or palm-pad, or from two-way modules playing ping-pong with a repeater. Neither of those would involve communication with an automation controller that interfaces through the TW523 port on the XTB-IIR (except for relaying the bogus traffic). So if the XTB-IIR was smart enough to stop repeating the bogus traffic, it could then issue a message to the automation controller (through the digital port - NOT the powerline) that it had shut down its repeater. The automation controller could log that event, and possibly sound an alarm if it has hardwire I/O capability, such as the Ocelot.
Since the XTB-IIR output is much stronger than other line traffic, it actually could send a signal over the powerline. I have tested it here punching a signal through a X10 filter. So if an alarm module was plugged into the powerline through a filter, that might receive a command sent by the XTB-II while not seeing the communication storm. However, that would not be guaranteed to work, and the digital link directly to the automation controller would provide a much better communication path.
I confess I've paid little attention to X10 over the years. That is at least partly due to my background in security alarms where X10 is largely regarded as toy stuff. I used it on occasion years ago but found the hardware that was then available was too unreliable for use in alarms. More than 1/2 the modules I tried failed within a year -- several within a few weeks -- so I lost interest in it.
From what I've read here, the XTB sounds like a real problem solver where signals are not making it. I'm sure there are also some better quality X10 devices on the market but I'm not particularly interested in them.
For the above reasons I've only paid cursory attention to the XTB discussions and frankly, I didn't give the problem much thought before asking the question earlier. Had I given it more consideration, I'm sure I'd have come up with something more useful or kept my mouth shut.
Now as to the XTB's smarts, is there enough code space to add a check for repeated commands, say more than 20 of the same? If so, could it not then be made to send a message through the automation port as you mention?
Can you explain to us dummies what gets repeated? Is it only the controller that is plugged into it or does it repeat other X-10 signals it hears from other sources?
The existing XTB-II and the forthcoming XTB-IIR can repeat signals received over the powerline. The XTB-II will only do that while it is in the TW523 emulation mode. While I am still working on the code, I plan to have the XTB-IIR be able to repeat powerline signals regardless of what the normal source of X10 signals are.
Too bad. Maybe my CPU-XA can be programmed to recognize a broadcast storm and sound an alert when it happens. Since stuck buttons have been an issue at least four or five times in the past, it's something that I probably should address in some manner because it's so catastrophic when it happens.
Often, I may not have been the one to push the button that's gotten stuck so retracing my steps is sometimes pointless. The Monterey is useful in pinning down the bad device, but an alarm that sounded as soon as perhaps 20 X-10 commands in a row were detected would be far more useful in alerting the user to the problem the instant that it occurred, not minutes or hours later when then *next* X-10 command is sent and it fails due to a broadcast storm.
The newsgroup has been pretty dead lately - nice to see some activity again.
I'm planning to address the broadcast storm in the following way:
If the same command is repeated constantly for at least 30 seconds, the XTB-IIR will shut down its transmitter, and send a command out the digital port indicating the shutdown. The command will be a "Status OFF" issued on the housecode selected for XTB-IIR mode control programming - default is P. Your CPU-XA can watch for that command, and issue an audible warning when it happens. It could also log the exact time, which might be helpful to diagnose the problem. The XTB-II will continue to monitor X10 traffic, and will resume operation when the storm has been cleared.
It's summer vacation time and lots of people are away. I've been kinda busy with that unfortunate event I told you about. )-;
on > the housecode selected for XTB-IIR mode control programming - default is P.
I started thinking that the XTB needn't be involved at all. If you had an Ocelot or CPUXA already it seems it could be easily programmed to sound a bell after X continuous seconds of X-10 activity. However, if you can do it internally within your device and firmware that simplifies things. You'd just have the ADI device look for the BSS (Broadcast Storm Signal) and then it could take whatever action required.
I locked-up a CM11A recently and without the Monterey, I would have had no idea where to look. Worse, still, it was caused by a dangling serial cord and began long after the cord became loose. I think that happened just so Fate could show me that my detector wouldn't solve every case of broadcast storms. In fact, it would have gone off in the middle of the night when the CM11A reached some sort of critical mass and began "singing" its song.
The detector should be able to react to *both* valid X-10 signals and X-10 noise on the line for thirty continuous seconds and then sound an alarm that required a push button or a cleared power line to reset. Sounds like that wouldn't be too hard with what you're proposing. Will the XTBII detector react to both noise and valid X-10 commands? I ask because sometimes lockups are caused by a continuous stream of garbage commands as a result of collisions or unusual failure modes. It would be nice to catch those as well.
Since this isn't really a repeater issue anymore, I changed the subject heading since I'd like to come to some real-world solution the broadcast storm issue. I have just put another 10 Palmpads into play as video source controllers for the HACS AVS-8 switcher and despite precautions, they tend cause a lot of problems when someone (usually me!) places something on them accidentally.
This should be a really simple device to build - all it needs to do is detect a suspiciously long series of X-10 commands. Thirty seconds should be enough. I could probably modify an ESM1 and monitor the signal LEDs with a timer circuit and latching relay that beeped a buzzer if the diodes were lit > 30 seconds.
For reliability reasons I'd really like this to be a stand-alone piece of equipment. The next-to-the last broadcast storm occurred at a very, very bad moment. We were getting ready to leave for an emergency event and suddenly nothing X-10 worked. It was a day of *very* low SAF. Had I heard a beep when I moved the stuff on shelves near the dogs, I would have known right then and there that I screwed up and what device was the likely cause.
Since the Maxicontroller that failed seems to have died of "inherent vice" that tells me that some of its brothers will soon experience similar failures. Some component has probably reached the end of its predicted life. Since these sorts of failures tend to cluster, I can reasonably expect more. That means a detector is an imperative. Maybe the ADI/Ocelot folks have already worked something like that out. It seems something well-suited for an already X-10 "smart" micro-controller.
That reminds me that the "even cheaper than the ESM1" Controlinc Maxi has a status LED that displays any line activity. Anything that lights a diode in response to X-10 traffic could be easily modified into a "storm detector" that could start a timer when traffic starts and reset the timer when the traffic stops. If the timer reaches the end of its cycle without resetting, sound an alarm. A long, long time ago I used to build simple timer circuits using 555 IC's so it's something I can likely handle, although I'll bet there are much cleaner ways to build an X-10 broadcast storm detector than hacking a diode monitoring circuit onto a MaxiLinc.
I still like the idea of the XTBII as the sensor for the broadcast storm buzzer since the repeater is the ideal place to locate such a device. Broadcast storms are really "show stopper" events, especially when the bum signal is getting a whopping big double XTB boost!
Doesn't the XTBII light up its LED in response to valid X-10 commands? (I confess I haven't yet installed mine!) I could couple that optically to a phototransistor without any internal tap wires and use that as the broadcast storm detector's input.
Of course, I thought this out before I read that you'll be able to modify the XTBII's firmware to watch for, report on and act on broadcast storms. Still, a little stand-alone plug in broadcast storm "beeper" might even have some commercial potential. I am sure anyone who's ever run around like a headless chicken trying to find a stuck Palmpad or Maxicontroller button would consider shelling out a few bucks for one.
I thought a storm would be a continuous command - like from a stuck Palmpad button - and planned to look for a continuous stream of the same command. It would be easier to respond to any "X10 like" activity. That would catch collisions.
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.