5753PEIRL Multi sensor

Hi all,

I have an installation that covers two seperate floors of an office block, each floor is indentical but has its own network. Each floor has 18 5753PEIRL sensors controlling five 8 channel DSI Gateways via a single lighting group.

The Multi sensors are set simply, Day and Night move of 30 mins and currently no light level maintenance or light level broadcasting is enabled. Of the floors, one is existing and the other new, the existing floor Multi sensors have mixed firmware of V1.8.00 & V1.9.00, the new floor is all V2.3.00. All devices, PIR's and DSI are programmed exactly the same but the floors exhibit strange, but distictly seperate behaviour.

On the existing floor, lights go off at random times, often after only a few seconds from when it was triggered even though it is set for 30 mins! (see attached Toolkit log file, unit 41 @ 12:07:06 and 12:07:11.) strangley this appears to be only happening on the PIR's with V1.9.00 Firmware!?

http://www.cbusforums.com/forums/attachment.php?attachmentid=1750&stc=1&d=1331045600)

On the new floor the lights are dimming, and the log file from the diagnostic utility appears to support that yet no PIR has level maintenance or light level broadcasting is enabled.

http://www.cbusforums.com/forums/attachment.php?attachmentid=1751&stc=1&d=1331045745

Any ideas,

Paul

 

Please re-attach the logs. I cannot read them.

To clarify, are all 18 Multisensors assigned the same group address? Are all the DSI output channels using the same group address?

 

Sorry, dont know what happend there but a section of the the logs are now attached, although only a section the activity is typical of the entire log.

yep all 18 Multisensors and all the DSI output channel share the same common lighting group address. Some further info, just in case you query it, all the multisensors have their 'pot A' fully anti clockwise.

Paul

 

With so many units controlling just a single group it's quite likely that there's a unit or two out there that are incorrectly programmed. It also means that any changes you make need to be made to all units at once, which takes time.

On the first part of the log, have you confirmed that unit 41 is definitely programmed with 30 minute timers, and that no other options are enabled?

I recall there being a site where electrical noise being emitted by a particular fluorescent ballast was being picked up by the IR Receiver in the Multisensors, making them turn off their groups. It's a long shot but you could try disabling the IR Receiver in all the Multisensors.

For the second log, have you actually confirmed that unit 21 on network F8, unit 28 on network F8, unit 27 on network F8 are actually Multisensors and they're programmed as you expect them to be?

 

What a waste!

Hi Paul
Sorry I can't be of much help, but I did a project with hundreds of PEIRL's about 3 years ago. Part way through they found an issue with the PEIRL firmware and had to change them all out. Unfortunately I don't have the Version no's but hopefully Clipsal has that all sorted out by now.

It would seem though that the installation has gone to the expense of dimmable ballasts and a dedicated control system and all they do is hard switch all the lights on / off at the same time?? This type of installation is why C-Bus gets a bad name, but it is really because of poor design &/or poor programming/installation.
What a waste of infrastructure and expensive components. Sadly this is not uncommon. I suggest you dimm on and off and Turn the PIR timer down so that you may at least get some energy savings each day.

 

What firmware version are the multisensors ?

 

Thanks to you all for the responses, ill answer all the questions as best I can

Yes I understand what you saying, but have checked, rechecked and checked again but they are all the same. Ive attached the Global & Light Level GUI tabs, this is the same for all, I was wondering, even though pot 'A' is fully anticlockwise, should it be disabled in the Global tab or doesn't it make any difference? Also I have Virtual Key1 = daymove & Virtual key2 = nightmove, should they both be set as day move?

Confirm, definitley 30 mins.

Thanks, good idea, all the fittings are in a false ceiling and all the multisensors are all close to fittings, but some could be closer than others.... i'll check the logs v pir position and and see if there is any correlation.

Confirmed they are same as all the others.

I agree, but unfortunatley the existing lighting installation, done by others, can only deliver around 500lux on a relatively bright day! this is the minimum CIBSE (Chartered Institute of Building Service Enginners) here in the UK recommend for general office work. So dimming will only reduce this below permitted levels and as all the existing DSI light fittings are relatively new the client doesn't want to replace them or go to the expense of adding more (which kinda defeats the object anyway...)

MultiSensors on the Existing network are all V1.8.00 & V1.9.00 and on the new network they are all V2.3.00

Thanks,

