Strange M1G Voice Messages

[RichardU]

I use a rule to: Disable Non-Alarm Voice Messages (when I don't want to hear them). While they are disabled, the system will generate messages, for example "Armed", which are not heard, but they are somehow queued up. Here's what I mean. When I:
Enable Non-Alarm Voice Messages, nothing happens immediately nor should it. However, the next time a Non-Alarm Voice message plays, I hear the proper message, plus the message which was queued up from before.

So for example, in the morning, I turn off Non-Alarm Voice Messages temporarily, then disarm the system. Don't hear anything as it should be. Later in the day, I should hear a message: "Motion Garage." Instead, what I hear is "Motion, is Disarmed, Garage" Strange.

Is there any way to clear out the queue of messages that are generated while Non-Alarm Voice Messages are disabled?

 

[Del91574]

I have the same rules in a bunch of panels (time based, so at night the notifications are squelched) and haven't experienced such.

Are there rules that clash? Maybe changing how the rules enable/disable the voice are part.

For giggles, what firmware is this?

 

[RichardU]

I updated all the firmware to the latest with no change.

Here are my rules:
WHENEVER F4 KEY ON ANY KEYPAD ACTIVATES; THEN TURN Output 100 ON FOR 10 SECS
WHENEVER Output 100 STATE IS TURNED ON; THEN DISABLE NON-ALARM VOICE MESSAGES
WHENEVER Output 100 STATE IS TURNED OFF; THEN ENABLE NON-ALARM VOICE MESSAGES

Would that cause the problem?

 

[Del91574]

I would start to suspect the phantom output and time delay.

Not following the specific application to only disable messages for 10 seconds.

 

[RichardU]

The application is this: Most of the time, I want to hear messages. But if I arm or disarm while people are asleep, I hit F4, then arm/disarm. I don't want to be "silent" all night long, because if someone forgets the alarm is on and triggers a protected zone, I want them to hear alerts so they have time to turn off the alarm before it activates. Maybe there is a better way to accomplish that.

As for the phantom output, that seems like a likely culprit to me as well. Is there any other way to disable messages for a limited time?

Thanks for your help.

 

[Del91574]

I have rules based on time for disabling the voice messages. The keypads still do the appropriate beeps (where sound is enabled on the units). Alarm messages always are active. Whether or not that is acceptable for your application, I can't say.

Maybe try a direct link in a rule vs. a phantom output trigger and try a longer time than 10 seconds.

You could also do a multi condition rule (armed stay or night, TOD, etc.) to disable the voices also.

 

[RichardU]

The keypads still do the appropriate beeps (where sound is enabled on the units).

Thanks. Even though I have five keypads, there are places in the house where they can't be heard.

For the benefit of anyone else watching, I found this article: How to Enable/Disable Non-Alarm Voice Messages

It basically advocates the phantom output method I've been using, and is probably where I got the idea. However, there are usually many roads to the same destination and I found someone else who wrote: "I have one leg of the speaker output running through a relay. On an F4 press, the output turns on for 5 minutes, breaking that circuit so all 8 speakers are off. The F4 button is illuminated for that 5min on all keypads."

I like that idea and may try it. The Elk will actually speak the words, we simply won't hear them. Interestingly, I was already using a version of that idea to do partial silencing. Here's how that works. There are times when I only want announcements played on the terrace level (where I work). So I have all of my speakers connected to two busses. Buss one connects the terrace level speakers, and Buss Two connects the rest. The speaker output connects to Buss One, and the connection from Buss One to Buss two runs through a relay.

 

[Del91574]

Be careful about having appropriate loading on the M1's outputs otherwise it's likely you can damage the board

 

[RichardU]

Thanks for the warning. I'm using the Relay Board which is rated for 7 Amps @ 28 VDC, 10 Amps @ 125 VAC. I'm thinking that should be enough, but would be glad to know otherwise.

 

[Del91574]

The problem is keeping the attached impedance within spec of the M1's output while using relays to mute specific outputs. Very easy to have issues unless specific care is taken.

If I'm doing multi-zoned audio and selectively muting on an M1, I usually prefer to install a M1TWA and then write a couple of rules. The added benefit is multiple volume control for each zoned output.

 

[RichardU]

Good reminder about impedance.

I like the idea of the TWA. I have a TWI which I have never used. I think the TWA came out right after that. Unfortunately I've already used J16 to connect my Relay Board. I guess I would need to replace my TWI with a TWA and my RB with an XOVR. I wonder if there is a market for any of the stuff I no longer need.

 

[narih1]

So I have an Elk M1 Gold installed and I am having the exact same problem.  Has anyone found a solution to this?
 
Basically, I have a phantom output (65) turn on for one minute when a specific key is pressed on the keypad.  I then have non alarm voice messages turned off whenever output 65 is turned on.  I use this to mute sounds at night when arming and disarming the system. 
 
It works but the problem is that the voice messages get queued and then the next time the Elk needs to speak something when it is not muted--it plays what it is supposed to speak and the previously muted message.
 
For instance, at night, I mute the system and arm it in night mode.  I also have motions sensors in the front of the home and the Elk speaks "visitor identified" when they go off.  Later in the evening, if the sensors pick something up and the system was muted I will hear a jumbled combination of "area armed in night mode" and "visitor identified".  If I don't mute via the phantom output, everything is fine.

 

[RichardU]

Welcome to the club. I installed a TWA, but still have the problem. It's not consistent, but it shouldn't happen at all. It would be nice if there were some way to clear out the queue.
 
 

... the problem is that the voice messages get queued and then the next time the Elk needs to speak something when it is not muted--it plays what it is supposed to speak and the previously muted message.

 

[snakevargas]

If you can't clear the queue, how about filling it up in the hopes that the queued messages you don't want get pushed off? Record some custom voice messages that are silence and have it say those while voice messages are off. It's hard to say not knowing the implementation.

 

[tmbrown97]

Very odd - I use one of those quiet buttons all the time, and have never had an issue with the queued messages.  I wonder what the pattern could be?  Firmware or the way the rules work?