The entities you are using have been introduced because people got confused buttons did not have entities, and because the original events that buttons emit are harder to use in triggers (i.e. you need to read documentation for it to know what events they use).
Initially I was very happy that they got introduced. That is, until I got the chance to actually use them, and discovered the design is seriously flawed. The flaw being: the state does not reset to idle shortly after triggering. I immediately thought of all the ways that may fail, and posts here on the forum suggest that is indeed the case.
As a consequence of the design, the trigger you need to use is not for a specific change, but for any change on the entity. The assumption made there was that this change could only have been a button action. But that isn’t true, because it could also be another attribute change, or what you describe: the device returning from unavailable or unknown. Which you then have to protect from.
It also breaks consistency: when normally you trigger on something specific happening and then check some conditions and do an action, you now need to trigger on a generic change. That is requiring you to use a choose in the action block, and makes it impossible to do something useful with the condition block. So the automation will be ome complex fast.
While maybe you could protect against this by checking for unavailable, unknown and any other change that may not be a button, this is even less likely for you to work because it always goes unavailable for you. Or maybe it does. But that is the point: the new entities are causeing more confusion than they solved.
So, TLDR: my advice would be to ignore the entity and trigger on the actual events coming from the buttons by using an event trigger, or use a device trigger if there are implemented on your device (even though they are advised against. It is the only reason I still use those). These should not be affected by the problem.
ps. it is not normal for wifi devices to go unavailable after triggering an event. I’m guessing it was an attempt by the integration builder to mitigate the design flaw in the entity. Unfortunately it does not solve it completely. Did you already use this with the state trigger:
not_from:
- unknown
- unavailable
not_to:
- unknown
- unavailable
Although theyse might have worked when the button does not go unavailable, they probably will hurt in your case, because they might always go from unavailable to single press?