PIR enable/disable from PAC

I have a building with a number of relays, PIRs and a PAC.

The requirement is:

• 7am-7pm ("day"), lights stay off until a PIR triggers them, then they stay on until the end of the day (ie the PIR will turn them on but not off).
• 7pm-7am ("night"), lights trigger from PIR, and turn off after 30 mins of inactivity.

What's the best way to program the PAC and PIRs to achieve this?

 

Update:

The way I'm doing this now is to configure the PIRs to directly control the lights on a 30min timeout, and also using the PAC to trigger a daytime override group whenever it sees the PIR trigger during office hours; the overide is being used in logic in the relays to hold the lights on after the PIR switches off, and the overrides are all being reset at 7pm to return to PIR control.

That seems to make sense and covers all the edge cases that I've thought of (eg lights in unused areas should go off at 7pm without delay, lights in occupied areas will however stay on, etc).

Suggestions still welcome though.

 

Is there a way to do this with a schedule ?

Then with a schedule - working hours - you disregard the status of the PIR and set those PIR Control groups = OFF which disable the PIR.

PIR Control Group = ON from 7pm .... 7am

In the PIR set the function, Disable PIR when "PIR Control Group" is disabled.

At a given time enable the control group "PIR Control Group". The night schedule will take over based on the inputs from the activated PIR modules.


Schedule 1 - When the PIR modules will be on and when the PIR modules will be off. This group is linked to the PIR directly.

Schedule 2 - Logic function which determines which lights operates and how long. The condition is OR in the logic. This means that it can be overridden by a local key-press to have lights ON as needed and then controlled by PIR when key-press is OFF.

You can "almost" do it without PACA.

 

It's interesting to see an application where an auto-on schedule-off scenario is required. I find it much more common to see a manual-on auto-off, especially in this energy conscious day and age.

What you have there sounds like it will work just fine. I reckon 10 different people would solve this 10 different ways.

Is there a particular problem or improvement that you're looking for, or are you just looking to broaden your mind by seeing other ways of doing it? One minor negative I can think of with your approach is that the relay channel group won't necessarily reflect the state of the load, as you're using output unit logic, but that may/may not be important in your application.

 

We experimented with this, but had a problem that if a PIR turns a light on, and is then disabled, it will still turn the lights off when the timer expires. We'd need the lights to stay on (obviously!) so that's not acceptable.

Also, we need any lights that are off at 7am to stay off until triggered by PIR, then stay on until 7pm. We don't want to bring lights on at 7am unless they're called for.

(By "we" I mean that's what the spec says, I don't have to agree with it!)

As I understand it, the existing building commonly has lights on 24/7 so this does represent a substantial saving. I would imagine that as the savings are seen they will want to go further.

Not really; when I first posted we didn't have a solution we were happy with (eg disabling PIRs as above), and it's hard to think of all the edge cases and test them (what happens if the lights are triggered just before 7am, what happens to lights in areas that are still occupied at 7pm, etc). In my experience, most problems have already been solved so there's no harm in asking!

What I can see happening next is that they'll want to move to 30mins 7pm-7am, and (say) 2hrs 7am-7pm instead of all day. So I want to try and be ready for that in some way.

 

Just found a problem: insufficient logic tags. Most of the relays (they're already on site) are 12-ch relays, and I can only assign 4 additional tags to the logic, which isn't going to be enough.

So now, I'm going to do the logic in the PAC to generate a third tag, and use the third tag to control the lights. If the PAC fails, the lights won't ever come on, so I'll also configure the PIR to turn on the 3rd tag when it triggers, but set the action on timeout to be "idle". So worst case, lights come on and stay on.

I *think* that covers me.

 

So then you would have a schedule with more than 1 PIR group group (according to how I discussed it). If the PIR groups need to do different things then they would logically be in different PIR groups.

I would still use the OR function in this design as I framed it. The OR could be in the Output module.

 

Ah, it looks like I misread your post and made assumptions which fitted in with what I'd been doing, not what you were suggesting! Sorry!

 

Here's an alternative way of achieving the same result that doesn't use output unit logic.

Configure the PIR's so that they turn on 2 groups (e.g. 'Office 1 Logical Day' and 'Office 1 Logical Night') whenever they sense motion (this is easy in Multisensor PIR's but not so obvious in other more basic PIR's). In the PIR apply the 30-minute timer to the 'Office 1 Logical Night' group only. Use a 3rd group address for the actual load (e.g. 'Office 1 Load') and assign it to the relay channel only.

Then, in logic, use the trackgroup function to copy the state of the daytime group to the load during the day, and the night time group to the load during the night. The group without the timer is used during 7AM to 7PM and and the group with the timer is used from 7PM to 7AM. The logic code would look something like this:

Code:

if ((time >= "7:00:00AM") and (time < "7:00:00PM")) then
begin
  TrackGroup("Wired Network", "Lighting", "Office Logical Day", "Office 1 Load");
  // Insert extra groups here
end
else
begin
  TrackGroup("Wired Network", "Lighting", "Office Logical Night", "Office 1 Load");
  // Insert extra groups here
end;

If a PIR has detected motion in the half-hour prior to 7PM, it will remain on after 7PM, until the 30-minute PIR timer expires.

You'll need a schedule that runs at 6:30AM to turn off all the 'Office x Logical Day' groups prior to the logic engine switching over to using them (at 7AM). This will flush out the PIR events on the 'Office x Logical Day' groups from the previous day, yet if any lights are already on when 7AM comes around (due to PIR events after 6:30AM) they will stay on when 7AM clocks over and remain on for the day.

Using this method there's no need to separately enable/disable PIR's or use output unit logic, so the state of the 'Office 1 Load' group will always be an accurate reflection of what's on or off at any given time. There's probably a wart or two in there somewhere... that's what you get for doing this sort of thing late at night.

 

PS: This approach is easy to modify for the 30-minute / 2-hour option you suggest above too. Instead of just turning on the 'Office 1 Logical Day' group, you would turn it on and run a 2 hour timer as well.

 

I'm about to do a similar setup.

Can anyone else confirm that disabling a PIR or Multisensor PIR does not stop the timer?

I am expecting to have the Multisensor turn on the lights, then through logic disable the sensor. The local switch will then be able to turn the lights off, with logic enabling the sensor.