Is the URC MSC-400 controllable?

[Dean Roddey]

Is this device something that can be interfaced to with a control system to make it send out it's stored IR macros? And I guess another question just in case anyone knows, can it be configured to send out ASCII strings to a serial port or something like that, to be used as a trigger input for CQC? Presumably it can since it claims to be able to control serial devices, so it could be treated as a serial command to a device.

[paradise]

I just got one. From everything I've read it can send out ASCII strings, just like the rti rp-6. I don't think it can take a serial input though to send out its Ir macros.

Zack

[Dean Roddey]

See the changes I just made in the most recent beta. It will make using these types of serial text sending IR trigger devices to trigger CQC much more flexible, if you are going to use it in that way.

[paradise]

Well now I'm glad I hadn't started working on this yet. That should make life much easier.

Thanks Dean

[paradise]

What is the fastest way to have CQC respond to serial data?

For instance, would it be faster to have one triggered action for Living room and then have if/else statements in there for all the cable box, receiver and TV commands, or one triggered action for each device, or one triggered action for each command? What's the best practice for this usage scenario?

Hope that makes sense...

[Dean Roddey]

For ones that aren't run often, it doesn't much matter. So for something like system on, system of, select what 'activity' you want to do (watch tv, listen to music, etc...), those things aren't run often enough that performance is an issue, so do them the most convenient way for your needs. These can just do If/Else type decisions and decide what to do.

For other stuff, it's tougher because you have to have some way of looking at the incoming generic parameter value and converting that to a field and value to write, and there could be lots of variations. You could get pretty slick there as well, but you'd be getting into fairly advanced stuff, probably used enumerated global variables as maps.

So it might be best to have per-device actions to invoke, where you pass in a generic command that it turns into a field write. Or, where there are a lot of them, where maybe even you just pass in the field name and value to write.

\Source\Transport\CableBox#Power Off

So you'd get "Power Off" and would break those into two values and the first would be the field and the rest would be the value to write to the field. You could get it down to that level for some devices that have a lot of IR'ish type of commands that just send out a value. You could do the same of course for an actual IR device blaster instead of the scheme I indicated above. Those types of commands would effectively be few lines, to break the value into the parts and then a command where you use the stored broken apart values to do a field write. Or even a more generic one that takes moniker, field, and value that you could use for any sort of 'just want to invoke a field write' type of actions.

For IR type devices just pass in the IR command name. So if the cable box in the above example was an IR based device, Power Off might be the IR device command, and you'd just take it as is and the action would be something like:

Devices::FieldWrite(MyIRBlaster, TheIRDevModel.%(LVar:CQC_ActParm1))

If you have more than one device of a given type, just have the monikers be such that they have a 1, 2, 3 or some other suffix on them, then pass in the suffix like:

\Source\Transport\CableBox#BR1 Power Off

Break the parts out, and append the first bit to the moniker to get the right device.


Anyhoo, those types of strategies could make it pretty low calory, though at the cost of less abstraction of course. I.e. you'd have to go back to the MSC and change commands if you changed devices under control.