Performance issues w/Motion Sensor

The latency from actual motion to it being visualized on the device type tile/UI on the mobile app = about 60 seconds. I was expecting 1-2 seconds. Any info on how/why this might be happening? Just using the out-of-the-box viewer for the motion sensor status.

FYI, it is quite inconsistent. Sometimes it is almost instantaneous, other times as long as 60 seconds.

@rickbullotta - Please send an email to support@smartthings.com to open a ticket and start troubleshooting - that kind of inconsistency is atypical - you should generally see motion events from the SmartSense Motion sensor immediately.

The Reset time (no motion) is 60 seconds after motion.

Thanks @pmsmaker - that’s exactly what I was seeing. So, to summarize, expected behavior = nearly immediate motion detection, 60 second period for stabilization/inactivity before returning to reset state.

Yeah! - That’s what I got from Andrew, the keymaster, @ST a couple of weeks ago.

I AM THE MASTER OF KEYS.

FFFEEEAAAAR MEEEEEEEEEEEEEEEEEEEEEEEEEEE

queue spooky music

Is there somewhere that could be documented? I’m not really sure where. Possibly a page for each SmartDevice going into some level of technical detail about things like this.

Another thing that comes to mind is the temperature specs for the multisensor (+/- 2 degrees).

As an added bonus, could the motion sensor timeout be configured at all by the user? Is that even potentially possible someday in the unpromised future?

I finally configured my first motion sensor thingy to control a fan connected to a z-wave switch in a room. The motion sensor turns off the fan after 5 minutes of inactivity. Oh, I used the “light follows me” smartapp btw. Anyways, I check the log on the android app and I keep seeing the app sending an ON signal to the z-wave each time motion stops and resumes within the 5 min window. The z-wave switch probably just ignores the command since it’s ON already but it floods the log with stuff with no way of filtering it (I think). Is this log accessible somewhere else?

Thanks for the help :slight_smile:

Tangent: I get inconsistent response time for switch state change confirmations on Z-Wave dimmers. They react immediately to an “on” or “off”, but the GUI says “TurningOff” or “TurningOn” for anything from 1 second to 10 seconds.

I also experience major delay in the “Flash When” SmartApp, trigging a flash of a Z-Wave device from the SmartPower (ZigBee) module manual push button switch.

Is there somewhere that could be documented? I’m not really sure where. Possibly a page for each SmartDevice going into some level of technical detail about things like this.

Another thing that comes to mind is the temperature specs for the multisensor (+/- 2 degrees).

As an added bonus, could the motion sensor timeout be configured at all by the user? Is that even potentially possible someday in the unpromised future?

yes to all of that. We’re working on launching a whole new preferences menu for a device-by-device configuration. Configuration of temps by multi, motion timeout’s, etc etc. It’s going to open up quite a bit of customization to different devices.

Sounds like wonderful new features coming our way… really appreciate them!

I would like to repeat my request, though, for the ability of a Device to have multiple simultaneous Main tiles visible in one group (and/or shortcut links). This will make multi-ability devices much more flexible (i.e., I need one tile’s main image to be Open/Closed, and another tile for the same Object Thing to be showing temperature.

Either that, or somehow permit a single Thing to be added multiple times to the Hub.

This functionality will open the door for creating “SuperThings” like X10 bridges that really represent and control a bunch of real world Things.

Thanks?
…CP

This functionality will open the door for creating “SuperThings” like X10 bridges that really represent and control a bunch of real world Things.

That’s probably the strongest argument for it so far. It also helps cover things like a dry-contact box for built in open/close sensors

That’s probably the strongest argument for it so far. It also helps cover things like a dry-contact box for built in open/close sensors

Agreed! Thanks!