Control object for the generic event-source plugin for the HMI Notification Manager

Any app
HMI Notification Manager
Note: This type of object is known as a server object, a special PPS object designed for point-to-point communication between a server and one or more clients. For details, see "Server objects" in the Persistent Publish/Subscribe Developer's Guide.


The generic event-source plugin for the HMI Notification Manager provides a PPS interface that allows applications to use the HMI policy-management facilities without implementing a custom plugin. Applications can use this PPS interface to generate events. The generic plugin can also be used for automated testing. Using the PPS interface, a test application can generate customized events and inspect the outcome for expected results.

PPS messages sent to the plugin's interface from clients take the form of JSON objects that describe an event. The format is similar to that used by the pps/services/hmi-notification/Status and pps/services/hmi-notification/Messaging objects, but additional attributes are included in this control object.

The event message

This object accepts only one command:

msg:: dat:json:
event {"parameter":"value", "parameter":"value", ...} (see below)

Parameters and values are as follows:

Parameter Value Description
name event_name Name of the event to be passed to the HMI Notification Manager.
view view_application Name of the application responsible for handling the event.
type event_type Type of event being passed. One of:
  • display-start
  • display-end
priority priority_number An integer for the priority level (range is 0 to 7).
window-type window_type Type of window associated with the event. One of:
  • Fullscreen
  • Growl
  • Hidden
  • Notification
  • Overlay
fallback_types fallbacks List of window types to be used as fallbacks for the event. These events must be given in order of preference and are used as fallback types if the requested window type can't be accepted. These fallbacks will be tried in order until one that can be accepted is found or the event request is rejected.


A client sends a display-start event with a priority of 1, with no fallback window types:
# echo 'event::{"name":"test_event", "view":"TestApp",
"type":"display-start", "priority":1, "window-type":"Overlay", 
"fallback_types":[]}' >> /pps/services/hmi-notification/control
The Status object should then look like this:
# cat /pps/services/hmi-notification/Status
The client sends the associated display-end event:
# echo 'event::{"name":"test_event", "view":"TestApp", 
"type":"display-end", "priority":1, "window-type":"Overlay", 
"fallback_types":[]}' >> /pps/services/hmi-notification/control
The Status object should now be restored, showing the previously displayed event in its display list:
# cat /pps/services/hmi-notification/Status
The following example illustrates a situation where the HMI Notification Manager uses a fallback window type.
  1. The client must be attached to the Messaging object (because it's a server object):
    # exec 3<> /pps/services/hmi-notification/Messaging
  2. Next, the client sends a test-event1 event to the generic plugin to ensure that an event with priority 1 or greater is active:
    # echo 
    >> /pps/services/hmi-notification/control
  3. The client then sends test-event2 with priority 1 and fallback window type Growl:
    # echo 'event::{"name":"test-event2","view":"TestApp2","type":"display-start",
    >> /pps/services/hmi-notification/control
  4. Now we can see that the Status object has been updated:
    cat /pps/services/hmi-notification/Status ; cat <&3

    And the Messaging object will show that a Growl notification event has been sent: