Local Processing for Door Chime via SHM?

[necromancyr]

I’m trying to find some specifics (but failing via search here and via Google) to find out a way to get door chimes to work a bit better than they are right now.

I’m using:

• Plain old door sensors (from monoprice,https://www.monoprice.com/product?p_id=15270)) for my doors
• Dome Siren as a chime
  *SHM as the ‘chime’ activator

What is happening is random delays between a door being opened and the chime - and sometimes the chime going off repeatedly. Really want to get this as close to possible as a normal alarm system type beep and wondering if there are things I can do to make sure processing is happening locally for speed and just general debugging?

[RBoy (www.rboyapps.com - Making SmartThings Easy!)]

Delays could be the latency. You can improve that by rebooting the hub and doing a zwave repair. It helps if you have a zwave repeater in the mesh for reliability but it can introduce a slight delay at times.

Going off randomly - that’s interesting. How have you set it up?

[necromancyr]

It’s not really ‘random’ more like it chimes 2-4 times instead of once for a single door open, all in rapid succession.

[TonyFleisher]

I don’t think shm or dome siren (custom dth) run locally, so this setup would be susceptible to delay do to network/cloud latency.

[JDRoberts]

Parts of SHM do run locally as long as all of the individual devices are eligible to run locally.

[JDRoberts]

It’s not really ‘random’ more like it chimes 2-4 times instead of once for a single door open, all in rapid succession.

When that happens, have you checked the log to see if they’re actually multiple commands being sent in succession? Or if the sensor is reporting multiple trips in succession? Or neither?

[necromancyr]

Trying to check and replicate and will post once I determine. Quick look at logs looks like things are switching open and close correctly (no multiple opens before a close or rapid open/closing) but I need to have it happen to really confirm.

Is there anyway to check/make a device run locally? (Specifically, the door sensors I mentioned?) I’m going to be shifting over to Konnected soon (once I have time to finish the setup) so that MAY address the issue if they can process locally.

[JDRoberts]

What determines whether a device runs locally isn’t the physical device itself, it’s the device type handler (DTH) that you have assigned to that device because that’s the code that can run on the hub instead of in the cloud.

No custom device handlers ( including Konnected) can run locally. Only the stock types that are given to all customers.

If you go in the IDE, you can see whether the rule you have set up runs locally or in the cloud. But the only thing you can do to change it is to switch to using purely stock code. So at the present time that means the smart lights feature ( or a few bits of smart home monitor) and the stock DTH.

[necromancyr]

Got it, thanks. I’ll check that.

And in looking at the logs (recently) for one door, I can’t figure out the extra beeps. Seems if the door opens and closes quickly enough, it goes off twice. If I hold the door open it beeps, but doesn’t do it again when I close it. really odd.

[JDRoberts]

Got it, thanks. I’ll check that.

And in looking at the logs (recently) for one door, I can’t figure out the extra beeps. Seems if the door opens and closes quickly enough, it goes off twice. If I hold the door open it beeps, but doesn’t do it again when I close it. really odd.

That could happen if the mesh is weak and the device resends The message because it thinks it didn’t get through the first time.

Contact sensors are particularly complex because you know that there is something moving in the house at that moment. It is possible to have a set up so that the door itself is blocking signal as it opens. ( this is the stuff of which engineering 301 final exams are made. )