Thanks, that'd be great. I'm probably using the device in a somewhat uncommon way (no load, to command a different switch). If I were using it with a load and sending commands to the device, I doubt if I'd notice any problem whatsoever.
I thought the filtering was a little far-fetched, but it's very curious why I'd see different data with association group 1 on Hubitat vs. SmartThings.
Is my understanding correct that parse() is the lowest-level function that the driver has?
I’m going to take a look at this tomorrow.. This might be fixable with a change in the z-wave associations.
ThisdevicesupportsAssociationCommandClass(3Groups)
• Association Group 1 supports Lifeline, Binary Switch Report
• Association Group 2 supports Basic Set and is controlled by pressing the ON or OFF button
with the local load
• Association Group 3 supports Basic Set and is controlled by double pressing the ON or OFF
button
• Each Association Group supports 5 total nodes
Worth a try. My driver does not add the hub id to group 2. Easy enough to do, of course though.
If you get time to look at it before me, let us know as I'll need to do the same thing. 
If not, I should get a chance to test it later this week.
EDIT -
I just realized that this post sounded like group 2 solved the issue. I was just trying to say that I had already tried group 2, which made (delayed) basic sets visible, but not basic reports.
Original -
Yep I was able to add association group 2 and it was at that point that I could see the basic set on Hubitat.
But that type (and timing) is different than the basic report, which I saw on Smartthings with association group 1.
Is there a diagnostic mode or something where I can see the timing of Z-wave packets received/processed? [Before they are transferred to parse()]
Not that I know of / kinda / I wish...
If you have a C7 hub you can try to watch the zwave logs (settings - zwave details - zwave logs). But full disclosure - those logs DO NOT show everything, and often don't work at all for me, but thought I would mention it anyway.
Yeah, it looks like the zwave logs are transmit-only (from the hub).
Oh well...did you have a chance to check out your switch?
Nope, no time yet. I work from the office, so not home much outside the weekends.
No worries, I'm the same.
I just looked, and on the Enbrighten dimmer there was nothing I could do to get the basic set come in any faster than the multilevel report. Both showed up on the hub at ~1-2s after press.
Breaking out the sniffer, when I single tap I see a broadcast packet and then nothing for the 1-2s until the S2 encapsulated msgs come in.
So I decided to try it paired with no security. Same thing. Still 1-2s before the device reports single tap on/off.
Sniffer shows the basic set, multilevel report, and central scene notifications all come from the device at essentially the same time (within 20ms of each other).
So this can't be a hub issue. It simply can't report the data until the device sends it after all...
It could still be a device configuration issue maybe, but the sniffer doesn't lie - as currently configured the device isn't sending any updates for 1-2s after a single tap.
If it was faster on ST, I don't know what they were doing in the config to make the device cough up the reports faster. 
EDIT: Oh, and adding the hub to assoc group 2 made no difference. The basic set comes in at the same time as the multilevel report.
From what I understand in discussions several years ago in ST community, If/when that broadcast arrives at the hub, you can request a status report and (maybe) get the response back sooner than the unsolicited one.
(This was a "trick" used to get closer to instant status updates on those older switches that didn't support it.)
That's interesting. I didn't know that. Learn something new every day!
Pretty klugy, but getting the multilevel (or other) reports back only takes maybe 50-100ms (I just did it to see).
So requesting a report on receipt of the broadcast packet would likely make the status update much faster on this device.
I personally don't think it is worth coding that workaround into the hub, though.
Here is a thread with discussion about it that I found about it (the context was the old z-wave GE devices that didn't send unsolicited reports due to patent, I think):
Its funny because when Jasco transitioned to zwave plus they fixed all of the reporting issues.
Now on the new Enbrighten they introduced a new reporting delay when they converted over to Central Scene reporting.
Some of that makes sense I guess. It has to wait a little bit to see if you are single/double/triple tapping after all. But the 2s this device takes to report sometimes is rather long. Sometimes reports in 1s.. Sometimes 2s.. Seems there may be some reporting 'quirk' in their firmware that makes it take an extra 1s sometimes.
This is interesting. Now I need to go read up on the zwave protocol, I hadn't come across broadcast packets yet.
Sounds like the broadcast packets are available to act on at the device driver level?
Actually, no. Broadcasts are not available at the driver level.
Boo, that stinks. I guess it's nice to finally understand what's going on and why the behavior is different.
But...sounds like I'll need to use a different switch for this light. Or I guess keep the SmartThings hub running to handle it.
Do you think it there would be a broader use-case for making broadcast packets available to the driver level? Future hub feature?
Do I? No. Broadcast packets were never meant to be used that way, or in drivers at all, really.
I think the answer is the one you stated - get a different switch/dimmer that does NOT use central scene reporting. The older non-Enbrighten GE ones would work as well as many others.
Any devices that use central scene reporting or can act as 'scene controllers' will have similar delays for similar reasons - maybe less, maybe more, than the GE but almost assuredly more than a non-central scene device.
Is a "broadcast packet" the same thing as a "hail"? If not, disregard the rest of this post. 
It looks like the Hubitat CommandClass stuff supports 0x82/HailV1 .
https://docs.hubitat.com/index.php?title=ZWave_Classes
Weird that it wouldn't get kicked up to the parser()...but now that a clearer picture of the issue has emerged, searching the forums is becoming easier. It appears that others have had this issue with the C7 and Leviton DZ15S.
Also, in each of those posts, it actually appears that the hail does actually make it up to the driver. Since I'm not seeing the hail, I wonder what's different.
@mike.maxwell wrote that something regarding the hail would be fixed in 2.2.3, but I'm on 2.2.4.158:
One of the posts mentioned looking at the "Data" section of the device details. I do note that they had 0x82 in their outClusters, but I do not. Could this be the difference? How do the inClusters and outClusters lists get populated? I believe they are CommandClass mappings?
What packet is it?
Some devices send a NIF as soon as there's user initiated activity (such as pressing a switch).
A common trick in the pre-instant status days was for the controller to respond to that NIF packet and send a poll (basic get, binary get, etc).
It was used a lot on Vera and I used it on SmartThings for some odd battery temperature sensors that don't send a wake up packet when they are manually woken up and the default wake up is 28 days! Instead of a wake up packet they send a NIF when they are manually woken up. That made them difficult to configure. By responding to the NIF packet in a driver they were configurable.
When I moved those devices to HE on a C4 running 2.1.something a few years back I believe this trick still worked (else I never would have got the devices working how I needed them to).
A few months back I moved them to a C7 running the latest firmware and that trick no longer worked, the hubitat.zwave.commands.zwavecmdclassv1.NodeInfo that I was previously using couldn't be saved in the C7 editor.
I asked @mike.maxwell if that was a recent change on HE and as far as he could recall NIF's never made it into parse() on HE so that would never have worked ..... I didn't have time to investigate further and moved on (now I configure them based on any report received e.g. the first temperature reading).
No idea if that trick still works on SmartThings, a quick look through the SmartThings source on github doesn't throw up any use of that CC nowadays so perhaps it was removed.
The OP would need a sniffer to see what's different on SmartThings, but I wonder if they moved that CC to something that's handled at the platform level directly i.e. as soon as a NIF is received (outside of Inclusion / Exclusion) they do a poll for basic get.
That could explain why there's a quick basic report on SmartThings following the switch press ....
Download the Hubitat app
