There is a time and a season for everything, and indeed, even in a two-way system there is a time to "speak" and a time to refrain from "speaking". So the focus of the issue before us is whether a system can support two-way communication and not when and how this capability is used.

There is only ONE way and it's Two way

Brian Baker

plugplay.jpg (12749 bytes)
Brian Baker

There is a time and a season for everything, and indeed, even in a two-way system there is a time to "speak" and a time to refrain from "speaking". So the focus of the issue before us is whether a system can support two-way communication and not when and how this capability is used.

brian.jpg (28545 bytes)

I remember a time in my youth growing up in a small town in Pennsylvania when my paths crossed with a group of people the news media of that time period had dubbed as "Jesus Freaks". Their message to society was simple - that Jesus was the only way to heaven! One thing in particular that stands out in my memory of my encounter with these people was seeing the poster and banners that made up their arsenal for evangelism; some of which simply stated their message in two words: "ONE WAY". My message to you is on a more temporal level and I could only hope to match their zeal in getting my point across - that there is likewise one way to true interoperability amongst products within our homes and that is through two-way communications. Our industry seems to still be debating this issue, though there are positive signs that we too are becoming enlightened. Some developers and users in the X10 community have taken up their banners and begun to influence the industry toward using two-way communication. This is encouraging since X10 products of the past tended to be classic examples of products developed under a one-way communication mindset.

To be able to make a proper judgement on this issue we need to put everything out on the table in front of us. We will start by discussing one-way communication and then approach two-way communication as a superset of one-way. This article represents a good example of one-way communication in that I have presented my thoughts and opinions in this document and you are now reading them. I am the source of this message and you are the intended destination. One of the issues in network communications is "knowing your source". Computer networks used in many offices depend on some type of user-name or password-based mechanism to establish the authenticity of network traffic. Since most of you have never met me, you will have to make a judgment based on the message content. What you do as a result of your judgment determines whether this is a monologue or a dialog; whether this is one-way communication or two-way.

Products developed according to a model stemming from the one-way side of this issue can be divided up into two main groups: (1) the send only camp and (2) the receive-only camp. Those products utilizing receive-only technology for home control were developed under the presumption that these products would only be used in applications where there would be no benefit in being able to provide feedback to the sender or that the system could tolerate a certain level of indeterminate behavior. Products from the other camp (send-only) suggest that their messages are either unimportant or that they presume that they are always heard. Either they couldn't care less about whether their message was received or they simply don't have the resources to deal with any negative feedback.

There is a time and a season for everything, and indeed, even in a two-way system there is a time to "speak" and a time to refrain from "speaking". So the focus of the issue before us is whether a system can support two-way communication and not when and how this capability is used.

While this article could represent a form of one-way communication, the "system" that has been established by the internet community can support two-way communication. One of the high-level services in this system is the capability of each of us to send e-mail. With regard to this article, you may elect to represent the receive-only camp on the one-way side of the issue, depending on whether or not you elect to provide any feedback. Some percentage of the readers of this article never got passed the first paragraph. Others of you may read it in its entirety and utilize the hyperlink at the end of the article to reply with a response. The point is that the system provides the full capability of feedback. This provides you with a means to influence the system.

Now that we have established what two camps comprise the members of the one-way community, we have inevitably exposed the shortcomings of one-way communication as a model for interoperating. The division represented by these two camps does not promote inteoperation between devices. Products from either camp were developed with a focus on their local operating requirements and not on the system in which they will be placed. Certainly the user believes that these products have something to contribute to his system or he would not have purchased the device to begin with. The problem is that each user must design a system gadget by gadget and work around the idiosyncrasies of each device. This can be difficult and extremely time consuming.

Electing to use two-way communication in the system only drives the first spike in the development of a working interoperability model. A high-level communication protocol is necessary that dictates rules and establishes proper procedure for two-way communication within your system. One of the standards that have begun taking hold within this industry is the Common Application Language (CAL) defined by the Electronics Industry Association. CAL was developed for two-way communications. This fact does not preclude its use by one-way devices. However, one-way applications of CAL are unable to use one of the most valuable facets of the language - feedback. The response mechanism defined as part of CAL provides a means for recipients of network traffic to inform the sender that the message was successfully interpreted. The capability of returning a simple "OK" response to the message sender opens the door for a much higher level of reliability in product interoperation. Without this mechanism, attempts to achieve high-level communication reliability usually revolve around automatic resending of the message (multiple repeats). Such automatic repetition consumes network bandwidth; which is one commodity that seems to increase in value on almost a daily basis. As home networks using the power line for a communications medium continue to proliferate, bandwidth efficiency will become even more of an issue.

Developers of receive-only and/or transmit-only devices will argue that these devices have a proper place in the home networks of the present and those of the future. I agree that there are some special cases where this is true. However, I believe these cases must be recognized as the exception and not the rule. The user who purchases one-way products as a general solution for home automation introduces an element of risk to the stability of his home-network system. Receive-only products have the real potential of reacting to communications within the system in a manner that is not expected nor understood by the user. The system itself cannot be sure if such devices exist and must tiptoe around these phantoms at all times to be sure that they are not disturbed. As the system grows and matures, there is no guarantee that at some point general system communications won't step on a sensitive area of a receive-only device causing it to yell "ouch". When that happens, the burden will generally fall on the user to try and figure out what just happened. If these disturbing events are intermittent, the user will begin to suspect that the system as a whole is failing or is in some way at fault. Likewise, transmit-only devices introduce a similar risk to the system. However, their impact is opposite that of the receive-only products. They may cause the system itself to say "ouch" or possibly cause it to stumble intermittently. These transmit-only devices cannot be commanded to "shut up" for a period while the system is performing maintenance procedures or other special operations.

I mentioned in a previous article that it is my conviction that this industry needs to mature from out of the "mix and match" mentality where gadgets reign supreme to a higher level of interoperability where well-engineered data models are the driving force behind system design. If you too want to advance into the arena of more reliable home automation and control, then I encourage you to invest some time in finding out about some of the advancements in the industry. Some of them have the potential to liberate system integrators from the bondage of gadget chaos to a promise land of true "plug and play" technology. Contact me ( the staff at SMART to obtain information about a new data model we have developed for the home networks system that we believe will help advance the industry in the right direction.

Comments (0)

This post does not have any comments. Be the first to leave a comment below.

Post A Comment

You must be logged in before you can post a comment. Login now.

Featured Product

MIDLITE® - Power Jumper IC™ HDTV & Sound Bar Power Relocation Kit with Interconnect

MIDLITE® - Power Jumper IC™ HDTV & Sound Bar Power Relocation Kit with Interconnect

The Power Jumper IC™ HDTV & Sound Bar Power Relocation Kit easily conceals power & A/V cables within the wall for a professional appearance. The kit is recessed and features a new low profile in-wall jumper that can be fed through 1" diameter holes. The metal strain relief bracket provides a solid connection for the interconnect. The kit comes prewired and does not require an electrician for installation. The Power Jumper IC™ is available in three options, HDTV, Sound Bar and HDTV & Sound Bar.