X10 and Linux

I hope to be releasing roZetta in the next 2-4 weeks. I think all of the problems have finally been resolved with the latest (actually I'm testing the pre-release version) of ZBasic and the ZX-40a VM although I'm still rewriting code and testing things. I'm working with Neil so he can provide a Linux interface. He's working on routines for downloading the VM and compiled ZBasic application to the ZX-40a.

It looks like it will simultaneously support...

The high-speed serial port can optionally be replaced (jumper select) with a Tibbo EM202 and communicate via TCP/IP with a virtual ethernet-serial comm port on the PC end. Linux drivers are available from Tibbo.

It will store events and macros, has a software RTC with an optional, plug-in battery-backed RTC or can sync to a connected PC. It calculates sunrise/sunset, handles DST and stores a user created list of holidays. Macros can be modified by day-of-week, holidays and certain time-of-day periods.

Everything about it is user programmable so you can make it do all that you've listed. If you don't like what it does, both ZBasic and Tibbo Basic (EM202) are free downloads so you can make it do something else. While I did not anticipate anyone might want to control everything full-time from a PC, it is possible to send commands to any of the ports from a PC and all inputs from all ports are reported to the PC. (You may have to control command pacing - most commands are ACKed only after execution but I haven't really planned on full-time PC control.) I will publish the communications protocol as well as the EEPROM storage schema.

Translating between multiple protocols is not trivial but I've tried hard to keep roZetta KISS-able (and she is dressed in red). The user programming is fairly simple and straightforward, organized by port. Users can determine how much EEPROM to allocate for each port so unused ports do not waste EEPROM. It takes 15 bytes to translate an X-10 extended dim code into a UPB or Insteon code. I expect between 16KB and 40KB (with the larger EEPROM) will be available for macros and scheduled events but adding features may cut into that.

The X-10 TTL ports can interface with a PL513, TW523, XTB-II or legacy controllers (with or without opto-coupling). A PL513 or TW523 (or equivalent) is required to supply ZC if a legacy controller is used. ZBasic couldn't come up with a way to generate ZC internally with sufficient accuracy.

The serial ports support MR26, CM11A, ADI, 1132B, 2414S (both protocols), UPB PIM, ASCII devices and several players to be named later.

The initial units will have a 32KB EEPROM which contains both the application firmware and user data. 64KB EEPROMs will be available in a few months and subsequent units will use them. Users can upgrade by replacing the EEPROM chip (requires soldering SO-8 surface mount chip).

If the internal RF receiver is used, it reports all known X-10 RF - standard X-10, security X-10, Digimax 210, Nola, Ninja/Robocam, AUX RF codes on most X-10 universal remotes, MouseRemote, etc. I captured Ninja codes a few years back - they are documented on my website. I've decoded all the others but have not published the results. roZetta will also report codes from the Chamberlain garage door sensors.

You could use any of the 8 ADC/DIO pins to send a baseband pulsetrain to an RF transmitter of your choice. It could be used for Ninja/Robocam or for any ceiling fan for which you can find the appropriate transmitter. I've also decoded many of those. I have a proprietary compression algorithm that will allow storing arbitrary codes in EEPROM (64KB version only) without taking up a lot of memory. I have a web page listing ceiling fan frequencies and RF transmitter/receiver sources.

A bare board (with all SMD, switches and headers pre-installed but without the through-hole connectors, sockets, etc) will cost under $30. It can be fully assembled (less ZX-40a, EM202, RF receiver) for under $80 (less if you do the assembly). Users will need to buy the ZX-40a ($40), optional EM202 ($63) and optional RF receiver ($5).

Once I'm sure I've survived the development of roZetta, there are about a dozen related PIC-based DIY projects I'll try to finalize. One is a daughterboard that replaces the CM15A processor, turning it into a serial device with full access to all of its features. Others are DIY RF receiver modules that will report signals from other security switches, etc. They will be RS232/RS485.

I will try to update the roZetta link on my website as things progress.

In general, I don't help people who are using illegal devices like the receiver you are using.

Since you are using Linux and only want to send RF, look at some of the simple IR hardware suggested for use on a serial port with LIRC. You can toggle one of the handshaking lines fast enough, enabling you to send a baseband signal to an RF transmitter (such as the daughterboard in any of the X-10 universal remotes except Lola & RemoteWonder which use 418MHz). I'll leave the rest to you since, to be legal, this needs to be "home built".

You could even send the IR signal since neither the transmitter nor the receiver will be able to switch at the carrier frequency. The end result will be the same as if you sent baseband.

As I noted earlier, the Ninja codes are documented on my web page. There is also a link to X-10's documentation for the CM17A which lists ~99.44% of the standard RF codes.

Once I get roZetta finished and an online store set up, I have about 75

I was just wondering how you get PLC status reports from 2-way modules without sending PLC status requests? AFAIK the V572AB has no capability for doing that.

In any case, Heyu

But the CM17A cannot send the Ninja and other non-standard RF codes he wants to send.

This is true, but he knows that. The CM11A/CM17A would just be a stopgap until he's got a working CM15A or CM19A system. He doesn't have a Ninja yet anyway.

Regards, Charles Sullivan

But a $5 transmitter (or one salvaged from a universal remote) on a serial port can send any code.

OK, time for me to jump back in. This is one reason roZetta would not be a good choice for me. No time to get my hands that dirty. And I am not a coder, at all. A $5 transmitter and all the code frequency documentation in the world does me no good if I can't write the software to utilize the two together.

The current CM19A Linux kernel driver allows one to send commands by echoing "plain english" to the post that the device occupies. "echo +a1 >

/dev/cm19a0" turns on A1. "echo ba1 > /dev/cm19a0" brightens A1 by one increment.

I'd like a daemon that can read what the CM19A is receiving so I can use the extended remote codes provided by remotes like the Lola to set up "special circumstances" without wasting house/unit codes.

I think Heyu or MrHouse may be overkill for my needs. If I can get RF receive to work I can do everything I need with bash and cron using lock files to arrange special settings. Eg. Push the "ARTIST" button on a Lola remote and have the daemon reading the receive values write out a file called /temp/quiet.x10.lock that would have my door motion sensors turn on the light when someone came up on the porch but NOT ring the doorbell.

For now, I can do this with the CM11A/CM17A combo by wasting house/unit codes to set up the special situations assuming there is something that can read the input from the CM11A and spit out the values to me in a readable form. Actually, I could do it with my CM19A and CM11A, if the CM17A can't receive then I may as well use the CM19A that receives but doesn't give me useful output.

Charles, I hadn't thought about having to send the status request via PLC from the device wanting the status report. I may have to reevaluate that requirement as I really only want ONE PLC transmitter injecting signals onto the line. I got the 572 for that reason. It is installed directly at my main panel. When I add to my system so that overall wire lengths increase I can add an XTB to the output of the PSC05. I had thought about going with a W800RF32 but I wanted to inject the signal AT the main box to avoid having to track down weak signal problems in both directions to find the "leak". I know my signal starts at the same strength on both legs at the "head" of the system.

Dave, I hadn't read your argument against the 572 before I bought it but, honestly, it wouldn't have changed my mind. It's a rule that the FCC chooses not to enforce, probably for the same reason that it would have made no difference to me. That FCC ruling for RECEIVERS is a bit idiotic. For transmitters it is a definite necessity but any idiot can still buy an FM transmitter in kit form for under $10 and wreak havoc with nearby receivers if the ham-handed "hobbyist" scratches the coil during assembly and detunes it. WGL should probably sell the 572 with the actual receiver parts in a baggie and just the interface parts that connect/communicate to the PSC05 assembled to be within the letter of the law, but they;ll take the bite for that if the FCC gets picky, not me.

When the roZetta is ready I may buy one for the parts box so I'll have it available when I have time to look into more dedicated control -- or when someone writes software/drivers to operate its outputs from a PC running Linux but from what I read it may NEVER be "what I want". I'll have to read your documentation more thoroughly.

I have extra PCs coming out my ears. I want 100% PC control. When I get something working the way I want on my Linux desktop play box I'll copy it all over to a dedicated server and stick it in my rack as a headless unit. But I always want to be able to make on-the-fly changes without having to reprogram an EEPROM and also want to be able to write a web front end to feed controls for remote access. I don't like the X10 cameras so I plan to buy better 12V or 24V cams and address them with UM506 modules but still mount them on Ninjas. Or possibly leave them hot all the time and use an X10 compatible relay board to switch the signal rather than switching power (have to see how much degradation is introduced by putting a relay inline with signal first).

Gerald

The FCC budget has been cut so much that most enforcement of technical rules has gone by the wayside although enforcement of non-technical rules (e.g. indecency fines) has quickened apace.

As currently constituted the FCC's only mission appears to be to keep the entire telecommunications industry "in play" so the investment bankers can make billion dollar deals and the politicians can extort campaign contributions. The enforement of technical rules has a low priority.

The receiver rules are less stringent and are far from idiotic. Many of the small receivers used in these low power RKE and similar applications are superregenerative types which can emit a lot of radiation. Very low levels can still interfere with rather important things like aircraft navigation.

If the FCC is not going to enforce the rules they should be repealed so that those who deliberately choose to ignore the rules do not gain a competitive advantage over those who try to follow the rules.

You mean there's salvage value to the X-10 remotes I've warn the lettering off of? X-10, it never stops giving!

-- Bobby G.

The Bush administration government has its priorities. :^)

Might also be press coverage... Remember Janet Jackson?

Who cares if some HA vender is fined for a radiating receiver.

Jeff

Exactly! They pander to the far right, religious ultra-conservatives, most of whom presumably don't even watch the superbowl (too busy picketing the local family planning agency).

BTW, speaking of Janet Jackson, I can't imagine how anyone could believe that exposing her bosom was worth $250,000. She's about as attractive as Monica Lewinsky and no one in his right mind would be attrac... errrm, never mind. :^)

