[FR] Web UI - MQTT websocket real-time updates

[InToSSH]

Hi,
this will be mostly for @paularmstrong and just an idea for the future.
I was thinking since we now have nice Web UI and a lot of people don't use it with HA or other system it would be great to have some kind of real-time dashboard with current events, possibly even notifications (just in-page with sound perhaps, not HTML5 as it would require external access and HTTPS) and it could grab the events using JS MQTT websocket client, without any additional work on the backend. This would make this project completely standalone for people who don't use or need any other system to connect this with.

[paularmstrong]

I'm going to move this to a discussion. I agree that it's probably what we should do, but there are a bunch of considerations to deliberate first.

[paularmstrong]

I was originally working on #647 when this idea was brought up. I also looked into MQTT in the web UI to handle toggling switches as well. I think it would really simplify how much needs to be done for the web UI, as well as some issues to the Python application.

In Python, I've got this working, but it ends up pretty hacky, needing to send the frigate.app the mqtt_client, config, and camera_metrics, then need to refactor the mqtt methods so they can be called from the app to avoid duplication of all of the logic in those switches. So, long-story-short, it's kind of a pain and will be harder to maintain in the future.

⚠️ On the web, using MQTT, however – it would mean that your MQTT password (assuming you use one) now needs to be sent to the web UI in plaintext format. This may be a non-starter for some more security-minded people.

MQTT as a JavaScript package itself would incur a 50% increase in dependencies that the browser needs to load. It's not HUGE right now, but it's not nothing, and it's a bit of a nuisance

[InToSSH]

First of all, thank you for moving it to discussions, completely forgot about those :)

You are right about security issue with password. I am using MQTT JS client on my web to pull data for my weather station, but that is read-only and a separate user that is locked to this one specific topic. In case of Frigate, as it sends snapshots this might pose a bigger security concern and would also need a bit more setting up - not as simple as installing Mosquitto and creating a user.

Then there could also be an option of using normal websockets, but that would of course require more backend work and running a Node server for example.

As I said, this just an idea for the future of the project. I have this integrated with HA and Node-RED so everything works beautifully, but since there is already some work on the Web UI, it would be nice turning it into a standalone project.

[paularmstrong]

No worries! I do think it should happen. I just want to make sure it's done in the best way that we can.

That being said, if you're using HA and you have access to its web UI, your passwords are easily discovered.

A read-only MQTT user would work for receiving updates, but would not work if we want to toggle switches on/off (detect, clips, snapshots, future things)

[paularmstrong]

Another password alternative would be to require you to enter the password any time you use the UI. It would be stored in your local browser indexeddb instance. Up-side: secure, only the actual frigate app can read it. Down-side: every time you access from a new browser, you have to enter the password.

[paularmstrong]

Further thought: MQTT would also not work with hassio ingress (or at least without a lot of work and potential fragile bit of magic)

[blakeblackshear]

I think the right path here is to use regular websockets and relay messages to mqtt. Ingress will proxy websockets too.

[blakeblackshear]

Yea. It's not really feasible to try and implement mqtt directly on the frontend. It would require publicity exposing mqtt. This extra hop will be microseconds.

[paularmstrong]

With that, is writing HTTP API endpoints for allowing updates necessary? For the web ui, there wouldn't be any reason for them, but that isn't to say that no one wants/needs to be able to make a quick HTTP POST.

[blakeblackshear]

Let's worry about supporting the use cases we know about now. No need for http endpoints.

[blakeblackshear]

I can add this to my todo list if you aren't already working on it.

[paularmstrong]

I wanted to finish up unit tests before moving on to anything else. Feel free if you have time!

[paularmstrong]

The MQTT relay is now built and able to be used. It is only implemented in the web UI for toggles (snapshots, clips, detect) and updating the debug page. Happy to review PRs for other implementations.