Changing PIR timings

Hi all,

I've got a commercial install in a three storey office block. There are three networks, one per floor, bridged onto a common backbone. Each floor has four office areas, each area is independantly controlled via a group of relays and associated PIRS in that area.

The client wants to change the PIR timings dependant upon time of day, ie 9am-5pm 30mins, 5pm - 9am 10mins.

I'm unaware of a simple way of achieving this without logic and shedules, could anyone differ or confirm.

Thanks in advance,

Paul

 

Correct, you cannot alter the PIR time-out remotely.

Don't be too put off by the need for logic to do this. It should be pretty quick. The simplest way would be to have the PIR control 2 separate group addresses, one with a 10 minute timer and the other with a 30 minute timer. Then, in logic, based on the time of day, use the TrackGroup function to map the correct PIR group state to the output channel group (different from the 2 groups above). It should be as simple as 2 lines of code for each additional group address, so it should be pretty quick to set up.

Something a bit like:

Code:

  if ((Time >= "09:00:00") and (Time <= "14:00:00)) then
  begin
    { Group mapping for 30 minute time-outs }
    TrackGroup(Network, Application, PIRGroup1a, OutputGroup1);
    TrackGroup(Network, Application, PIRGroup2a, OutputGroup2);
    ...
  end
  else
  begin
    { Group mapping for 10 minute time-outs }
    TrackGroup(Network, Application, PIRGroup1b, OutputGroup1);
    TrackGroup(Network, Application, PIRGroup2b, OutputGroup2);
    ...
  end

 

Just looking at the code above, good idea-nice and simple but for a slight improvement maybe put the times into a schedule rather than hardcode them in the logic. In case the client changes their operating hours regieme, in which case it is simple for you to adjust what time the changeover occurs. (rather than having to edit times written in the logic itself).

 

Many thanks for the above Newman the codes no problem as we have a PAC on the system, bit wary of using it in a commercial setting though! I've got a question on the best way of setting up PIR groups though.
I've got a mixture of 5753 & 5751L's, what is the best way of setting up the second group? As an additional virtual key on the 5753's and use the blocks tab on the 5751L's or use the blocks tab on both? also I presume that either way they are set as day move?

Thanks in advance,

Paul

 

I would configure it on the blocks tab for both units. The only reason to use the extra Virtual Keys on the Multisensor for this would be if you want to actually change the behaviour in more complex ways than just changing the time-out.

For both groups the unit will be using Day Move functions when the light level is above the threshold and Night Move functions when the light level is below the threshold.

 

Hi ,

Appologies for pushing this thread to the front again and putting it onto a public forum but as they say "needs must when the Devil drives". Having implemented this solution (exactly), I am experiencing some intermittent erratic behavior with PIR's and consequently the output loads, that is being both difficult and timley to resolve, the situation with the customer is now very urgent to say the least

Schneider UK C-Bus tech support have now got involved, and said, that in their opinion, given the size of the installation this method of operation is incorrect and question:

a, Use of two seperate lighting groups with seperate timer values on PIR's.
b, Achieving this via blocks.
b, The use of a PAC, its capability (and in the singular) to provide such critical functionality.
c, The potential to generate high network traffic. (I know this to be incorrect as have run the traffic analyser at times of high office foot fall and see an error rate of Avg 0.0/sec and a message rate of Avg 1.1/sec)

Their solution is to use a 'standard' PIR config ie, single timer, ML = MD, PIR lighting group = output lighting group. Then set up a timer in the PAC to only become operational during a set time window ie between 5pm and 8am. This would run for a shorter duration than the PIR's timer and therfore turn off the lighting group prior to the PIR timing out.

However, I don't see how this would work, as there is an obvious need to reset the PAC timer in the event of any further motion detection while it is elapsing. As the PIR's timers are still running against an active lighting group they will not transmit any further lighting commands, i believe?

There advice is muddying the water so to speak, what i need is definite answer that the original concept is sound? or not? I can then either carry on the diagnostics or find an alternative solution.

Response from Clipsal staff only please, i know this could be very political but, that needs to be put aside for the sake of the customer.

If you (Clipsal) need further information (privately) please email direct, details are on my profile.

Thanks

Paul

 

I can see no major problem with your two group solution. Can you provide more detail on the erratic behaviour you are seeing?
If you are having problems setting it up reliably, the single group solution may be better.
I also see your point about subsequent motion not resetting the time. Perhaps there is a better way.
With the single group suggestion, instead of setting up the PIR to have the longer duration (30 min) timer, it may be better to set it up with the shorter duration (10 min).

Implement the following in the PAC for each affected group:
Step 1: When the load is turned ON by the PIR, the PAC can start a short timer no shorter than 10 seconds. One minute would be suitable for this installation (to ensure that bus traffic is not excessive).
Step 2: On expiration of the short timer, configure the PAC to:
a) issue a command to set the group to the same level as it already is so that
the network loads are unaffected but the PAC is now in control of the group.
b) start a long timer of either 9 minutes or 29 minutes depending on the schedule.
Step 3: On expiration of the long timer, the PAC can then simply turn off the group.

If the PIR senses motion again, it will turn the group ON again and the PAC can be configured to return to step 1, thus resetting the time interval as required.

This is roughly the same algorithm the PIRs themselves implement to keep bus traffic down while allowing multiple PIRs controlling the same group. With multiple PIRs, Step 2 occurs only if a second PIR senses motion.

 

The C-Bus Forum is not an official support channel and is neither paid for, nor administered by Clipsal/Schneider Electric. There are however plenty of current and past Clipsal employees who contribute to the forum.

If you need an official response, you are very unlikely to get it on the forum. What you will get on the forum is responses from well meaning and knowledgeable C-Bus enthusiasts.

From the Forum Rules:

 

You really need to gather more information to flesh out this statement.
- Can you describe the "erratic behaviour" in more detail?
- Is the "erratic behaviour" occurring only with 5753L's, 5753PEIRL's, or is it always with the same particular units?
- Have you run the Traffic Analyser within the Diagnostic Utility to ensure that the basic C-Bus communication is reliable at ALL times, i.e. log for 24 hours?
- Are there other devices controlling these loads through output unit logic?
- If you configure the PIR's to control the loads conventionally do all the outputs respond correctly all the time?
- Are the PIR's being remotely enabled or disabled?

Depending upon how many groups you're doing this for, it is possible that the PAC is running out of steam and some groups are being missed. According to the PICED Logic help file, a Trackgroup function will consume either 0.4% or 2.4% of the logic engine's execution time. The reason I suggest this is that the logic engine re-setting itself can lead to loads getting stranded on or off. To test if this is the case, you can disconnect the PAC and simulate the logic from a PC, as a PC in simulation mode can handle a lot more logic. An alternative to simulating on the PC (as it times out after a day or two) is to turn on a Group Address at initialisation time in the PAC. If the PAC resets, the group will get turned on and this will show up as a C-Bus message.

You are exactly correct. The PAC will not know that the PIR timer has been re-set by additional movement and will continue to time out 10 minutes after the PIR first turns the group on.

Don's solution is a good one and should work just fine. It has the advantages of only using a single group per output and, if the PAC gets accidentally disconnected, you still get the basic functionality, albeit at the shorter 10-minute time-out. The only minor negative is a little more logic to write per group address.

Why the 2-group solution is not working as you need it to is still a mystery though. Either method should achieve the results you're looking for.