I can see where a subscriber list could be useful,
but it sounds like from these use cases a subscriber count might
be more useful. I had a similar case where units would publish
status updates every 15 minutes for regular logging, but if
someone was watching that unit it would publish every few
seconds. I did it with a control type message, but thinking
about it a subscriber count would work better.
However in my case I would typically always have a single
subscriber that was simply putting the data into a database
for historical reporting. You guys got me thinking and here's
the design I would use(and may go back and fix my own code):
Decide subscribes to <device-id>/listening/#
Listener connects, and publishes a retained message to
<device-id>/listening/<topic>/<client-id>,
setting a LWT to clear the message.
Device keeps a count of listeners, and starts/stops(or
increases frequency) based on that. I'm pretty sure it
wouldn't even need to keep track of the individual clients.
Just add one if there's a body, and remove it if there isn't.
Assuming that it resets to its idle state when disconnected,
or is a non-clean session(so it doesn't miss the removal of
the retained message while disconnected).
That way you could have passive listeners that don't
trigger device behavior changes without cluttering up the
device code.
-Darren