There's a book I recently read about how the Republican party has dealt with science and the relationships of government agencies to science and scientists. The book is clearly biased (in favor of science) but it's an interesting read. "The Republican War on Science". Those among us with an interest in science and its relationship to government agencies such as the EPA might enjoy it.

The government is hard up for money. One $250,000 fine to CBS brings in a lot more than scouring the countryside for illegal low-power transmitters and receivers. It's just a matter of most bang for the buck.

-- Bobby G.

They don't need to scour the countryside or even measure the emissions. They only have to ask the manufacture to provide proof that the devices were tested by an FCC certified lab prior to being marketed. If they were to levy the maximum penalties (millions per day, per device with geometric growth), it would clear the national debt although it's unlikely they could ever collect.

Anyway, you can see much bigger boobs exposed at any meeting of the FCC commissioners. Last week they recused a commissioner from his earlier recusal for conflict of interest so he can vote on a proposal that will allow further media concentration (and fees and contributions). It's no wonder the mafia has fallen on hard times - honest crooks can't compete with rackets like these. ;)

Try "cat /dev/cm19a0"

and if that works you can use: "cat /dev/cm19a0 | your_program"

With x10-cm19a-0.0.5 this works with standard X10 RF and a few but not all of the Ninja RF codes. Maybe there's a later version which is better and does Lola as well.

