Wireless X-10 Direct to XTension !
Dramatically improves responsiveness and reliability !
In other tutorials you've learned about the wireless (RF) remotes and sensors
that send signals to the X-10 RF-to-Powerline transceivers.
Traditionally, you must have one of these transceivers for every House Code,
and must set your wireless remotes and sensors so that they send addresses
with House Codes that match the setting on the (nearest) transceiver.
Since one transceiver will only receive RF commands from 16 different Unit Codes,
it usually leads to the necessity of having multiple RF transceivers, each with
that ugly antenna poking out into the room.
Now comes the new X-10 MR26a
RF to Serial Interface !
The MR26a is about half the size of a cell phone, connects to the serial port,
and has a cute little 'tail' for its antenna.
It costs less than $30 US, but also requires a serial cable adaptor to let us
Mac folks convert that PC connector to a Mac serial port.
Buy the MR26
Also notice that the
ActiveHomePRO now serves both powerline and wireless signals, including the security type codes !
And even more wireless interfaces now !
Exciting new possibilities !
The MR26 receives RF signals from any house code,
from ANY X-10 wireless transmitter,
including hand-held remotes, and motion sensors !
This means that if the MR26 is placed in a central location in your home, it can
replace all of the old RF transceivers you currently have. (see notes below)
It also means that the wireless commands no longer have to travel first to a
RF transceiver, that then sends X-10 commands to the powerline, be received
by the CM11, and then to the Mac and XTension.
The old RF transceivers must monitor the powerlines, and avoid signal collisions,
and there's still the problem of signal propagation across the two phases of
your powerlines, and of course the total signal path can be affected by length
and appliances which cause X-10 signal-destroying noise.
In theory, being able to go direct to the MR26, and then to XTension, will avoid
a lot of traditional problems with signal loss and response time.
Another little traditional problem is that of 'tracking' incoming DIM commands
from a remote. Neither the CM11 and especially the LynX, can accurately track
these and XTension has always had a problem keeping the database updated
with the current status of dimmers.
Now it is possible to have XTension receive the DIM commands directly from the
remotes, and then command the dimmers so that we always know the status
(unless of course you manually dim a lamp and the dimmer doesn't send commands
Update ! July 2008
XTension now supports all the RFXCOM wireless interfaces !
These are USB native, WiFi, and Ethernet based.
Update ! May 2007
The MR26 does receive the commands from the X-10 UR51a, "MP3 Remote",
and now XTension lets you create a Global Script "AUXRemote" that will be
called if any of the DVD/MP3 type commands are received. You can assign
your own meanings to these 'commands', and call ZephIR stored library IR
commands in response.
Update ! January 2005
X10 has released the ActivehomePRO that is combines powerline and wireless features into a single USB-Native interface !
See it here
The physical setup
The first thing you're probably going to need is a spare serial port. With an older Mac you
may need to get a PCI card with multiple ports, and on newer Macs you will want
to get a USB-to-Serial adaptor.
With older Macs that have traditional serial ports,|
you will also need a 'pigtail' that connects between
the MR26 cable and the DIN-8 connection on the Mac.
You can buy one Here
XTension and the MR26|
are known to work
with all these adaptors.
All are available
from X10 Wireless
USA19X and USA19HS
For USB Macs, the cheapest solution is the USA19X (about $40US),
since it connects directly to the cable
end of the MR26, without the need for the 'pigtail'.
Update: Unknown commands and inconsistent behavior
Already we are seeing that some individual units do not work on all Mac serial ports.
The problem seems to be that the voltage levels of signals from the MR26 are not
compatible with the receivers on the Mac serial ports.
With some Macs there is no problem connecting the MR26 directly, using the
suggested 'pigtail'. However there doesn't seem to be any consistency. Some
work when plugged in, others work sporadically, and yet others will not work at all.
You know for sure that you have the problem if you get NO commands registered
on your XTension Log Window, or if you get many "Unknown commands".
Jeffrey Lomicka has done the research that has shown that the voltage levels
are incompatible, and some additional hacking of the cable may be necessary
for those MR26's that are directly connected to the traditional Mac serial ports (not thru USB adaptors).
If you find that you have trouble with the connection, please check out
the famous "Lomicka Cable"
And some folks who use the
MegaWolf 4-Port serial PCI card, there is a
that can be made to work perfectly with the MR26.
Setting up XTension
This is the easiest part. With the release of XTension version 3.5.0, you simply
pull down the Edit Menu, select Preferences, and click on the "Comms" tab :
Then click on the "MR26 settings" button:
Select the port you want to use, and click OK, then click OK in the Prefs dialog.
The proper baud rate, parity, etc, should already be correct as shown :
That's all you have to do !
Just push a wireless remote button and see the event in the XTension Log window !
Well, not really. If you still have those old RF transceivers installed and in
range, you may see two or more messages in the XTension log for the same event.
So, now you need to think about just how you're going to organize your system,
like where you will place the MR26, and whether you need to keep some of your old
But do notice that XTension handles the incoming commands exactly like it did
when the RF command was transmitted over the powerlines to the X-10 interface.
Well Almost... It's a lot faster !!!
Those of you who have resorted to the technique of having a motion sensor send
signals on an address that directly turns on/off a lamp in a room, may no longer
be necessary. You may find that
having the signal sent directly to XTension and then having a Unit Script turn on
the lamp to a conditional level, is just as fast, and more satisfying.
The response time is now so fast that it probably will be just as fast to let
XTension handle it ... and you don't have to worry about fiddling with the
delay times in the sensor. If XTension is in control, YOU have control over
when the lamp is turned off !
Update for XTension 3.5.4 and later
Responding to user requests, version 3.5.4 includes the ability to specify which
of your units may be commanded by the MR26. However, this does not preclude a unit from being controlled by normal X-10 signals.
Wireless commands that are received for units that are not 'RF ok', will cause an
entry in the Log Window that says that the command was ignored.
Wireless commands that are received for X-10 addresses that are NOT in the database,
will cause an entry in the Log Window that just announces that a wireless command
for that address was received... no action will be taken.
There is a new option checkbox|
in the Edit Unit dialog that 'allows'
the unit to be commanded.
Also note that List windows indicate
that a unit is 'RF ok' by showing the
X-10 address in Italic face...
Note that with XTension version 3.6.5
there is a new 'Pass-Thru' option...
Notes about how XTension works with the MR26
You will have noticed that the wireless remotes and sensors often send more
than one command...?
This is perhaps an effort to avoid loss of signals, and it's not such a bad thing
unless you have scripts that respond to commands.
No doubt you've had to employ the old technique of testing the 'last timestamp'
of a unit and making sure that you don't respond twice to such commands,
unless it has been 'a reasonable time' since the last command.
It's a good idea to continue to employ this technique, but XTension does help
by employing a 'time filter' on the commands coming in from the MR26.
In short, XTension will remember the 'last' command and address, and if it
receives a duplicate within 400 milliseconds, it will be ignored.
This time filter may have to be adjusted in the future to accomodate such
things as DIM/BRI commands, but for now, the filter time is enough to allow
other things to happen, and reasonably emulates the effect that you see with
the old RF transceivers.
XTension NOW automatically relays wireless commands to the powerline (version 3.6.5)
With traditional RF transceivers, the wireless command was first sent over the
powerline before XTension could see it. That means that if you had a Lamp etc
that had the same House/Unit code address of the wireless command, the Lamp
would respond directly to the command.
With the MR26 direct-to-XTension technique, the command is not seen by the Lamp.
If you want the lamp to come on automatically, as with the old RF transceivers,
all you have to do is check the Pass-Thru box in the dialog above.
IF you choose to make the decision yourself, and you must use the same address for both the wireless
command and the Unit being controlled, you must remember that
whenever you stimulate a database Unit that has scripts, those
scripts WILL be executed.
SO, just remember that in such a 'same-address' case, you must
prevent the script from calling itself,
with the use of the 'with no script' phrase:
IE: ON script for Lamp (and the wireless Command):
if wireless then|
turn on "Lamp" with no script
The 'wireless' and 'command' variables
XTension offers two new variables that help you determine whether
a command came in from the MR26, and what that command was.
XTension responds to all of the standard X-10 commands that can be sent from a wireless remote or sensors.
ON -- OFF -- DIM -- BRI
( All Lights ON -- All Units Off are covered by the DOall.x scripts )
In your Unit Scripts, you may use the 'wireless' variable to
determine whether the command came in from the MR26.
But maybe you issued a 'DIM' or 'BRI' command, and want to
reflect that same command to the powerline to the same address:
For this, you want to know exactly which command was sent.
You need the 'command' variable for this.
The 4 different commands have codes representing them, and
at entry to your Unit script, the 'command' variable will be set
to the integer value of the command.
So here's an example:
RF range considerations
This is probably going to be the most bothersome thing about this new device.
Most of the RF remotes and sensors simply don't have the signal strength to push
a signal more than 30 feet, and some are limited to even about 15 feet.
In a small home, if the MR26 is located centrally, it may be sufficient to receive
signals from all of your sensors, and most of your wireless remotes.
But help is on the way! Many folks are working on improving the antenna of the
MR26, as well as methods of improving the signal strength of the remotes.
Update - You can construct a better antenna that will improve the reception
of the MR26, pushing the radius up to as much as 70 feet or more!
How to build a better Antenna
If you live in a small house or apartment, you're in luck if you can locate the MR26
in a place which is central to the home, or is within 30 feet or less of your sensors.
In the case of larger homes, and for wireless sensors that are farther from the MR26,
you may still have to use the old RF transceivers, but it may not be long before we
can come up with a solution that could involve multiple MR26's or the X-10 RF
This is probably the most exciting thing that has happened in the X-10 home automation
world in many years. It will take some time before we work out all the kinks, but the
potential for improving the response time and reliability of sensors, as well as reducing the cost
and 'ugly-ness' of all those RF transceivers, is well worth the bother.
No doubt there will be a lot of effort expended on this and XTension will certainly
be the first to follow these changes.
For now, you can certainly have even more fun with XTension ... !
How to build a better Antenna
Back to the Tutorials
Copyright 2008, Sand Hill Engineering All rights reserved.
Last modified: July 17, 2008
Michael Ferguson, firstname.lastname@example.org