Smoke Alarm Detection Failed

Just a heads up in case you were counting on this to work. I have 4 cameras and none of them alerted me to the smoke alarm that went off for about 3 minutes yesterday! Luckily it wasn’t a real emergency.

How far away were they from the alarm device?

Also, I just learned that they may have a 5 minute cool down limit on the alarm or sound events, so if a camera is in a commonly noisy environment, it may not detect an alarm sound if it was triggered by something else within the last 5 minutes. I haven’t thoroughly tested this, but that’s what I seemed to experience this weekend when I was trying to set it off.

Assuming that’s accurate, I think that’s something that should be updated. The camera should analyze every sound locally and should have a separate cool down or no cool down for the alarm vs any other sound.

For some reason, Cam Plus only removes the cool down for motion events and not for sound events, so it would only help if an alarm happens to occur during a motion event too, because if there is no motion, I believe even Cam Plus subscribers are limited to a 5 minute cool down on sound events.

This means that if there is some other sound that happens, a camera will trigger a sound event and then ignore other sounds for the next 5 minutes (unless there is also motion). So if a dog barks and then 1-4 minutes later the alarm goes off, there would be no notification immediately because it hasn’t been 5 minutes since the last sound event yet.

I think that it a fairly serious concern. I would expect the cameras to internally analyze all sound 24/7 and always alert if any of them ever sound like the CO/CO2 alarm sound with no cool down period preventing said alert.


This is not at all how I would expect cam plus/unlimited to work. This is extremely concerning to be totally honest.

I think it would be reasonable to expect a dog to bark at an intruder before they broke any windows. My dog doesn’t bark often, but I would care way more about the window breaking event. Just an example off the top of my head.

I completely agree! Is this something we need to vote for as a feature request? Or do you think this is a potential bug?


After seeing what Wyze’s initial response was with cloud events being deleted when a cam is added to a new account, I’m a little worried that this won’t be seen as a cause for concern. Thankfully they charged their minds with the cloud events, so hope remains.

For what it’s worth concerning the detection of smoke alarms, I semi frequently set my smoke alarms off. I hardly ever get a notification from Wyze about it. I honestly can’t remember one time I was notified. My cams are about 10-15 ft away from the alarms and are in a window mount. The alarms are obnoxiously loud, they can be heard outside the house. This causes me to believe that the cams should be able to clearly hear the alarms. The cams in question are 2 Cam v3s, on cam unlimited.

I have sound events off for the 2 Cam v3s. Would that cause the alarm detection not to kick in? Sounds events are on from the pan v3 but no notifications.

One thing to note is that while reading this thread (before creating this post) I went to check my cam’s settings and noticed that alarm detection settings were off for both my cam v3s. This is far from the first time I’ve noticed that they are off, when I remember turning them on. Is there potentially a bug with some cams that turns off alarm detection?

I will do some testings tomorrow to see if they will alert me and double check the settings before testing.


For those curious if I’m constantly trying to burn down my house or not: All 3 Smoke alarms in my house are in a centralized location just outside the only bathroom. Long hot showers result in a very steamy bathroom. When I open the door the steam rushes out and sets the alarms off. I’m renting so I haven’t cared to deal with it, and now I’m moving so it’s not my problem :joy:

1 Like

I think it is an oversight, rather than a bug. In this case, I believe a wishlist request would be needed. I can say that when I first noticed this, I DID talk to an employee about this in a casual conversation sometime earlier this spring but I don’t believe there is anything currently on the roadmap to fix this.

I do have to admit that I am not 100% that the alarm doesn’t have it’s own separate cooldown that is separate from the other sound events. I was doing some sub-intentional testing over the weekend about it and will need to do some more thorough testing to verify it first, but I do know that sound events are definitely limited to 12 second events on a 5 minute cooldown, and that is a flaw itself that I think should be resolved with Cam Plus (which only extends motion and removes motion cooldown, not sound events), and since CO/CO2 alarms are an extension of sound events, I expect it’s the same, and I did verify the camera I was testing on had a 5 minute cooldown between alarm detections, but I should’ve absolutely checked if a sound event enforced a 5 minute cooldown on alarm notifications too or if alarms had their own separate cooldown. It didn’t really cross my mind to verify that before now.

If anyone tests that before I get around to it later next week, please let me know what you find. Then, once absolutely verified, we can request it on a wishlist and promote it that way to start with.

Might also be a good question to add to an AMA in the future.


I tested this a long, long time ago when sound AI types were undergoing beta testing. I found that alarms appeared to be one of the many AI types under the sound object (vs motion object) and no cam service removes the 12s event limitation and 5m cooldown restriction for any sound events. We have a wishlist topic that covers this issue, but it’s labeled probably-not:

Remove cooldown on sound events only


I’ve seen the notifications sometimes when testing my smoke detectors, but oftentimes NOT. willy_nilly

Wyze should update the settings page to display the algorithm used to determine when a notification is sent. It should work when notifications are OFF, and, not be subject to the “sound detection sensitivity” setting,