Correct! Still get the event on the second press.
I’ll play around with the other triggers “Switch opening opened” and “switch light turned on” as workarounds since HA is receiving those signals, but it feels like a bandaid solution if I want to trigger double/triple taps from the “off” position from the get-go.
Having the same issue. Awaiting an update to address this.
If you and @stefan814 haven’t already, please fill out the form in this thread and include the first 12 of the ieee of affected device(s).
Done 
Also seeing the same issues except I’m using Z2M and Sonoff. I have a very simple HA automation that is set to toggle a hue bulb if the switch is double pressed. If it’s been more than a minute or two (maybe longer, I haven’t done any sort of scientific testing on the timing) the switch no longer sends the double tap even an must be single tapped to turn it on at which point it will send double tap events until it “sleeps” or times out again.
The switch is otherwise operates as a normal single-pole switch that controls an overhead light–I’m just trying to use the smarts of the switch to also control a nearby Hue bulb.
I will also fill out the form linked above.
EDIT: Tested the “time out” length some more and it looks like its 90 seconds (using the ol’ Mk.1 eyeball and a stopwatch across 3 or 4 runs of the “test”). The double tap event registered so long as it was issued all the way up to ~89 seconds. At ~91 seconds no response and had to turn the switch on again by single up tap.
I’ve had similar problems, but a single up tap sometimes doesn’t do the trick to re-activate double-up taps. Sometimes I have to hit down first before anything else will work. Other times it has to be up before any down commands will go through.
Yeah it really feels like something in the switch is going to “sleep”.
Hopefully this is all just a config issue since there’s such a variety of platforms people are using and not something related to the signal/routing/pairing issues mentioned in other threads. I tend to think not since my switches otherwise work fine and respond near instantly if I send a command from HA–it’s just when the switch is unused for ~90 seconds that tap events FROM the switch aren’t being sent/received.
I’m in a similar boat. Every morning I wake up to Zigbee problems. A handful of my switches seem either go to sleep or become unavailable where they can’t be woken up remotely. This causes binding to break and also causes routing instability between other Zigbee devices. I have blue switches bound together in 3-way and 4-way configurations that will simply stop communicating, even if they all show an okay LQI. I keep changing out switches, only to have issues pop up somewhere else. I’ve never had any Zigbee problems prior to this. I’m hoping for a firmware fix soon. I love the look and feel of these switches, but it’s honestly starting to wear me down.
Using HA and Zigbee2MQTT
Coordinator: SONOFF Dongle P
Coordinator FW: 20220928
Fill out the form:
@EricM_Inovelli – can you take a look at this when you have a chance (I know you’re buried with some of these other issues)? This seems to be an issue – I’m not sure if it’s related to the network/routing issues (ie: maybe commands aren’t being received due to network errors).
Further observations…it’s more random. Sometimes the double tap up event will work correctly even after the switch hasn’t been used in quite some time (like hours) but then sometimes it’ll just go right back to needing to be “awoken” with a tap up to turn on before it responds to double taps.
I tried setting QOS to 1 and 2 but that didn’t affect anything. As all 20 of my switches are in the defective lots, this may just be some sort of signal issue even though by LQI is 120 for this particular switch; it was very stubborn to get initially connected.
The one switch I had installed overnight timed out and marked itself unavailable (ZHA, ezsp on Sonoff bridge). Pushing a button on the paddle woke it up, and it rejoined.
Smells like a zigbee problem I’ve seen in the past with some devices where they don’t handle monitoring clusters properly? Don’t remember the details, but the shape of it is something like “this device would generate traffic if it was being effectively monitored and reporting, but that’s not working, so there’s no traffic, and its route is being timed out.”
Main symptom is a device swallowing the first event as it wakes up.
I’ve don’t some testing over the last week and the switches continue to act randomly. I currently have 7 installed through ZHA with the following mix of log results from a simple “Up press”:
Starting from a “lights on” position (and waiting an hour) yielded similar results with rare instances of no response from the switch until the paddle was pressed up seemingly turning the switch on.
My hope would be the following:
Not sure if it’s helpful or not, but one of the five switches I set up this weekend would not send ZigBee events at first.
I got the switch sending events by using the “Reconfigure” option in the ZHA device dashboard under “Device info”. As soon as that ran the switch started sending events on click, double click, etc.
My setup:
I tried this here with my Z2M setup and it didn’t work. 
For folks with TI based coordinators there is a firmware issue causing events to be sent to endpoint 0 (ZDO endpoint) which is incorrect. (SI coordinators get more info and can kind of hack around it) You will probably see a ton of parsing errors in your logs when you should be getting events. This has been verified with packet captures. Details were shared in another post.
The 2.0.7 firmware update seems to have fixed the issues I was having with this for both bound and non-bound switches.
I’m still seeing issues unfortunately
Still requires a wake press before firing a zigbee event and unable to decouple the “switch opening” and “switch light” from an initial up press. Was hoping to have an “up press” only fire the zigbee event and have the “switch opening” and “switch light” (which appear to be directly related since it’s a dumb light) operate as standalone entities.
Things got less bad for me, but I have 90% switches from the batches with the signal problems. I put in non-connected bulbs for the meantime.