I think this is not easily achievable. The problem here is the following.
The core logic
State change from OK → WARN - the core triggers the first notification (Nr.1) - the core sends this to the notification subsystem and don’t knows if there is are real notification going outside.
Next state change from WARN → CRIT - for the core this is the second notification for this problem.
And so on until the service reaches again the OK state. Then all starts again from 0.
But here is a solution for this problem 
With the rule “Notified events for services” you can define on a per service basis what should be notified directly from the core. That means you can say only crit and ok should trigger a notification.
With this setting also your count should not increase so quickly.
I don’t know how it counts with a status change like - ok → warn → crit - > warn → crit