I had written everything below before remembering that I did have communication issues with mine at one point. The issue turned out to be that the device seemed (from the ST side) to support network-wide exclusion and inclusion, and I had excluded it and then re-paired it in place. Communication between the device and hub was shoddy after that inclusion, especially for anything coming from the device. The solution was to bring the hub next to the device, exclude it (I may have had to do a general exclusion, and I remember doing the factory reset on the device which I think is ten quick taps on the up button), and then re-include with the hub in close proximity. If you excluded/included at a distance, I would start with a clean re-pair at close range.
I think first thing is to nail down where the point of failure is. If you’re watching for motion events to pop up in the app, then the full chain for the event to get to you is Device => Z-Wave Mesh => ST Hub => ST Cloud => ST App. There’s definitely lag in those last two steps, and there’s really nothing we can do about it. The device history in particular is terribly laggy.
Easiest thing to knock the app and cloud out of consideration is to set up some routines (the native ST ones) that run local based on motion. Lamp turns on when motion, off when no motion. You should see fairly immediate response if the Device through ST Hub portion of the chain is working efficiently, since everything really is local at that point.
Alternatively, if you have the CLI set up, or are willing to set it up, then the logcat function will definitely narrow things down to the Device through ST Hub portion. The CLI logging shows an entire driver at one time, which will make it tough to isolate one device, so you may want to temporarily divide your switches between my generic GE driver and the one specific to the motion switches so that the switch you’re testing is alone on a driver. Both drivers handle motion events the same - the only difference is whether the key config parameters like occupancy mode show on the detail view. For every motion trip, you should see a burst of log lines posting immediately - an incoming z-wave message followed by an event being posted. If you see both, then everything is being handled properly through the hub, and the issue is cloud/app. If you see z-wave but no event (or an error message), then I need log lines to see why the driver code isn’t handling what your switch is sending. If there’s neither (or both post but slowly or intermittently), then it’s the device or mesh. I’d be more inclined to say mesh if it’s slow or intermittent, and device if you don’t see anything from the device except in response to a command from the hub.
I’m sure there’s a body of knowledge regarding troubleshooting the device in this thread - I’m a newcomer to these devices and haven’t read through this thread to get caught up to date. If the issue is with the device, then I could see possible benefit in going through the settings and toggling them to a different setting and then back. The driver attempts to send the parameter change every time you toggle it (you don’t have to exit the settings menu anymore). If you have the CLI with logging running, you should see 3 z-wave commands for each parameter toggle - sending the parameter change, sending a request for the device to report the parameter value, and the device sending back the current value for the parameter. Edge doesn’t allow me to update the app settings menu based on the value that the device sends back, so it just shows what you last attempted to set the device to, but seeing that return message in logs would be confirmation that the parameter change worked. For the dedicated motion switch driver, the parameters that show on the detail view ARE updated based on what comes back from the device, and are also queried fresh from the device if you swipe down on the detail screen to trigger a refresh command, so you can trust the values displayed as actually being programmed in the device.
Assuming you confirm that all of the config parameters are actually set how you want them at the device, the other thing that I could see causing problems with device configuration is if you somehow knocked the hub out of association group 1. If that were the issue though, I wouldn’t expect the device to provide ANY updates to the hub unless asked for them. I don’t have association group 1 in the settings specifically so people don’t accidentally mess that up, so I don’t think this would be your issue unless something went wrong during inclusion or you did something crazy.
There really aren’t any tools in ST to troubleshoot the mesh - even less so on Edge right now. The two options for getting serious about investigating your mesh are adding a z-stick to your network (also useful for firmware updates) or using a zniffer to see the commands going to/from a particular device. Those options are going up a few levels in complexity though.