Universal Devices ISY-994i Series, Руководство пользователя

Страница: 363 / 692

Page | 340
'extended messages' - this makes Insteon suitable for high-security applications such as
door locks or security systems.
So, when you link devices you create the controller link in the controller link table and then
you go to the responder and create the responder link to complete the linkage. I should
mention that one of the benefits of ISY is that it takes care of creating both sides of the link
for you - the controller record in the controller and the responder record in the responder.
The responder link table looks a little different than the controller link table. It keeps the
address of the device that will control it, the group of the device on the controller that will
control it, the button on itself that will be controlled, the ramp rate for it to respond and the
dim level for it to respond to. So... when a responder sees a group command arrive with its
address as the destination it looks in its responder table for a record that matches the
controlling address and controlling group and if they match it reacts by doing what it's
supposed to do in that record according to the group command it receives.
So how does it react to these commands?
When a responder receives a fast OFF - it turns completely off instantly. When it receives a
fast ON - it turns completely on to full brightness instantly. Off will turn the device off but
will do so at the ramp rate specified in the responder table for that command. On will turn
the device on - again at the ramp rate specified but will turn it on to the level specified in
the dim level setting in the responder table. What's important here is that the controller is
only sending on, fast on, off, fast off. The 'scene' type settings - the dim level and ramp rate -
are stored in the responder table for the matching group command.
The next important thing to understand is how Insteon sends it's commands through the
network. Insteon doesn't do what X-10 did - flooding the powerline with a varying, time
sensitive voltage signal. Insteon controllers send their command to the devices they know
of as a binary message with specific data in it. The command is set to a 'max hops' of 3. If
the destination device receives the command then it responds, acknowledges, and it's over.
If not then that device will relay the command to the devices that it knows of and
decrement max hops. When max hops reaches 0 that device will no longer forward the
command. This is so that if you sent a command to a device that doesn't exist it would
bounce infinitely around inside the network, never stopping. That would effectively ruin
your network. Max hops prevents this internal reflection. You can see clearly by this 'mesh'
model how having more devices and more links between them strengthens the network as
there are more paths to get to each device and a greater likelihood of finding it quickly.
A significant part of this communication is that when the responder finally receives the
command it acknowledges it. This is something that X-10 never did. With X-10 you sent
your command and prayed. Later devices let you do status checks but they were expensive
and didn't work well. The controller relies on this ACK coming back. Commands that are
not acknowledged cause a great deal of network performance degradation. The controller
will lag and flash if it doesn't receive a prompt ACK - this signifies to you that something is
wrong - and that something is usually a missing responder or responder link.