Paul

 

Rotating Pot A fully anti-clockwise should give you the same light level threshold behaviour as if the pot was disabled. Your virtual keys are configured correctly.

 

Thank you for your detailed answers. I think I know what's happening here.
Assuming that the network communication is fine; sufficient power supplies, burden correct, no intermittent connections (- these problems could create similar symptoms or exacerbate the symptoms you are seeing), then the fact that many motion sensors in the same area control the same group might be the core of the problem.

When there is motion that can be seen by more than a single sensor, the sensors will fight for control of the group. The last sensor that saw a motion in the end is the unit that determines the timer interval if all is going ok. When there are so many sensors and they can see the same motion, the traffic can get so high that some of the sensors may fail to get their message through. This is an abnormal situation. Different firmware versions exhibit slightly different behaviour in this case, and what you are reporting matches this. The earlier units V1.8.00 and V1.9.00 will enter an 'error' state if they fail to get a message out, and the next motion they detect will exit this state and turn the group OFF. This seems to agree with your observations.

Firmware version 2.3.00 is slightly improved - if this abnormal situation occurs and it gets into the 'error' state, it won't stay in the 'error' state permanently, but after 60 seconds will return to normal operation, and next motion detected will turn the group on according to your configuration. If the unit is in the error state and is still timing the 60 seconds when it sees motion, it will issue the countdown timer value as a level instead of turning the group OFF. This is why you see 'dimmed' levels and why these levels are always below 60/255.

What to do about it?

Firmware version 2.3.00 has an inbuilt feature which should help. If you change the programming in these units so the single controlled group is in the second block and not the first block, then any units that see a command to turn on the same group will hold off for a few seconds before they register a motion. This feature will reduce traffic greatly and should stop the problems on that network. This 'crowd tolerance' feature was added to multisensor in version 2.3.00 firmware, but it doesn't work for 'motion in darkness' if the controlled group is in block 1 - it only works for block 2. (that's been fixed in V 2.4.00... we strive to improve the performance of units in all situations).

What to do about the floor with 1.8.00 and 1.9.00?
If you can limit the field of view so a movement can't be seen by more than one sensor at a time, it would be a great help. If you can't - or if the traffic is very high in the area, I suggest swapping a few sensors between floors - and place the earlier units into positions in the floor dominated by 2.3.00 units that see as little motion as possible (and not the same motion). The 'crowd tolerance' feature of V2.3.00 should reduce network traffic here.
When positioning a few 2.3.00 units (programmed with the controlled group in the second block) on the floor dominated by 1.8.00 and 1.9.00 units, place them in the highest traffic areas, or where you can't avoid multiple sensors seeing the same motion.

Controlling the same group from multiple motion sensors was not expected when C-Bus multisensors were initially developed, but it seems to be used sometimes now. I hope some of these suggestions can solve your problem

 

Thank you Don for such a detailed explanation, it expalains a lot, but could you just clarify a couple of things for me?

So what i'm seeing here is the value of this 'settling/reset' timer rather than a dimming value and will should always be between 1-60, however, just to put my mind at rest, this would not be interpereted as a dim command by an output unit?

Do you mean that only key group 2 should be used? and should be set as day move? I only ask this as key group 1 seems to use block 2 by default.
I've attached two configrations the 1st is the default the second is, i think, how you suggest they should be set?

Thanks again,

Paul

 

1) yes, the timer value is interpreted as a dimmed level by an output unit. This is a problem, but only exists under very unusual conditions where:
a) a unit has tried and failed to transmit its message due to excessive network traffic, and
b) the same unit has attempted to issue a second command within 60 seconds of the first failed command.
We have tried to replicate this condition in the lab, and find that it is very difficult. The configuration in the installations you have seems to be the only way to achieve it, and even then it is not predictable as to when it will happen.
If you are controlling loads with a relay, you can set the relay threshold to a level of 1, and the controlled load will not be affected. If you are dimming, however, this behaviour presents a problem.

2) The default configuration (the first configuration you attached) is correct for the 'night move'. I suggest leave it that way but set key 1 to 'unused'. Turn the light sensitivity pot fully anticlockwise (or set the light threshold high) so that the sensor always thinks it is 'night' (in this installation, 'night move' is probably more appropriate than day move).
The second configuration you attached would probably work just as well, but set the key 2 function to 'night move'.