The Marmitek AWM2 micro-module is the first to market of the new breed of modules supporting ACT's A10 (Advanced X10) protocol. The AWM2 is simply a 16A appliance module, but it has two switch inputs: the first controls the built-in appliance module, and the second is transmitted as X10 on the mains wiring. A10 adds an advanced addressing mode, but otherwise is identical to X10.
ACT's OEM A10 modules add significant extra functionality though, addressing some of the irritating shortfalls of X10, which after all is a 30 year old technology. A10 modules have been hotly anticipated for some time, and the AWM2 has an impressive list of drool-worthy characteristics.
First of all, it's small. Really small. You just won't believe how vastly, hugely, mind bogglingly small it is. It's 46x46x16mm. I told you it was small. I refer my learned readers to the photo of the AWM2 consorting with a humble steel back box. The back box shown is 35mm deep. The AWM2 will fit in single gang back boxes, behind the original plate. Admittedly, there's going to be a bit of a struggle if you've got lots of wire in there. The AWM2 will also crucially fit in ceiling roses, or if not, in a cavity in the ceiling which you can disguise with the ceiling rose. I imagine this will be most UKHAers' preferred configuration, as the AWM2 requires a neutral connection, which commonly isn't available at UK light switches.
Secondly, you can use whichever switches you damn well please. No more trudging through trade catalogues looking for acceptable momentary switches, no more agonising over the expensive and frankly brassy momentary switches over at letsautomate.com. No more SWMBO whinging that LW11 switches are ugly. And let's face it, in our hearts, we always knew that to be true. I'll reiterate the point just to ram it home: the AWM2 will work with your plain old common or garden light switches, which even the most techno phobic of luddites have learned not to fear.
Thirdly, the AWM2 is a two-way X10 module. This means that if you turn on the AWM2 using one of the attached switches, it sends that switch action as an X10 code. Further, it means that a suitably equipped X10 device can query the AWM2 for the state of its inputs, and get a response. The Hallelujah Chorus you can hear is that of long-suffering UKHAers up and down the country rejoicing that their prayers have been answered.
Fourthly, the AWM2 remembers the state of its relay after a power outage. So turn the light on, kill and re-apply the power, and the light is still on.
Fifthly, the AWM2 does not have those irritating X10 code wheels, nor does it have a fuse slot and demand to be fed obscure fuses every few weeks. (Hands up all of you with a big bag of 2 amp fuses stashed away somewhere!) It's responses to the X10 ALL UNITS OFF and ALL LIGHTS ON commands are also programmable.
Installing the AWM2 is a breeze. It has terminal clamps for load and phase, and two clamps for neutral. Three flying wires provide the connections for the two switches. The first switch (which operates the appliance module) is connected between the blue and brown wire, and the second switch between the red and blue wire. The AWM2 also has a recessed button for putting it into programming mode, and an LED that blinks reassuringly. The flying switch wires indicate that the AWM2 is really intended to live in a switch back box, an assumption borne out by the illustrations in the entirely adequate manual which accompanies it.
This means that if you're installing an AWM2 in a ceiling rose, you're going to need a few terminal blocks to make all the necessary connections. The flying wires themselves are rather thin single-core affairs, and will need careful treatment to avoid snapping them in a terminal block. I'd have preferred to see another three terminals on the AWM2 itself for these functions, rather than the wires. And while we're on the subject, the terminals that are there feel a bit flimsy themselves, being PCB mounted.
Once the AWM2 is successfully plumbed in with a switch across its switch inputs, a load across the relay outputs (the phase and load terminals) and a connection to the supply neutral, it can be put into programming mode by holding the recessed button for several seconds until the LED comes on solid. An X10 address can now be programmed into the AWM2 by using a separate X10 controller – no mean feat when you're up a ladder trying to watch the LED. The address is set by sending first the house/unit code, and then sending the house/ON code twice. The LED blinks twice to indicate success. While you're in programming mode, you can also enable or disable the unit's response to ALL LIGHTS ON and ALL UNITS OFF, both of which are disabled by default. Programming mode may then be exited by briefly pressing the programming button again, or just leaving the module for a minute with no X10 input, after which it times out and exits programming mode.
I found that I was unable to configure the AWM2 with an MC460 mini-controller, an MT10 minitimer, an SD533 sundowner, or the IR7243 IR<->X10 gateway, but it would respond quite happily to the TM12. A surprise success there for the frankly dreadful RF gateway! My failure with the other controllers may be down to my rush to get it all working or the usual X10 woes, I'm sure this will get some airing on the mailing list.
The address which is configured into the AWM2 is the address of its built-in appliance module. This is also the X10 code that is transmitted when input 1 changes state. The second switch automatically assumes the next X10 address from the programmed address
Permit me if you will to sidetrack here into a minor rant. In the bad old days of 70's vintage X10 modules, this "automatically use next address" behavior was tolerated because the address was input using cumbersome mechanical codewheels. With a device that is programmed through software, this approach is entirely unacceptable. I want X10 devices to be set up the way I want them – I do not want my X10 addressing scheme dictated to me by the module's design shortcomings.
Consider the following example. You have a hall and landing light, a dual switch plate at the top of the stairs and a dual switch plate at the bottom of the stairs. Switch A on either switch plate operates the landing light, switch B the hall light. You want to automate this arrangement with AWM2 modules. You can configure the hall AWM2 as unit code A1, with switch A on input 1 and switch B on input 2. You can configure the landing AWM2 as unit code A2, with the same switch arrangement. Now, switches A and B work as expected in the hall, as does switch A in the landing, but switch B on the landing does bugger all. Why? Because the landing AWM2 has automatically assigned address A3 to it, which is about as much use as tits on a boar.
About the only workaround I can see is to have some intelligence on the network which toggles A1 whenever it sees a change in A3. This is undesirable because it won't work if that intelligence fails or is out of action, and it uses up a unit code unnecessarily. Particularly so when you consider that most X10 controllers only let you access the first 8 unit codes for a given house code anyway.
I've emailed Marmitek with my concerns; I shall update this review if any reply is forthcoming. I don't see that it is particularly intellectually challenging or hard to engineer an approach whereby both addresses used by the AWM2 can be programmed independently. For example, you could send unit code, OFF, OFF to configure the second address.
Once configured, the AWM2 works like a charm. Toggling the switch switches the relay instantly, and the X10 message that accompanies it is sent immediately. Toggling the second switch also sends the appropriate X10 message out. If you're installing the AWM2 in a ceiling, chances are that you're not going to be using the second switch input. If this is the case, make sure it's well insulated and taped up out of the way – it doesn't take much to trigger it. I have a suspicion that my AWM2 is also randomly sending an X10 code at a completely unrelated address (the adjacent bedroom light now seems to have a mind of its own) but I am unable to verify this. The relay in the AWM2 module has a discernable click, but if like me you're an enthusiastic light switcher, this is masked by the switch noise. The sample period for a 'maintained' (ie regular, non-momentary) seems to be around 1 second: if you flick the light switch on and off in a Daley Thompson's Decathlon styley, the light changes state about once a second.
Thanks to recent changes in the Linux kernel, I'm unable to verify that the AWM2 responds to status or hail requests, but I hope to remedy this shortly.
Update! (24th April 2002)
Well, I've been beavering away to port my Linux tw7223 driver to version 2.4 kernels in order to test the two-way capabilities of the AWM2 module. The AWM2 does indeed respond to STATUS REQUEST messages, but only on the first configured address. That is to say, it will report the status of its built-in appliance relay, but not the current status of the second switch input, which is disappointing. I know that makes sense if switch 2 is a momentary type, but it would have been handy for latching switches, which are far more common.
Just to disappoint you further, the AWM2 doesn't seem to respond to HAIL REQUEST messages either, on either configured address. I'm 90% certain that I'm sending a correctly formatted HAIL REQUEST message, but it's difficult to be sure as I don't have any other devices which I know support it, and none of the Marmitek documentation I've seen even mentions this message.
The A10 protocol and ACT's OEM modules however do support HAIL REQUEST, but it's a configurable option in the same way as the module's response to ALL LIGHTS ON and ALL UNITS OFF. I'm guessing that Marmitek have chosen to disable this option by default, and there's no way to enable it using their programming interface, which is a shame.
For my next trick, I shall attempt to determine whether the AWM2 supports other A10 goodies like extended addressing – watch this space.
In summary then, the AWM2 addresses many shortcomings of existing X10 modules. For the UKHAer, it's small, and has two-way X10. For SWMBO, it takes acceptable, non-scary switches. On the downside, the terminals are flimsy, the addressing fiasco is frankly irritating, and it doesn't seem to like many controllers in programming mode. The AWM2 disappoints in it's two-way performance too – it's a shame that the X10 transmitter in the unit is limited to basically reporting the state of the internal relay, when we know that the module upon which it is based is capable of so much more. I can't help but feeling that OK, it's small, but it'd be cool if it were just that bit smaller. And finally, there's the expense: those benefits come at a fairly hefty premium. Having said that, it's still significantly cheaper and easier than the various hardwired lighting solutions that are out there, so you'll have to decide whether the added functionality over regular X10 devices justifies the price difference for you. Personally, I'll be ordering a few more of these babies come pay day.
Finally, rumors abound of the impending arrival of a replacement for the old light module, ie an AWM2-a-like with dimming functionality. Expect it to be larger, and to require the infamous momentary switches. Marmitek's website also shows two modules which are controllers only, ie they give existing switches the capability to send X10, without the built in appliance module, so I'm sure they will surface some time soon also.
Approximate Price £69.33
Available From Lets Automate