What is the benefit of still using serial commands instead of an IP connection? The major brands like AMX, Crestron and RTI are still using serial commands for their communication interfaces. Even RTI’s new flagship XP8 has 8x serial ports but no working IP! Why is that?

The idea here is standardization and reliability.  Even though RS-232 is almost as old as I am, it is still the standard interface on almost all electronics.  RS-232 is fully standardized, no issue controlling a Panasonic TV and a Denon DVD player, where newer control schemes (like HDMI-CEC) are often incompatible between brands.  The interface is simple, standard ASCII codes sent, standard ASCII received.  A programmer with very basic skills can program “on/off”, “input 1” etc.  Really it just boils down to the fact that it works!  IP control is evolving, but for control only, you really do not need IP or a 10Gbps connection to send a power off command.

I agree with jnemesh - AV dealers want reliable system which will not require calls in the middle of the night/weekend from frustrated customers. Most AV manufacturers have implemented RS-232 into their equipment over the years and there is a clear standard which has been accepted.

Our company has been implementing IP control for over 2 years, the main reason to use IP Protocol is to get feedback from AV units we install. You can get feedback from RS-232 but it is slow compared to IP protocol. When you want to provide your customer with cover arts in color and other metadata - the best solution is IP Protocol. Obvioulsy you can mix both protocols in the same project.

I agree with both post. You have to look in the application in order to see what works better. If you just need on/off you should go with RS232.

Please forgive me in advance as I’m quite new to this business and the rookie label certainly applies. However, in my other line of work, RS-232 would be considered legacy technology. Especially when you consider today’s web-enabled devices.

People nowadays have a “need” to always be connected and the ability to talk to their devices through a wireless connection, be it within the home or half a world away, is the future. Actually, it’s already here. When you can stream your media to anyplace that has an internet connection, or view your IP cameras or turn on your coffee pot through your web-enabled cell phone, well…

I realize my comments are off topic given the question. However, I just couldn’t think of any benefits of RS-232 over IP.

I agree. IP is the advanced standard! But it sounds like everybody is right in this post! If you like to control AV equipment and just need on/off - play - stop ... then RS232 is very reliable and a accepted standard. If you want to control a system remotely or work with real-time applications then IP is the advanced standard. I think the industry will chance in the next years.

A big part of the RS232 vs. IP debate is cost.  Some people say everything should go IP.  Do you really want an IP address in every dimmer or occupancy sensor in the house?  I don’t think so.  If you have IP in everything the cost and complexity goes way up.  Now having an IP controller that can talk RS232 is what makes a lot of sense to me.  Right now IP control has no interface standards(I don’t consider completely different web pages a standard) so you still need a controller that ties multiple subsystems together in an efficient manner.  To me that is how you get the best of both worlds.

Just my two cents.

-Shane

I believe we are in a transition and have to support both approaches.  We all know the entire industry is moving towards more and more support for IP.  However, the reality is that much of the industry still hangs on to a lot of legacy technologies (not to get into a huge debate, but component video comes to mind).  What scares me is when system designers do not plan for the eventual influx of IP-based devices and potentially limit their customers’ options in the future.  At least put in the wiring infrastructure for it if possible.  Supporting IP-based devices usually requires a different cabling layout then one based on RS-232.

To wonder off topic a bit and look at it from more of a strategic perspective, there is a lot of activity in leveraging the Devices Profile for Web Services (DPWS) standards as the way for devices to communicate and that looks like the way things will go as of now for an IP-based ecosystem in the home.  Keep in mind, however, that IP does not mean Ethernet.  One of the things holding back devices based on low powered, low bandwidth, and lower cost communications infrastructures like 802.15.4 is that DPWS requires an IP stack, which RS-232 does not offer (nor will it in the foreseeable future).  In fact, the ZigBee standards do not either (although there are some gateways available to go between the ZigBee Automation Profiles and DPWS).  There is progress being made for IP over 802.15.4 and one or two vendors license their stacks to other manufacturers for this purpose, but no work is being done that I am aware of for IP over RS-232 (and thus DPWS over an RS-232 physical connection).

We also will have to start changing our way of thinking and designing monitoring and control systems a bit to support a standard like DPWS though.  In one regard, we can stick with some sort of controller for the house (usually a PC).  The way you discover and communicate with this new generation of devices will simplify installation and configuration tremendously.  Where you start getting into some really interesting problems is when you look at low-powered sensors that go into a sleep state and only are available occasionally.  For instance, take a smoke alarm.  Most of them go into a low-power state and wake up occasionally to update their status.  Now imagine that you want to query that device real-time.  Does a UI display the fact that it is not accessible when it is powered down, does it wait for it to wake up and take the time to re-establish a communications connection so it can get its status, or does it use a cached value stored somewhere that needs to be queried as if it were the device itself?  If it is a cached (or non-real time) value, where will that be stored and accessible at all times if there is no controller in the loop?  How will it be mapped back to the device itself as some sort of data proxy service?

