MQTT remote control of UI3

[bp2008]

UI3 does not currently have any MQTT capabilities, but I recently learned that MQTT brokers commonly support web socket connections. So it should be technically possible for UI3 to connect to a broker and subscribe to, or push messages to, any MQTT topic.

This could enable remote control of specific UI3 instances. Trouble is, I have no idea how a potential user would expect this to work, so I don't really know where to begin in designing such a remote control system.

Anyone with any suggestions, or interest in this feature, please comment here.

[bp2008]

I thought a lot about this and did a little research. Based on my limited MQTT knowledge I can come up with this:

I would add a "MQTT" section to UI3's settings panel. Inside this, you could configure:

• MQTT broker hostname/ip
• TCP port number for WebSocket connection to MQTT broker
• Whether the connection should be made with HTTP or HTTPS
• MQTT user name
• MQTT password
• Unique UI3 instance ID (a short auto-generated string, but user-configurable in case the user wants to use a specific name or have multiple UI3 instances share the same name)
• Enable MQTT Client (yes/no option) so it could be turned on and off without needing to erase some of the the configuration to "break" it.

Then when it is all configured and enabled, I would have UI3 publish and subscribe to the topic UI3/instance_id/state. It would be expected that other MQTT clients would subscribe or publish to the same topic(s) too.

One thing seems fairly clear, MQTT is not meant to operate like a traditional TCP socket or a message queue. Like, imagine you wanted to export a clip. MQTT doesn't seem like a good way to communicate this intent to UI3, especially if persistence is enabled on an MQTT broker, because the command could be received multiple times and the message could end up still existing after it was handled.

Thankfully plenty of more common tasks are perfectly suited for MQTT. Imagine instructing UI3 what the state of the UI should be by publishing a string to UI3/abc123/state.

Example:
UI3/abc123/state -> { "cam": "index", "maximize": true, "volume": 0 }

When you want to change the state, you publish a new value here and it replaces the old state. That seems simple enough. But it doesn't take long for questions to arise. Imagine the remotely-controlled UI3 instance has a local user who clicks on a camera. What is supposed to happen? Does UI3 change its state without notifying via MQTT? Does UI3 prevent local changes while MQTT remote control is enabled? Does UI3 allow the state change, but publish the new state to the MQTT topic? I think that last option is clearly the best. But then, is the 3rd-party MQTT client expected to understand and consume JSON markup?

So we could split the state into multiple topics, not using JSON encoding.

e.g.
UI3/abc123/state/cam -> index
UI3/abc123/state/maximize -> 1
UI3/abc123/state/volume -> 0

This multiple-topic method may be easier for most MQTT clients to work with. Especially if UI3 is going to be publishing its own changes to the state as a user interacts directly with UI3, I bet this would make the information a lot easier for 3rd-party MQTT clients to consume.

I could have each UI3 instance announce its online/offline status by publishing UI3/instance_id/state/online -> 1 and tell the server via the "last will and testament" functionality to publish a value of 0 here when the connection is lost. Or maybe it can delete that topic or something. Not sure if it is even possible to delete topics in an MQTT broker with persistence enabled, let alone do it automatically upon connection loss. Anyway clients could learn which UI3 instances are available via a wildcard subscription UI3/+/state/online and look for the topics that have a 1 value.

I also don't know what other information might be useful for UI3 to publish or subscribe to. It could publish all kinds of things related to the current state of the UI. Current frame rate. Current streaming bit rates (for audio and video separately or together). The active streaming profile. Play/pause state. There could be a way to remotely set a timeline position or open a clip and seek to a position.

Any suggestions are welcome.

[jaygrovr]

Doesnt the console version of BI use mqtt already, can we just copy most of the functionality? I like what you came up with already as well.

[bp2008]

I thought I had replied to this yesterday but I don't see it. Shame. It was a very detailed reply.

Blue Iris does have MQTT support baked in already but most of what it does is very different from UI3's needs. BI also did things pretty weird, making clients poll for status instead of doing the MQTT standard thing of just publishing the data and letting clients subscribe if they want. For actual remote control, BI just allows you to send the same admin commands that would normally be sent via HTTP, but using MQTT instead. Its not ideal by any means, but it was their easiest way to implement a lot of functionality. I would do it differently with UI3 in a way that better-embraces MQTT's strengths.

[jaygrovr]

Yes, I think your idea to make it better would be wise.  They are two different use cases, from my point of view.  The UI3 is just the display side whereas the console is more configuration and management. Let me know if you have any builds you would like me to test with mqtt. Thanks again Jason On Friday, June 17, 2022, 09:19:37 AM PDT, bp2008 ***@***.***> wrote: I thought I had replied to this yesterday but I don't see it. Blue Iris does have MQTT support baked in already but most of what it does is very different from UI3's needs. BI also did things pretty weird, making clients poll for status instead of doing the MQTT standard thing of just publishing the data and letting clients subscribe if they want. For actual remote control, BI just allows you to send the same admin commands that would normally be sent via HTTP, but using MQTT instead. Its not ideal by any means, but it was their easiest way to implement a lot of functionality. I would do it differently with UI3 in a way that better-embraces MQTT's strengths. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[bp2008]

Implemented in UI3-216. Feedback would be welcome.

[bp2008]

The implementation differs slightly from what I described above (cam topic renamed to vid so it will make more sense if I ever decide to support clip/alert playback using this same topic).

There's a full Help file section for the MQTT functionality, linked from the top of the MQTT configuration area in UI Settings.