roZetta protocols

roZetta will understand the protocols for...

TW523/PL513 CM11A 2414S UPB PIM CPU-XA/Ocelot/Leopard MR26A

roZetta will emulate a TW523 for any controller (e.g. Ocelot, JDS Stargate, HomeVision, Omni) that expects a TW523 attached to its PLC port and can output PLC codes using any of the above listed devices (MR26A excepted). I've designed a generic DIY project board that fits a standard Polycase LP11(F) 2.5x2.5x1" enclosure that can be used to build RF receiver modules for anything using ASK modulation and either 310, 315, 418, or 433.92MHz (for which Mouser sells $5 receiver modules). I will create firmware for an

8-pin PIC to decode the RF and output the codes via RS232. These will have to be "home-built" although I'm willing to discuss supplying them assembled for anyone willing to pay for FCC testing ($5K and up).

I've already committed to try to support the Oregon Scientific (and Radio Shack) wireless weather transmitters. (Actually, roZetta might also interface with their serial devices.)

I know the protocol for Crestron RF but wonder whether it's worthwhile to support it since they appear to be moving to Zigbee. I also understand Lutron's RadioRA protocol but am not sure it lends itself to this application - their codes are ridiculously long which would require extra memory in any receiver.

I'm willing to entertain suggestions but will not actually start working on any suggestions until after I've released the first version of the firmware.

roZetta will be field upgradable so the fact that early firmware will not support these other devices is not an issue.

Some of the wireless protocols will not require much in the way of roZetta resources. The RF receiver will output a hex string and the user can specify a response. roZetta will not need to "understand" the underlying protocol and no handshaking is needed so roZetta will be able to support lots of these device types.

Others (e.g. Oregon Scientific weather devices) will be inputting variable data and roZetta will need some level of "understanding" to deal with the data. I might be able to generalize the approach I took with variable sensors in the BX24-AHT but these types of devices will always require more resources so only those with wide appeal and for which the protocol is available will be supported.

Reply to
Dave Houston
Loading thread data ...

I do not support illegal devices.

Reply to
Dave Houston

A few obvious candidates:

Weeder Technologies multidrop RS232 devices Peter Anderson's 1-wire serial interface Midon Design's TEMP08

I have a 2-3 of the Weeder modules so will try them after I get the previously scheduled things out of the way. Multiple Weeder modules can be on one roZetta serial port as long as the data flow doesn't become a flood.

Prof. Anderson has several variations of DIO, ADC, 1-wire, etc. I don't want to get into anything that involves calculations beyond very simple things so I'm not sure which one, if any, to support.

I'll have to look deeper at the Mid>roZetta will understand the protocols for...

Reply to
Dave Houston

How is this an illegal device?

formatting link
It's what I currently use to get RF into my MisterHouse and it works very well for receiving both Hawkeye motion sensor and X-10 RF signals.

-- Scott Knight

Reply to
Scott Knight

The rf transceiver distributed in defiance of FCC rules. It's illegal to sell in the US. I will *NEVER* support it.

S>I don't understand, which illegal devices. This is the rf tranceiver

Reply to
Dave Houston

FCC Part 15 rules require that such devices undergo FCC specified tests in an FCC accredited laboratory *before* they can be sold in the US. Industry Canada (FCC counterpart in Canada) has similar rules. The testing can cost $5K and up per model. Some companies try to gain a competitive advantage by deliberately ignoring the testing requirements.

Such devices must either have an FCC ID or have a Statement of Compliance on the device itself and both require the tests. If you look at RF devices from legitimate companies you will find they have one or the other. For instance, the MR26A bears the FCC logo and the statement "Tested To Comply with FCC Standards" and the CM17A bears "FCC ID: B4SCM17A". The difference is that transmitters and certain types of receivers must have the test data submitted to the FCC who then issues the FCC ID while other receivers merely require that the testing be done and that the test data (from an FCC accredited lab) be on file before the device can be sold.

The FCC rules allow an exemption from testing for DIY "home built" devices.

If you would like to read the FCC Part 15 rules for yourself the latest versi>How is this an illegal device?

Reply to
Dave Houston

on 2/4/2006 3:15 PM Dave Houston carved the following into a picnic table:

Ah, now that I have Google'd around a bit, I can see your beef. My only comment is that it's not easy getting to your 'official' BX24-AHT project data, if any such thing even exists. I am following a painful trail of outdated links. Where is the current project (besides what I read on this newsgroup)?

Thanks for the clarification.

-- Scott Knight

Reply to
Scott Knight

Jeff Volp has posted here a couple of times in the past week or two with a URL for the last of the BX24-AHT boards. Last I heard he was down to a dozen. I'll let you search for his post.

I'm no longer actively supporting the BX24-AHT but all the documentation, including the BasicX source is available at...