I had hacked one of the earlier releases of this driver to receive and transmit the raw RF bytes. (This is the way I think a driver ought to work instead of limited to built-in translations for specific remotes.)

I was able to receive all the Standard X10 and Ninja codes. I could could transmit all the Standard X10 codes by feeding back what I had received but this didn't work for transmitting the Ninja codes - at least my Ninja didn't respond. I didn't have a second CM19A to monitor what was being sent (if anything).

Maybe, but Heyu is self contained and you should be able to download and install it in less than 10 minutes if you read the "INSTALL" file in the tarball. Run 'heyu monitor' in a terminal window and you'll see all the PLC traffic on your power lines in clear text.

As mentioned, Heyu doesn't yet receive RF. But with an X10 HR12A remote and the PLC from your V572 these lines in your Heyu configuration file would do the above job after you run 'heyu engine':

ALIAS lockit_command A1 REMOTE2 ALIAS motion_detector B1 REMOTE2 ALIAS porch_light C1 WS467

SCRIPT lockit_command on :: heyu setflag 1 SCRIPT lockit_command off :: heyu clrflag 1 SCRIPT motion_detector on flag1 :: heyu on porch_light

With a CM17A Firecracker the last command could be replaced by 'heyu fon porch_light' to have the V572 send the PLC.

I think you're a little too concerned about having only one PLC transmitter, but if that's to be the case, the V572 is not the right choice for it. If nothing else you're limited to On, Off, Dim, Bright, AllLightsOn, AllUnitsOff commands. (And the Dim and Bright don't send repeatable PLC for the same RF received unless WGL has fixed something since the one I tested.)

Regards, Charles Sullivan

Where does one get this driver?

That's Michael LeMay's X10MMMS CM19A driver.

Thanks I'll get that link posted to my site so other can find it.