roZetta protocols

I do not support illegal devices.

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...

How is this an illegal device?

-- 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

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?

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

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...

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

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.

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

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.

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).

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

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. ;)

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).

IIRC, their website does have the serial port protocols.

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