The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: xAP Floorplan



------=_NextPart_000_0045_01C67CC5.D4820490
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks James.  I took a closer look as you suggest and there are definitely
duplicate timers in the timers page for that link - hence it would appear
that the code isn't simply updating the time on an existing timer but
creating a new one each time.

Cheers
Shane
-----Original Message-----
From: xap_automation@xxxxxxx
[mailto:xap_automation@xxxxxxx]On
Behalf Of James
Sent: Saturday, 20 May 2006 9:53 p.m.
To: xap_automation@xxxxxxx
Subject: Re: [xap_automation] xAP Floorplan


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









xAP_Automation Main Index | xAP_Automation Thread Index | xAP_Automation Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.