formatting link
After I get roZetta released and after I port the BX24-AHT code to the ZX-24 chip, I will try to update the BX-24 versi>on 2/4/2006 3:15 PM Dave Houston carved the following into a picnic table:

Reply to
Dave Houston

Wow! Quite a list!

How's it handle the MR26A signals?

If you needed a Lutron device I'd be willing to lend you one for a short while.

How do you see the various PC apps dealing with this device? What will their drivers need to change in order to work with it?

-Bill Kearney

Reply to
Bill Kearney

Since the MR26A is only one-way you can't send to it, you can only receive. All the other supported devices send and receive.

Users will be able to select a default action for messages received from any port. The most likely action with the MR26A will be to send a PLC command using one of the supported PLC interfaces.

In the configuration, users will define the default action. They can then define other actions for specific messages received.

Example:

MR26A on S1 (serial port #1) TW523 on T1 (TTL port #1) S1 default -> T1 (when no specific action is defined send X-10 with TW523)

The MR26A messages will look like "D5 AA B0 30 AD". If no specific action is defined, the TW523 will send "H3, H On".

Or you can define a specific response such as "no action" or send a message or command via one of the other ports and interfaces. So, you could use an X-10 RF remote to input codes that, in turn, trigger UPB or 2414S commands.

And you can choose to copy all or part of the activity to the PC (or Ethernet) port. But, the more things are defined, the more memory is used.

They use very long RF codes so I'd either need a different PIC in the receiver or would need to add a long-lived EEPROM. Either way it would be more complicated than the other RF codes I anticipate handling which can be handled by a PIC12F629. IOW, it's going to be very low priority.

Does Lutron have a serial device that can send/receive RadioRA? It would be simple to interface with that (assuming the protocol is available). Crestron has serial gateways.

That really depends on the software and on the user. You could program roZetta to send messages to the PC that would appear to be coming from the device itself so roZetta would be transparent. However, if the software expects specific responses to the messages it sends, roZetta will not handle that. And since roZetta will be handling messages from multiple ports it needs to keep the main PC port at a higher speed than used by most devices. I think what I'm saying is that I'm not going to concern myself with how PC software interfaces with roZetta. I'll publish the details and let software developers worry about it. I'll provide Windows interface software. I may write something using REALbasic and see if I can find someone to compile it for Linux and Mac. Neil Cherry has volunteered to be a guinea pig (umh, make that "beta tester") and I'll probably send him one of the prototypes.

One thing which *may* be possible is to configure one of the serial ports as a "passthrough" and route all traffic to/from another port through it unaltered. It would require a null adapter on the passthrough port and it might add too much of a delay for handshaking messages. In cases where it does work, the software would be unaware of roZetta and think it's talking to the device directly. This is on my list of things to test.

Reply to
Dave Houston

Does anyone have the interface spec's for the Lutron devices?

Reply to
Neil Cherry

They have documentation for all of their IR protocols on their website. I don't recall the URL but I posted it here a year (or more) back.

I do not recall whether they have a serial gateway so obviously haven't seen (or looked) for any documentation on such a device.

Reply to
Dave Houston

They have three interfaces - a telephone interface, a network (i.e. Ethernet) interface and a "Multi-Function Entry Master Control".

There are specs and app notes on their website.

It might be possible for roZetta to interface with one of these but I haven't looked at it in depth and will not do so until much further down the road.

I really haven't explored how roZetta will make use of the xPort. Beyond knowing that it will allow transparent control via TCP/IP I haven't determined what specific things it will allow (e.g. email alerts).

Reply to
Dave Houston

I forgat about their "Chronos System Bridge and Timeclock" which provides an RS232 iinterface, The protocol is published on their website.

Reply to
Dave Houston

The Lutron RS232 interface uses an ASCII protocol so users can interface to it without roZetta needing any knowledge of the protocol.

I like the easy ones. ;)

Reply to
Dave Houston

I should clarify.

roZetta will only support a fairly simple subset of commands for most interfaces. It will not setup scenes, etc.

For UPB and the 2414S it will be able to turn devices on/off and set the level.

For the ADI devices, it will use the binary protocol for X-10. Users can use the ASCII protocol to control other things.

For the CM11A it will send receive all X-10 commands but will not handle CM11A EEPROM related things.

For ASCII protocols it will send whatever the user specifies and will report ASCII codes received.

It will not report binary codes received from devices which are not specifically supported but will present them as hex strings for devices which have native support (e.g. MR26A).

Reply to
Dave Houston

IIRC, their website does have the serial port protocols.

Reply to
Bill Kearney

Ah, that makes sense.

Yes, they do make a RadioRA serial gateway. I have one already.

Best of luck with getting it all working!

-Bill Kearney

Reply to
Bill Kearney

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.