Now let’s look at an even bigger issue that potentially uses the same set of protocols.  Suppose you install a completely IP-based distributed audio system that allows you to create “audio scenes” that dynamically remap sources to sets of speakers or rooms.  What happens when a speaker (technically the amp) is powered off or disconnected?  When it comes back on line and is rediscovered via the IP-based WS-Discovery protocols, is it viewed as a new device that has to be re authenticated, reconfigured, and remapped each time or will it be seen as the same “GUID” in the system (as a PnP-X device to the other devices or potentially to a centralized controller) and automatically be available for use?  Conceptually, the way you design a system for a door sensor, a smoke alarm, or an IP-based audio system is the same in the IP world, but it takes a whole new set of skills and product classes.

Why did I go to all of this trouble explaining this?  Mostly because of the initiatives by the energy companies to reduce consumption by integrating with things like thermostats and window treatments in the home.  You do not want to install two different platforms, one for your RS-232-based control system and one for their IP-based infrastructure.  I know of no utility company or manufacturer of devices playing in that arena that is using RS-232 and some proprietary communications protocol as part of its infrastructure.  The bottom line is to plan ahead.  What you put into place now needs to meet these types of demands over the next five or ten years as the marketplace moves to IP-based products using some sort of web services and SOAP-based interfaces.  You can use RS-232 if you must, but planning ahead and putting in an infrastructure to support the eventual use of IP-based devices is the only way to go.  Therefore, my recommendation is IP all of the way.

=D-

RTI’s new controllers are IP enabled.

If you have 25 networked devices to control (Crestron iDoc, Kaleidescape player, etc), do you want to wire up 25 RS-232 cables and take up 25 RS-232 ports on a processor? Or would you rather use the existing LAN connection on your processor and take advantage of the fact that your device is already on the LAN? No new wires to run, no additional ports needed, nearly limitless expandability.
If you are a Crestron programmer, its very easy to change the IP address of the controlled device, in fact this can even be done dynamically now. There is no need to get into the rack and move a serial cable, no need to change com port assignments in SIMPL Windows.

If you are an installer, you have one less cable to make and test and dress if the device is already networked.

I wont touch on all the other benefits of IP control already mentioned (speed, features, etc) IP control is more convenient and in my experience IP control is more reliable on some devices, assuming the network is well designed and maintained.

Some of my favorite IP controlled devices, VUDU, Kaleidescape, CEN IDOC, Escient FP1.
Devices I wish were IP controlled: Playstation3, UPB Lights, everything else.

Hey guys,

First post here for me…

I have to agree with both sides of this topic.  I think that RS232 control is and has been a solid format for reliable control in many industries.  The drawback, though, is the fact that our side of the industry is evolving so much that our control options need to follow suit, in my opinion.

I have worked with Crestron and Elan for quite a few years, along with CentraLite, Lite Touch, and most all the other large and moderate manufacturers in our market. 

I’m now a NetStreams Dealer, and couldn’t be happier with their performance and ease of installation.  Sure, they are slightly limited when compared to Crestron and tho others, but they don’t require tens of thousands of dollars in programming.  While the DigiLinX system does communicate through IP, they still have the same ability to control and communicate with other components via RS232. 

They have a new module that works with Vudu, which I’m surprised Casey didn’t mention.  I do second his comment about the PS3 and basically all other devices being IP controlled. 

Take a look at Proliphix thermostats.  Why would anyone use Aprilaire when you can use those?

I am an idustry cross-over.  I spent 10 years in IT and made the transition into CI about 6 years ago.  I was amazed when I had to make sure my new laptop had a serial port because MANY of the systems I want to program talk over RS-232.  Pretty crazy if you ask me, but I suppose the analogy of trying to turn a ship fits here.  Derek Flickinger (aka Dr. Flick) seems to be keeping up with the actual standards.  I’m curious if anyone else gets involved from the standards side?  Do we, as an industry, have any influence to steer the manufacturers?  What is the forum for that?  I’ll be attending my first Cedia this year, probably a good place to start looking.

I too vote for IP over RS-232.  As a side note, heck, USB over RS-232.  I’m just thinking of the remote programming that has to be done and comparing those that have serial vs USB - the serial programming lags.

Happy communicating!

-Morgan

Of course, we then open up a whole new can of worms if we look at the CEC command set over HDMI connections as the potential new preferred control protocol for A/V devices. It is a shame the majority of the vendors decided to implement proprietary vendor-specific extensions instead of using the globally-defined ones. It also is a shame most A/V and HDMI switcher vendors do not support controlling the devices over IP (or at least do not document the command sets for doing it). Just because these things can connect does not mean they have anything to say to each other once they are plugged in <g>.

=D-