Can't figure out why response is so slow

I have a simple system...Aeotec door and window sensors, Aeon Doorbell and Zooz announcers. I have the latest update in my HE hub.
My rule uses a door/window opening as a trigger, and the announcers should ring once. When I first installed things (about 6 months ago), it worked fine, with almost-immediate responses. Now, however, there's a long delay between when the trigger happens (which logs in immediately) and the rings from the announcers. Sometimes the announcers ring several times before stopping. I even added to the rule to turn the announcers back off 1 second after they get turned on to try to stop the multiple rings.
While I don't understand what's going on, it seems like things were operating locally 6 months ago, but now are waiting for the cloud or something. (My internet connection works fine, with about 65Mbps down/6Mbps up.) I've tried rebooting the hub, and repairing the Zwave network. I've also tried adding two Aeotec repeaters, though my house is single story, 1750 ft, and gthe hub is central/high.
I've attached a log from this morning to show what I'm seeing (ignore Doorbell 1: it's the same Aeon doorbell as Doorbell 2, and I unplugged it to try to see what's going on.) As you can see, there's almost 30 seconds between the trigger and the Doorbell 2 ringing. In this case, the Zooz rang right away, but that's usually a longer delay also.

2019-12-28 10:12:27.849 am info52 Doorbell 2: status is off

dev:362019-12-28 10:12:27.497 am info52 Doorbell 2: status is off

dev:362019-12-28 10:12:27.056 am info52 Doorbell 2: status is off

dev:362019-12-28 10:12:26.327 am info52 Doorbell 2: status is off

dev:362019-12-28 10:12:23.824 am info52 Doorbell 2: status is Doorbell Ringing

dev:362019-12-28 10:12:14.847 am info52 Doorbell 2: status is off

dev:362019-12-28 10:12:08.055 am info52 Doorbell 2: status is Doorbell Ringing

dev:362019-12-28 10:12:06.674 am info52 Doorbell 2: status is Doorbell Ringing

dev:652019-12-28 10:11:44.441 am info53 Zooz status is stopped

dev:652019-12-28 10:11:44.433 am info53 Zooz switch is off

app:92019-12-28 10:11:40.543 am infoDelay Over: Off: 51 Doorbell 1, 52 Doorbell 2, 53 Zooz --> delayed: 0:00:01

app:92019-12-28 10:11:39.433 am infoAction: Off: 51 Doorbell 1, 52 Doorbell 2, 53 Zooz --> delayed: 0:00:01

dev:652019-12-28 10:11:39.362 am info53 Zooz status is playing

dev:652019-12-28 10:11:39.353 am info53 Zooz switch is on

app:92019-12-28 10:11:39.279 am infoAction: On: 51 Doorbell 1, 52 Doorbell 2, 53 Zooz

app:92019-12-28 10:11:39.241 am infoDoor Opened Triggered

dev:482019-12-28 10:11:38.961 am info11 D Front was opened

Silly question, but have you rebooted recently?

Yes, I've tried rebooting and shutting down/restarting the hub. No difference.

Interestingly, I can go into the Edit Devices window and tell the Doorbell 2 to play its sound, and it does so immediately, without delay. But opening a door still exhibits the slow response described above.

What 'announcers' are you using?
If they are not cloud devices then your internet connection will not have any affect to the rule execution.

1 Like

I have two Aeotec Gen5 doorbells (I don't use the button, just the speaker to ring a chime when a door is opened). The other is a Zooz multisiren, which I use the same way.

Since there's a (seemingly) arbitrary delay to both types of announcers, it doesn't seem like the problem would be in a device driver.

I don't know if these are cloud devices or not (or even how to tell if they are). That would probably be helpful to me, if someone could instruct me on that.

They're not. Could you post your rule that uses the "announcers"?

I've no knowledge of those devices.
If they are zigbee or z wave then I would suggest they run locally on your hub. WiFi, then maybe, maybe not.

Are you using one of the built-in sounds or is it a custom sound file you are playing? I just got the newer generation (6) and it's totally different. It's sitting here on my desk - next in the installation queue.

Also, it would be helpful to see your rule.

Sorry I'm so dumb about this stuff, but I don't see a way to copy the rule to paste it in a post. The rule was made in Rule Machine 4. I can see/edit the rule in the "Devices" window, but it doesn't look like I can copy and paste the text. Can you tell me how to do that?

Good to hear that they are local devices. I had assumed they were since they reacted so quickly early on. But then I'm at a loss on what's causing the delays (and multiple rings).

Previously you said that when you manually activate the Chime they work quickly and correctly (no repeats).

You also stated 6 months ago everything worked well but now there are problems. In between now and then I'm going to guess you have applied updates as you're running RM 4.0 and your system has had changes.

I'm surprised nobody yet has suggested doing a restore as lately that seems to be the go to for "hub slow" problems rather than acknowledging it's a rule having issues which means either that rule, rule machine or the underlying DB is just bad.

Yes, I've applied updates as they became available.

If "restore" means either reboot the hub or shut down and restart, I've done those things, along with multiple zwave repairs, but no change. Is there a more basic restore that I can do?

There's a whole encyclopedia of information and issues around "slow hub"

There's a un-official "backup -> soft-reset -> restore" process that some have been using. I've never had this problem with my 2 hubs so I've never used it so I'm not a good resource for "howto" info on this.

Thanx much! I'll spend some time going through that & see what I can find.

In reading your explanation of the situation, I’m also wondering about the sensors. Since you can trigger the chime and it acts as expected, what happens if you substitute a virtual switch in your rule for the sensor. If you then turn on the virtual switch, does the rule fire as expected and the doorbell chime quickly and only once?

If the answer is yes, then I would turn my attention to the sensor. Is it responding instantly if you watch its device details? Is it “bouncing” between open and close?

If the answer is no, it still doesn’t chime quickly when manually activating a virtual switch, then I would turn my attention to the rule. Maybe rebuild it and if it’s still slow, then turn focus to a possible corruption in the database that needs to be repaired with a restore.

But if the sensor is indeed slow to respond, then I would focus on whether or not you have enough repeaters to keep the mesh stable. If that is affirmative, then have you tried a rebuild of the mesh?

The time of the trigger from the sensor is in the very first post. It shows the sensor was triggered and then.......wait for it..... wait.......... rule executes.

Can’t tell from a log when the sensor was physically triggered, vs when it registers with the hub that I was triggered. That’s what I’m suggesting to look at, by observing the device details for the sensor.

For troubleshooting a sensor physical to HE recognition yes I agree this would be useful. Yet with the issue being time from HE recognizing the trigger to executing actions is past the point of opening/closing a sensor to see when HE see's the sensor. It sees the sensor and just sits there.....

What device are you using a phone/ tablet or a PC /Mac? Basically you want to do. Screen shot of the rule. Ideally use the sniping tool to copy just the rule and also the logs as that's the best way to see it.

I may have solved my issue.

First, I excluded one of my two Aeotec Doorbell speakers, then re-added it. Even though I only did one of them, that seemed to speed things up, but they were still erratic and would sometimes do multiple rings.

Then, I paused the "notify-upon-door-opening" in the Rule Machine app-maker and created a new one in the Notifier app-maker. So far, I've have no delays or multiple rings.

Maybe the Notifier app calls the doorbell speakers in a different way than the RM app did...
I'll watch it for awhile and see how it goes.

Thanx for the responses.