ioBroker
[enhancement]: Enable/Disable notification per Adapter / per Instance
No existing issues.
- [x] There is no existing issue for my request.
Related problems
Users differ in respect to notifications. Some users are happy to get any small information sent by a notifications while others are very frustrated by any notification and consider them to be spam.
Latest discussion see i.e. https://forum.iobroker.net/topic/74380/adapter-worx-landroid-v3-x-x/212 (and before / after this comment)
Description
I would suggest to evaluate a setting at admin to enable / disable notifictaions for an adapter or (if possible) for an adapter instance like setting loglevel is done at admin.
This would allow to control sending notifications at adapter / instance level without implementing such a enable / disable flag at every adapter which wants to support all kind of user preferences.
Currently disabling notifciations is possible using notification manager. But this requires installing an additonal adapter. In addtion sending notifications to the notificationmanger with the sole purpose to drop / delete them there creates unneeded load - so it would be better to block sending the notification at adapter level for those users which so not want to see those messages.
Additional context
No response
so it would be better to block sending the notification at adapter level for those users which so not want to see those messages.
I don't think that admin can do this.
Why? Admin can control the loglevel as well. And admin can - in combination with js-controller / adapter package code - set a flag to abort processing notification calls as early and with as less effort as possible.
One implementation suggestion:
- admin sets a flag 'notification disabled' at adapter or instace object
- call to senNotification checks the flag and simply return is no notification should be sent.
What has the loglevel to do with the notifications? Yes Admin could Set a Flag but the Adapter which Registers the notification would need to Respekt it eg worx Landroid or better centralized Controller. However, if we introduce sich a Flag I would tend to implementiert Handling in Controller + UI in Notification Manager and Admin maybe has a link to Notification Manager then else Logic will be Split again
I used Loglevel as an example to show how centralized admin can show and manage configurations which effect adapter (instances).
Forcing adapters to honor the flag is no good idea as devs simply do not implement it. Blocking notofocations must be possible even if the adapter does not cooperate. We do not rely on the adapter the handle logging too. In addtion implementing the logic at every adapter is redundant code which can be easily avoided.
Implementing the functionality at js-controller, more exactly at adapter code of js-conntroller repo, is exectly what I suggested abobe too.
Forcing all users to install notification manager even if they do not want to setep special handling is not the best solution in my oppinion. But if this is really the goal then the UI of notification manager must be changed to use some single line display like admin instance view. If you have many instances installed the current format getts much too long. And in addtion one cannot see (currently) which adapter / instances are disabled or active as an overview without openeing all areas.
Ah so for you it's only about showing in admin, but would still need a new flag at Instance level..
Forcing all users to install notification manager even if they do not want to setep special handling is not the best solution in my oppinion. But if this is really the goal then the UI of notification manager must be changed to use some single line display like admin instance view. If you have many instances installed the current format getts much too long. And in addtion one cannot see (currently) which adapter / instances are disabled or active as an overview without openeing all areas.
Yep, in the long term we wanted to play out more our decentralized approach and have some fucntionalities outsourced instead of the admin code taking care of everything. Else the whole notification stuff would have been an admin feature instead of separate adapter.
Ok lets repeat to mak it more clear:
a) If using the possibilioties of notification manager (fine grained filtering, sending to multiple targets etc) everythink is fine and completly OK
b) I am suggisting an ipprovement for the group of users which do not want to use ANY notification for an adapter. So I would like to see a simple notification ON / OFF display and switch at admin adapter (or instance) level. I do not expect (and I do not even think it to be a good idea) to add any fine grained configuration of notifications into admin. Notification manager is completly ok for this.
In addition: Technically I assume that every notification sent by an adapter must be processed by code inside notification manager / js-controller and forwarded toi the desired targets. So if i.e. using a flag to disable notifications of an adapter the code at js-controller/adapter could simply return if notifications for this adapter are disabled at all avoid any further filtering, forwarding etc and hance reduce load. This could be a feature if some adapter beleives it must be sending notification for every tiny change (i.e. 1% battery level change ...)