Central PIR Control

I am after an efficient means of operating PIR sensors in a dwelling.

This property has 13 or so PIR sensors across 3 levels. It has 5 x 5753PEIRL; 5 x 5750WPL and 3 x wall mount one (whatever they are). I would like to control these from a C-Touch panel (2 in the property) for the following reasons.
1. The light level readings on the multisensor seems to report 0 except for the unit on the terrace and can't be used for light level readings. Therefore a desire to use sunset command to determine operation.
2. There is the need for a universal disable/enable from the touch panels for times when the sensor operation is unwanted
3. There is a desire for movement detection with a counter that indicates time elapsed since last trip up to 5 minutes. Ie movement draws a coloured shape on the screen with text counting.
4. There is a need for more complex logic routines than can be attained within the units themselves. For example, when certain lights are on then the operation would be disabled and so on. There are more individual group addresses than can be stored on an individual unit ie 4 on the wall mount.

I keep reading that broadcasting the levels on a PIR can "clog" up the network. Given the number of sensors, what is the most efficient method of querying the sensors, or getting a trigger from them so I can act upon the results? Can I get some sample code please.

 

I assume you're talking about the surface-mounting ones that are about the size of half a baseball, the 5751L's.

This can be done by using Schedules in the touchscreen that enable and disable the PIR's at sunset and sunrise. The multisensor measures the light at the ceiling which, in lots of cases, is not very much at all.

This is trivial, but if you need a help here then just ask. Each of the sensors can be assigned a Group Address for enabling/disabling and this can be controlled from a host of different C-Touch components.

If this is just a desire then I'd suggest you have a go at managing your customers expectations, as this is not trivial. The C-Bus PIR's handle all the timing functions internally and you're asking to transfer this responsibility across the network to the Touchscreen. The challenge here is to transfer the timing functions to the C-Touch without generating lots of network traffic. If several of the PIR's are all detecting motion, and they are configured this way, you could easily overwhelm the data bus with messages.

As a start, you'd need to get the PIR's sending messages across C-Bus in response to motion. You don't want this to happen all the time though as there may be times when the network is completely flooded with C-Bus messages and then the customer will be calling you to tell you that "the lights don't work".

You could possibly throttle the network traffic by making each of the PIR's control a logical group, not the actual group associated with the output channel, with a 5-10 second timer. Whenever this logical group goes on, the C-Touch could re-set a timer on the real channel group back to 5 minutes (or whatever timeout value you want).

Ultimately, it will become a trade-off between network traffic and timing resolution on the C-Touch as you vary the timer interval in the PIR.

This sort of thing is fairly straightforward using the in-built logic functions. There's plenty of examples in the PICED help to get you going.

What you're asking for is not trivial and writing logic to handle cases like this is a task that many people actually get paid for, so I doubt someone is going to give you their logic code for free on this one. Simple examples, maybe, but not something more complicated like this, where you're trying to manually re-create features that the products handle internally natively.

 

Thanks Newman. I got carried away with the preamble and in so doing masked my question. The code on the c-touch is no problem (eg logic, counter, enables etc etc). However, being completely new to cbus my query is; what is the best way to get a PIR trigger onto the c-touch? It seems universally agreed that broadcasting PIR levels potentially "clogs" the bus. So then what is the "best" method? Could it be:
1. On the PIR set the secondary application to trigger group, apply that to a virtual key set for bell press and
2. then monitor for it on the c-touch? eg. once GetTriggerLevel("name") = 255 then ...

Would that work or have I completely missed the point?

I appreciate your patience.

 

Changing the application that is used from Lighting to Trigger Control doesn't address the network traffic issue that you are going to get by trying to centralise the PIR's timing functions. You could use either Lighting or Trigger Control for this purpose. The previous comments about potentially finding a compromise between timing accuracy and network traffic, and doing this through the use of short duration timers in the PIR's, still stands.

I certainly wouldn't use a key configured as a 'Bell Press' as this will result in lots of C-Bus messages. This is akin to the 'Any Motion' feature in regular PIR's and Toolkit gives the user a warning about excess network traffic if it is used.

The mechanism you use to get messages from the PIR to the C-Touch doesn't matter so much, it's the message rate that is important to control. You could just use the default PIR configuration, shorten the timers down to 5-10 seconds or so, make the primary application Trigger Control and just use a logical trigger group address that is not associated with a real load. That would be sufficient and you could use the GetTriggerLevel function as you suggest. There is no real "best practice" example for this sort of thing because it is not normally done.

 

Thanks. I've got that. Use "on" with timer to control bus traffic to every 20 sec or so. Use "once" function to limit ctouch load to at most 1 every 100 scans @ 20 sec.

Out of interest, would it work to make a group address with no physical load, apply a timer and then use a GetLightingState on the ctouch to monitor the state?

By the way, the "public" area PIRs are the only ones that need the complex logic. The other private areas like bathrooms, toilets and so on are easily controlled on the unit.

 

The timing won't be this precise, as the timer in the PIR will be re-set to it's initial value every time it detects motion, but you've got the general idea. If you're running the logic on a Colour C-Touch they can handle a LOT of logic, but using 'Once' means that all the code below that only gets executed the first time the condition becomes true (which is good).

Yes, it's quite OK to have a group address that isn't associated with any physical load. The only thing to be mindful of here is that the power-up state of group would be Off, regardless of the power-up settings in the PIR, so setting the group to a known value at power-up would mean the first event detected behaves predictably.

 

Thanks