Notification infrastructure

Development
1

Hello developers,

I have the following proposal for a notification infrastructure (excerpt from the bundle readme):

Notifications

This bundle defines multiple interfaces for the notification infrastructure.

Notifications are runtime events and are not stored / restored on startup.
They always have a maximum life-time and a priority level.

Most notifications are just streamed events, they appear once on each interested
notification consumer and are gone after the life-time is over or a user
has dismissed them.

Other notifications express an urgency, and need to be user dismissed and may
even re-appear after a time. For example a “short on storage” notification.

A notification consists of:

  • a unique ID
  • an integer priority level with certain values predefined,
  • a maximum life-time before the notification is auto-dismissed,
  • a list of scopes (a scope may be “binding”, “system:storage” etc),
  • an urgent flag: If that is set, the notification need to be actively,
    dismissed by the user and may even re-appear after a time,
  • a notification label
  • a notification html message
  • an optional image url
  • optional rule action UIDs.

The general flow is that notification providers push notifications to a registry
and notification consumers are notified. The notification stays in the registry
until the maximum life-time has been reached or is dismissed by the user.

Notification consumers

A notification consumer listens to incoming notifications and expose those.

The user can restrict a consumer to specific notification scopes
(via regex patterns). So that only urgent system notifications
reach your mail-box for instance. A minimum notification priority can be configured.

An example for a consumer is the org.openhab.core.notification.rest bundle
which allows a web-user to list the last x notifications or get notifications
in real-time via websockets.

Another example is the org.openhab.core.notifications.gcm bundle which exposes
notifications via the google cloud messaging service, especially useful for
Android phones.

A consumer is not allowed to cache any notifications.

If a new session to a consumer is opened (a phone registered to the
google cloud messaging service or a REST call happens), all still valid
notifications from the registry are (re)exposed.

Notification provider

A provider adds new notifications to the notification registry.
It can overwrite existing notifications by using the same unique id.

Some notification scopes like “system” can only be set by system services.

An example for a notification provider is the
org.openhab.core.storage.notifications bundle which pushes urgent notifications
when the runtime state could not be synched to disk (low disk space, write errors).

Another example is the org.openhab.core.notification bundle which pushes
all “warning” and “error” log messages.

Notification registry

The registry accepts a few configuration parameters:

  • A block list: A user can block certain notification scopes. Useful if a binding
    is abusing notifications to call for attention.
  • a reappearance time value for urgent notifications that are not yet dismissed.

Would be interested in feedback and suggestions.
(I’m not interested in taking over the old PR, I’m happy with this proposal so far)

@wborn @maggu2810 @hilbrand @martinvw @kai

Cheers, David

3 Likes
2

Just for information, there is a notification system used in the ZWave binding and in HABmin. This was proposed to be added to OH a while ago, but it got bogged down with people trying to decide to add more features, and link it to a much wider scope bundle in ESH and it was therefore closed a month or two back (after 2 years or so).

It is a reasonably simple system that uses the existing event system to send events to users.

I don’t mind if you use this, or start again, but I do think we need something that does this, and I would recommend getting something added rather than having a huge discussion about the best approach - that’s what happened 3 years ago, and, well, nothing ever got merged.

2 Likes
3

I also don’t like how slow it is to get things into the core and that slows me down by a lot. Habmin, habpanel, HAbot they all have wonderful bundles inside that should go into core. (Although habmin is very much xml based and uses own files instead of the StorageInterface). And Sitemap needs to be isolated.

I like how easy it is to work with the new maven/bnd system and was able to establish my own distro within half an hour. Thanks to OSGi we have relatively small bundles already, but .core and .core.thing is a mess. I’m have fixed the first one (splitting it up into multiple bundles while keeping the package names for API compatibility). So I basically have a fork of some bundles in front of me.

My fork also contains:

  • A new extension system based on user addable repositories which allows me to add npm as a source and use my paper-ui-replacement without wrapping it in an OSGi bundle and allows to install scripts via npm as well. (This replaces .core.extension and .core.binding and .karaf and .boot)
  • Additional Annotation based binding development (while the old interfaces stay intact). This will reduce review time by a lot. The typical new-binding will be 1k loc and not 3k loc. The new buildsystem already reduced boilerplate files.
  • The above notification system, although I’m still writing tests.
  • The ui.widget interface from habpanel for UIs that want to display widgets.
  • The ui.cards interface from habot.
  • A new ui.pages interface that reminds on the old sitemap concept.
  • The NLP parts from habot in an own org.openhab.nlp bundle.

It is like with the rule engine. Sometimes it is just better to have it in, declare it experimential, and tweak it until it works as expected.

I hope I can convince core maintainers to use semantic versioning for osgi bundles. That way a bundle with a version lower than 1 is very obviously experimental and not API stable.

I want that upstream at some point, and the way to go is via a Telco with all or most push access capable maintainers. But I also have no problems to promote my distro here with all those new features, and call it openHAB-NG or so and invite all developers to come over.

My problem at the moment is that I do not have any UI for my .ui interfaces except a management UI.

  • I need to upload the web part of habot to npm and make it available,
  • need to change the few bits of habpanel to use the core widgets interface instead of its own one and
  • develop a small, lean flutter app for android/ios for the pages ui interface,

and then I’d be ready to promote this as an alternative. Too much for just me and I don’t care about control interfaces. So those ui bundles will take some time to be merged back into the core, because at least one consumer is required I guess.

Cheers, David

4

David, please let us keep using Github issues for discussions around features etc - that’s what it’s meant for.
The “development” category here was rather created for newbies on how to get into development in openHAB, where to find code, IDE, best practices etc. If this is misleading, we can think about removing/renaming it again.