Identifying the last unit to Change a GA

"Originating Unit"

Toolkit identifies the last unit that changed a GA (Application logs).

Is there any existing function on the PAC that can do this?

If not, are there any plans to do this in the so called future?

 

I don't think so, and I doubt the feature is on the short term feature list. (Sorry for being vague, but Darren keeps a closer eye on the PAC product). However, I'm really curious as to what you would use the feature for if it was available.

If really desperate there is a a way to do it by connecting the serial port of the PAC to a PCI and writinig your own implementation of the C-Bus protocol in pascal.

 

No.

No. I am not sure why you would want to. Can you give me an example of where this would be useful ?

 

An inbuilt Application Log on the B&W TouchScreen would rock for diagnostics.. a neat little portable diagnostic tool..

 

Good one Duncan - I am pretty sure Darren could knock that one up before lunch time.

 

Yep, that is a good idea. But the poster mentioned using a PACA. I would be hesitant to recommend any logic control that was based on unit address (which is what the change messages use) as these may be changed at anytime during a scan and unravel breaking any logic based on unit addresses.

 

Here goes nothing.

Current Setup

1. Cytech?s Comfort Security Panel linked to CBUS
2. All PIR are connected to Comfort
3. PAC
4. Neos and DLTs

In common rooms, when movement is detected, the GA is retrigged (timer via PAC). If user uses any key on the Neo/DLT to manual switch the GA on, I do not want the PAC to continue retriggering the GA based on movement.

I have the setup working based on GA levels. I had this working using global variables, but it was a pain to maintain, especially when the GA is controlled by multiple units.


Hope that makes sense.

 

Errr not really. The first thing I can think of is - are you using "Once" for your PAC logic ?

You might have to try to explain a little more clearly in order to give you any useful help. I am sure the PAC can easily do what you require. As I have said here before. Before you can try to write any logic you have to have a thorough functional description (from all angles) of what you require. The first step to writing good logic code is to write no logic code. Get the functional arrangement spot on first...

 

I think I get it...

Ok,

I think I understand your problem;

If the light has been turned on "manually", you don't want movement to start the timer on the PAC, which would then turn off the load when the timer expires.

My first thought was to use two GAs per load - one controlled by the PAC & the other controlled by the input units - and then use OR logic on the output units. The problem with this is that if you turned the load off using the key unit but the timer was currently triggered then the load wouldn't turn off until your timer expired.

A variation on this is to have the PAC track the state of the switch controlled GA and reflect this onto the actual load GA. When the switch GA turned off you could start a "guard timer" on the PAC that inhibits the operation of the movement sensor for 30 seconds - this would prevent the movement of someone leaving the room from turning the light back on that they just turned off.

Of course I haven't programmed a PAC yet, so there could be an even easier way to do this

Paul

 

Yep.

I did this initially, but the run out of "logic space" as the outputs allows about four logic groups per device. And the LED on the keypad does not reflect the correct status of the GA as well as the issue you hilighted above.

Are you talking two GA and using TrackGroup function?

 

This I think is the best idea. The PAC could detect the key switch transition to off a cancel any timers.

 

Richo, if it is two GA, the off transition will be on one GA while the timer is on the other GA, how will the PAC cancel the timer?

 

In this case I'm assuming the PAC is doing the timing and therefore can cancel it. If you can't cancel a PAC Timer (I'm on my linux box and don't have PICED installed) then you could certainly combine the timer and another flag in the code as to whether to ignore the timer or not.

 

You can cancel a timer any time you like by
TimerStop (n)
{where n is the integer number of one of the 20 available timers in the PAC or a declared constant reference if you are using seveal timers.}

Again there is nowhere near enough functional info for a solution to your issue. There is a good chance your functional flow crosses itself up so no amount of logic coding will help you.

My first, no this is the second question, is it possible on normal entry to this room/area to get to the switch first without being detected by the PIR or should I say - on normal approach to this room / area is there a chance the PIR will pick up movement before the switch is pressed.

 

I am trying to use as little code as possible and have the code as effecient as possible as the PAC does a lot of other things as well.

I am using PulseCbusLevel which uses an internal timer.

This is a common room with multiple entry points, on 2, the PIR will, on the rest it does not pick up movement before the switch is pressed. 80% of the time, the setup works fine, the switch is for the 20%.

As I said, I had tried a few other ideas (two GA's and so forth).