[Ovmsdev] Notification subtypes vs. MQTT topics & subscriptions

[Michael Balzer]

I pushed the support for notification transport to web clients yesterday:

    Notifications via WebSocket channel & Web UI dialog widgets
   
    https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/83
   
    Includes addition of a fifth notification channel "stream" for subtype/app
    specific data. Notification subtypes are used as MQTT style topics:
   
      "notify/<type>/<subtype>"
   
    …with subtype dots '.' replaced by '/'.
   
    The web client subscribes to topics on a receiver object. Types "info",
    "error" and "alert" are always forwarded to the web client, "data" and
    "stream" only as subscribed. MQTT topic patterns are supported (as far as
    mongoose implements them, which is currently only "#").
   
    Test & documentation:
    - components/ovms_webserver/dev/notifications.htm
    - components/ovms_webserver/dev/dialogtest.htm


1)

Notification subtypes fit MQTT topics semantically, but have been introduced by us using a dotted syntax.

Server v3 currently uses subtypes as submitted for the MQTT topics generated from them. For the webserver, I convert the dots to slashes (utils: mqtt_topic()).
I suggest applying the same scheme to the v3 transport, so subscriptions can be simplified by applying standard MQTT wildcards (e.g. "notify/+/charge/#" would
subscribe to all charge notifications).

I haven't changed the v3 server, because it may break existing subscriptions. Are there any MQTT users working with notification subscriptions yet?

And as subtypes really are topics now, maybe we should change the subtype scheme to reflect this?


2)

The new "stream" channel is meant for "re" and similar applications, i.e. apps needing fast display update channels. It's currently not transported by the v2/v3
servers, but adding that to the v3 server is very simple once we've sorted out this:

Generation of stream updates without any active clients would add unnecessary CPU, memory and network load. Streams could be switched on/off using some
dedicated command, but a better way is to check for active subscriptions to the stream topic before producing the data.

This currently needs polling the MyNotify.HasReaders() method. I would rather introduce events to signal topic subscriptions and unsubscribes. I can easily
produce these from the webserver as sub/unsub is handled by the server itself, but we should introduce this with real MQTT subscriptions in mind.

Problem with MQTT is (or seems to be?), there is no defined broker standard to get consumer topic sub/unsub updates. Do we need to define a custom topic scheme
for this? Or is there a broker standard about to emerge?


Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26