Thanks everyone for digging into this.
Agree, normal and nominal notifications should not be "visual" or "sound".
Notifications management in openplotter was designed in early days of Signal K and the conception of notifications in Signal K has changed over time so I suppose this moment was inevitable.
At this time OpenPlotter is not prepared to manage multiple notifications for the same state, it is prepared for a single notification per state and the management of state changes. Personally, I prefer the second logic because knowing when that alert situation occurred for the first time is very important and that is lost in the first logic. Furthermore, it seems like a waste of resources to me because thousands of identical messages are generated without relevant information. On the other hand, the first logic allows the disconnection/connection of the listener without having to do a first reading of the full Signal K model, but it seems to me to be an advantage that is not worth it.
I guess this has already been discussed and all we can do is adapt to it. We will need some time to modify openplotter-notifications app to the new situation, so it is best for affected users to uninstall this app until further notice. We will try to turn the problem into an opportunity and try to store the time and value of the first detected notification.
Luckily only "visual" is defined in these multiple notifications, if "sound" had also been defined it would have been fun...
Agree, normal and nominal notifications should not be "visual" or "sound".
Notifications management in openplotter was designed in early days of Signal K and the conception of notifications in Signal K has changed over time so I suppose this moment was inevitable.
At this time OpenPlotter is not prepared to manage multiple notifications for the same state, it is prepared for a single notification per state and the management of state changes. Personally, I prefer the second logic because knowing when that alert situation occurred for the first time is very important and that is lost in the first logic. Furthermore, it seems like a waste of resources to me because thousands of identical messages are generated without relevant information. On the other hand, the first logic allows the disconnection/connection of the listener without having to do a first reading of the full Signal K model, but it seems to me to be an advantage that is not worth it.
I guess this has already been discussed and all we can do is adapt to it. We will need some time to modify openplotter-notifications app to the new situation, so it is best for affected users to uninstall this app until further notice. We will try to turn the problem into an opportunity and try to store the time and value of the first detected notification.
Luckily only "visual" is defined in these multiple notifications, if "sound" had also been defined it would have been fun...