[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: xAP Floorplan
--------------070402050903050004010207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Probably best to explain what should happen.
When a link is triggered with a time-out set the first thing that
happens is , obviously, a cmd is sent to the light to turn on. Now a
timer is added with a block of code to turn the light off. This timer
will show up on the timers screen. When the timer triggers the light
will be turned off and the timer is removed. Additionally if the link is
re-triggered then the timer will be recreated with a new time. The
theory is that the time will be alwasy be X minutes from the last event.
So in trying to debug why the timer is going wrong the easiest way is to
keep an eye on the timers screen and verify that the time is indeed
updated each time the PIR is triggered and that no duplicate timers are
created.
hth
James
Kevin Hawkins wrote:
> I have not tried a similar setup but I was just wondering about how
this
> is implemented in FP. Is it possible that the first trigger of the PIR
> already places in the queue a corresponding OFF command for 20 minutes
> later and although later triggers happen the previous 'OFF's are
already
> queued and hence happen still ? From my understanding of what your
> saying below you are right in that there shouldn't be a xAPBSC.cmd /
> state=OFF being seen although you would see xAPBSC.events or
> xAPBSC.infos with state=OFF as this is a status message from the lamp
as
> it turns off.
>
> K
>
> Shane Harrison wrote:
>
>> Bit of a co-incidence - I was just about to write a post about the
same
>> subject as Andy.
>>
>> I am convinced there is an issue regarding links in my setup
having played
>> around quite a bit. I also continue to have page loading issues
even though
>> I have upgraded to the latest intranet.ocx - it is better but not
completely
>> solved.
>>
>> I have setup up a link between a PIR and a light. Set it to
"Any change
>> always turn on", run for "20 minutes" and
"linked". It seems to work fine
>> for a while but eventually it continues to respond to the PIR
event but only
>> stays on for a second or so.
>>
>> I looked in the viewer and the floorplan is definitely sending an
off event
>> almost immediately which shouldn't be possible if my understanding
of the
>> logic is correct since I don't have a toggle situation and hence
external
>> events can't cause the behaviour I am seeing.
>>
>> Running WIN2k, latest floorplan.
>>
>> Would collecting a trace be useful?
>>
>> Cheers
>> Shane
>>
>>
>>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
--------------070402050903050004010207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Probably best to explain what should happen.<br>
When a link is triggered with a time-out set the first thing that
happens is , obviously, a cmd is sent to the light to turn on. Now a
timer is added with a block of code to turn the light off. This timer
will show up on the timers screen. When the timer triggers the light
will be turned off and the timer is removed. Additionally if the link
is re-triggered then the timer will be recreated with a new time. The
theory is that the time will be alwasy be X minutes from the last
event.<br>
So in trying to debug why the timer is going wrong the easiest way is
to keep an eye on the timers screen and verify that the time is indeed
updated each time the PIR is triggered and that no duplicate timers are
created.<br>
<br>
hth<br>
<br>
James<br>
<br>
Kevin Hawkins wrote:
<blockquote cite="mid446C42F7.6080806@xxxxxxx"
type="cite">
<pre wrap="">I have not tried a similar setup but I was
just wondering about how this
is implemented in FP. Is it possible that the first trigger of the PIR
already places in the queue a corresponding OFF command for 20 minutes
later and although later triggers happen the previous 'OFF's are already
queued and hence happen still ? From my understanding of what your
saying below you are right in that there shouldn't be a xAPBSC.cmd /
state=OFF being seen although you would see xAPBSC.events or
xAPBSC.infos with state=OFF as this is a status message from the lamp as
it turns off.
K
Shane Harrison wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Bit of a co-incidence - I was just about to
write a post about the same
subject as Andy.
I am convinced there is an issue regarding links in my setup having played
around quite a bit. I also continue to have page loading issues even though
I have upgraded to the latest intranet.ocx - it is better but not
completely
solved.
I have setup up a link between a PIR and a light. Set it to "Any
change
always turn on", run for "20 minutes" and
"linked". It seems to work fine
for a while but eventually it continues to respond to the PIR event but
only
stays on for a second or so.
I looked in the viewer and the floorplan is definitely sending an off event
almost immediately which shouldn't be possible if my understanding of the
logic is correct since I don't have a toggle situation and hence external
events can't cause the behaviour I am seeing.
Running WIN2k, latest floorplan.
Would collecting a trace be useful?
Cheers
Shane
</pre>
</blockquote>
<pre wrap=""><!---->
xAP_Automation Main Index |
xAP_Automation Thread Index |
xAP_Automation Home |
Archives Home
|