Re: roZetta protocols

[nobody@xxxxxxxxxxxx (Dave Houston)]

"Bill Kearney" <wkearney99@xxxxxxxxxxx> wrote:

>How's it handle the MR26A signals?

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.

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

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.

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

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.