Front Door Bell cancelling melody

[marcuslee]

Hi All,

Have a simple setup of digital input switch which is a Front Door Bell.

Plays the default Doorbell.wav, broadcast to all DFP Type2s.

Also have the front door magnetic reed switch on a digital input, and as per text book help file example, it cancels the Front Door Bell upon opening.


Tonight, had an example whereby I found all DFPs with the X key button red lit. Report was that door bell went off like normal, however the music didn't stop playing when front door opened.

Checking the logs however, I see that when the door opened, the Door bell stopped, but immediately, I see another log entry with same timestamp of it starting again.

It could quite possibly be that the door bell was literally re-pressed just as the door opened.

However to deactivate the door bell melody the user press the red lit X button on closest DFP.

Everything above is expected, except that I thought cancelling the broadcast Door Bell wav, should not only deactivate the red X on the DFP where it was pressed, but also all other DFPs keypads also?


Any insight appreciated,

Marcus

[marcuslee]

Just to add also, to remove the red lit X on the other panels, a simple press of the X didn't deactivate the red backlight. An actual press of the intercom button and then the X was necessary. Which was something else I wasn't quite expecting.

[chris_j_hunter]

maybe your door-bell button bounced, 'though IIRC there are settings on the digital-inputs to avoid such problems ...

OTOH, we've an array of sliding-magnet reed-switch float-sensors in a tank, that we use to track its water-level ...

it generally works v.well ... occasionally, though, one of them switches off (with falling water-level) and on again immediately (ie: same time logged), then off a few minutes later ...

we'd assumed this was due to the combination of a drip of water sending a ripple & the natural stickiness of the sliding magnet ...

but your experience makes us wonder !

there are eight in all, and we think it's just two of them that do this - haven't had time to check that detail, yet, though ...

[marcuslee]

Interesting, also I was just about to reply to my own to say, I think there's something else a foot, as I've just re-simulated what happens when the front door is opened, but the door bell button is pressed, and melody starts. And then the melody is cancelled with the "X" button on a DFP.

All the "X" buttons on all DFPs go from red back to normal colour as expected.

So not sure what happened yesterday but whatever it was, Idratek didn't perform the colour change on the buttons like it would in normal practice.


Thanks for the lead on Digital Input settings to stop the bouncing though I can't see any having looked.

Also as it happens it's not actually a normal mechanical door bell button but a relay on SIP door module, which itself can be set for how long the relay catches for (in this case 3 seconds).

[chris_j_hunter]

>bouncing ...

yep, have just checked a few data-sheets, and nothing's mentioned ...

OTOH, for the buttons on a QBI, digital filtering is mentioned ...

so maybe I was thinking of that ...

and since a QBI is probably just a quad Digital Input module with buttons - it seems likely all Digital Inputs will have such filtering !

so, filtering rather than settings ...

[marcuslee]

Interesting, also I was just about to reply to my own to say, I think there's something else a foot, as I've just re-simulated what happens when the front door is opened, but the door bell button is pressed, and melody starts. And then the melody is cancelled with the "X" button on a DFP.

All the "X" buttons on all DFPs go from red back to normal colour as expected.

So not sure what happened yesterday but whatever it was, Idratek didn't perform the colour change on the buttons like it would in normal practice.

Follow up on this is that I've had this happen a few times now.

And my deduction is that it's definitely Cortex which is not working properly. It appears as if in the logical sequence, that it gets stuck at the "play the music file" part of the sequence. After this sticking occurs, usually all the DFPH's get stuck with the speaker and the "X" button lit red, even though things might have moved on by then, such as the door opening (which should cancel the melody).

To add to the above, Cortex thinks it's played the melody as it lists it in the event list.

Any suggestions on how to troubleshoot this further?

[Karam]

Are any of the intercoms operation period gated at the time of the incident?

[marcuslee]

Are any of the intercoms operation period gated at the time of the incident?

Hmm not sure what you mean by gated? If you mean by in operation, then no. As far as I can recall, I'd say there's been no user activity of the Idratek network at all the times when the door bell has rung (and not executed properly).

At the mo, Idratek's use by users is virtually limited to turning lights on and off only, and door bell has been pressed only during business hours.

[Karam]

I mean the 'Operating time for Sound Prompts and Spoken messages' settings in the intercom behaviour menus. But anyway suggest you visit Diagnostic tab in the logging menu and enable the Sound logging option. Then next time it happens you can go to Cortex, right click on communications window and then click on Capture to log file now! Then send us the log file so that we can try and see what might be going on.

[marcuslee]

I mean the 'Operating time for Sound Prompts and Spoken messages' settings in the intercom behaviour menus. But anyway suggest you visit Diagnostic tab in the logging menu and enable the Sound logging option. Then next time it happens you can go to Cortex, right click on communications window and then click on Capture to log file now! Then send us the log file so that we can try and see what might be going on.

Ah ok, and indeed it's ticked All the time for all the panels.

Thanks for the logging options, this is enabled, and will see if it happens again.