motion sensor - Status is On vs Control is switched On

[eitheta]

What's the difference between these two program conditions, for a 2420M INSTEON Motion sensor?

 

If
       Status  'Motion1-Sensor' is On
Then
       Foo
       Bar
Else

versus

If
       Control 'Motion1-Sensor' is switched On
Then
       Foo
       Bar
Else

 

Is maybe the first version a polling test, with the ISY continuously sending queries to the motion sensor and the motion sensor responding to each query?

And maybe the second version is a silent listener, which does nothing until the motion sensor sends a notification (unsolicited by the ISY) that it has detected motion?

If this guess is correct, then the first version results in continuous network traffic, while the second version does not? In which case I should probably avoid the first, unless there's some specific reason to use it?

Or maybe the two conditions result in exactly the same communications and results?

 

This question also applies to e.g. TriggerLinc-Opened.

 

Thanks!

[eitheta]

I found some info about this in the wiki:

http://www.universal-devices.com/mwiki/ ... _vs_Status

 

When you use 'Control' you are testing for how it was turned on, eg. On, Fast On, Off, Fast Off etc

...

When you use 'Status' you are testing for its current brightness level.

 

No mention of the continuous polling issue I was wondering about. Does the ISY maintain a table of current status for all linked devices? And it only updates the table when it receives an indication of a change in the device. And it just uses the value from the table, for deciding program conditions? In which case, do I need to worry about the potential for the table to get outdated or otherwise out of sync with reality? Perhaps the ISY occasionally queries devices to ensure its status table hasn't gotten out of sync?

 

I gather that the INSTEON protocol requires a form of ACK packet, and provides for retries if that goes awry.

But I also gather that when I set up a simple scene (e.g. one KPL button controlling one ApplianceLinc), then the KPL and the ApplianceLinc can do their thing even if the ISY goes down. Which suggests that those two devices wouldn't be requiring an ACK from the ISY, and leaves the possibility that KPL's signal is acted on and ACKed by the ApplianceLinc, but the ISY might miss the transaction. So it's device-state table is not guaranteed to be up to date.

 

In the motion sensor or TriggerLinc cases, I've not set those up as part of scenes, so I would presume that when they send a signal indicating detection of motion or switching, then they retry the signal until they get an ACK from the ISY (which is the only device I've linked them with). So the state-table incorrectness worry would seem inapplicable to these.

 

Sorry if these seem like pointless (and not very precisely formed) questions - I'm just new to the whole Insteon thing, and trying to get a handle on what's actually going on when I use the "programming" tool in the ISY Admin Console.

 

Thanks!

[LeeG]

eitheta

 

The ISY does not automatically poll devices. There is a Query command that can be issued by the Program to obtain the current status but this should not be necessary under normal conditions.

 

The Control option is reacting to a specific command coming from the device. If the motion sensor was set to Occupancy mode where an On command is sent for each motion detected regardless of the timeout interval, every time the motion sensor detects motion and sends an On command the If condition is True and the Program runs.

 

The Status option is True based on the status/state the ISY is keeping for the device. The If Status On becomes True when the motion sensor status/state changes to On. This remains True for as long as the motion sensor status/state is On. A Program that is triggered from an If Status On will run when the device status changes to On. Subsequent On commands from the device do not change the Status from On so the Program will not run on subsequent On commands. Of course other If conditions could cause the Program to run.

 

I hope that explanation is accurate. I am sure someone will jump in with another perspective if what I said is thought to be wrong.

 

Lee

 

EDIT: A Controller sends a command to each Responder in the Scene. Each command must be ACKed by the Responder before the Controller moves to the next Responder.

 

Example:

 

KPL button C is a Controller

SwitchLinc1 is a Responder

SwitchLinc2 is a Responder

 

When KPL button C is pressed On, the KPL sends a Group Broadcast message on the powerline which ALL devices normally receive. Any device which has a Responder link matching the Controller device address and Controller Group/Scene number react simultaneously. The Group Broadcast cannot be ACKed by any device as it is not sent to any specific device. The KPL then sends a Group Cleanup message to SwitchLinc1. SwitchLinc1 will/should send an ACK back to the KPL. Then the KPL will send a Group Cleanup to SwitchLinc2 which will/should send an ACK back to the KPL. All of this happens without ISY intervention.

[oberkc]

One other difference that I see between status and control is the that by using status, you are relying on the device (motion sensor in this case) to control the on, off, and time in-between. By using control, you can simply watch for "on" signals and then use the ISY-99 to control the timing and shutoff.

 

I have the same perception as LeeG which is consistent with your assumptions.

 

No mention of the continuous polling issue I was wondering about. Does the ISY maintain a table of current status for all linked devices?

The status is based on an ISY-99 maintained table of current status (which can be seen at the admin panel, my lighting). If the ISY recieves an on command from a motion sensor, the status will turn to on and remain so until it recieves an off command from that sensor.

And it only updates the table when it receives an indication of a change in the device.

That is my understanding

And it just uses the value from the table, for deciding program conditions?

Yes, also my understanding

In which case, do I need to worry about the potential for the table to get outdated or otherwise out of sync with reality?

It can happen, but if so this typcially indicates a communication problem which needs to be solved.

Perhaps the ISY occasionally queries devices to ensure its status table hasn't gotten out of sync?

It appeared to me that the ISY has a default program which queried the system every night at 0300 (or something like that). Does yours include such a program?

But I also gather that when I set up a simple scene (e.g. one KPL button controlling one ApplianceLinc), then the KPL and the ApplianceLinc can do their thing even if the ISY goes down. Which suggests that those two devices wouldn't be requiring an ACK from the ISY, and leaves the possibility that KPL's signal is acted on and ACKed by the ApplianceLinc, but the ISY might miss the transaction. So it's device-state table is not guaranteed to be up to date.

All consistent with my understanding. If the ISY misses the transaction, then this would constitute, in my mind, a communication problem, which should be fixed. If the ISY "misses" things, you will not be happy with the performance of you system. But, you are correct. Scenes will continue to work without the ISY.

then they retry the signal until they get an ACK from the ISY (which is the only device I've linked them with).

I believe there is a limit to the number of retries. Perhaps three?

Sorry if these seem like pointless (and not very precisely formed) questions

I found them neither pointless of imprecise.

[eitheta]

Thanks to LeeG and oberkc for the replies. Both were helpful.