Add a on delay for PIRs

[nigels0]

Hi,

When using PIRs, they are likely to trigger each time something moves in front (as they are designed). What would be neat is to have an option to be able to disregard repeated triggers for a configurable number of seconds. Sort of the reverse of the off-delay. Where PIRs are constantly on, the off delay adds no value.

[Egregius]

What's the problem with repeated on signals?
I find that even good, that way the lastupdate of the pir is updated.

[lost]

Hi,

When using PIRs, they are likely to trigger each time something moves in front (as they are designed). What would be neat is to have an option to be able to disregard repeated triggers for a configurable number of seconds. Sort of the reverse of the off-delay. Where PIRs are constantly on, the off delay adds no value.

Depending on technology, PIR may be tuned directly to trigger after several detections in a time lapse. For devices that do not allow this, the only way would be to manage them externally by a service that'll filter their trigs (for instance simply adding them as a trig weight) as you like and, when a trigger threshold will be reached, feed a virtual switch in Domoticz through the HTTP API for 1s & reset the trig weight.

I'm doing this for external cams, to avoid them triggering on a bird passing by for instance: They send captures on a FTP hosted on the I running Domoticz & a python written service monitor cams upload directories every 10s and opens a 1mn time window during which nb of images captured will feed a weight & if a threshold is reached, will feed a virtual PIR switch in Domoticz + send images in a password protected archive on a dedicated gmail account.

This virtual PIR can be used as true ones in an alarm system build on Domoticz (via Lua scripting).

[nigels0]

Yes, that's my point. Having external code is messy where a time check within domoticz would be much tidier and functional .

I'm having to do the same with my cams, but the log still shows repeated triggers which really aren't wanted.

Fair point about the update time, but I'm only talking about 30 seconds here.

[lost]

Yes, that's my point. Having external code is messy where a time check within domoticz would be much tidier and functional .

That's your point... But for those who implements such things that's not as easy at it sounds, especially if you want to make tunables that'll fit every device/situation.

I see Domoticz as a platform that does a good job on merging/scheduling things & making them available to users. But specific needs should IMO not make it's core grow too much, especially if it can stay out using existing APIs.

Working on a good plugin system (looks it's on the way) is IMO a better way to handle this kind of stuff in a better way compared to what exists now. Another is to buy the right devices.

[nigels0]

Hmmm. I'm not suggesting a complex feature or limited use feature here - what I'm suggesting is the opposite of the off delay. If that is there, then an on delay option is hardly extending domoticz significantly.

I thought the point was to suggest things for addition in this part of the forum.

Anyhow without this feature, I'll probably use variables and use them as flags.

[lost]

Hmmm. I'm not suggesting a complex feature or limited use feature here - what I'm suggesting is the opposite of the off delay. If that is there, then an on delay option is hardly extending domoticz significantly.

That's just my opinion, but I assume there is another problem: This kind of switch (PIR, contact switches used on doors), like sensors (temperature...) is supposed to copy an hardware state.

That's why you even cannot modify their state/value from the interface! Only an external hardware can drive them.

I think others will find this confusing to change this behaviour.

This is why I advise doing a post processing job in an alarm scripted system (in Lua, there is examples on the wiki) to say "for this switch I allow N state changes in a time slice before switching on the siren". Or a pre-processing one, for a cam that drives a virtual PIR for instance, to switch on if someone is moving for some time in front of your house but not when the neighbor cat rushes into your garden.

Just a tip: Using naming prefix conventions for internal/external PIRs even allows adding new devices without alarm script modification.

This is what I did, using a weighting mechanism (suggested by another forum user several months ago): Internal sensors have a base weight (=summed weights in a defined time slice that is set as the threshold) that triggers alarm immediately. External ones have a base weight that is a fraction of the threshold. Cams directly drive a weight that is a fraction of captured image nb in the slice, per device configurable: Too much variations depending on device type, it's situation... For them, adding one is a YML config file setup & restarting the service.

[nigels0]

Well I fixed it in the script - but I'm still getting log lines, which is irritating but no big deal.

I think we'll have to disagree about the feature.