It’s similar for me, and if the device is Android, it must have unblocked TCP 5228 output to Google servers.
As we know, all these notifications are based on the Google system Firebase Cloud Messaging, of course we are talking about Android, Apple has its own. 
As for delays, I also had them once, from a dozen or so seconds to even 30-60 m. So much so that I gave up on ewelink notifications based on Google.
And I am using webhook from ewelink web for private webhook serving front.
Macrodroid has a similar solution, but it is also based indirectly on Google and can also have a delay, although usually on average 10-20 seconds max, although most of the time it works quickly and correctly.
There are offers on the market for webhook services, most of which are paid unfortunately.
It works on the principle that ewelink makes a webhook call to the service provider’s server (not Google) and the latter, through an appropriate solution, transfers the data to your host, which may be behind NAT/Firewall because you maintain the connection to the server, so you do not have to expose yourself to the world.
Then all you need to do is implement how to process this data and spit it out as a usable notification.
There are also commercial applications with free plans that implement notifications…
It doesn’t matter what we use, the important thing is that the entire ecosystem is not clogged and does not rely on Google. In this way, you can eliminate the problem of delaying ewelink notifications based on the Google solution.