Just an observation, but there is no video, when vizy.local is open on vizy’s RPi (after connecting it to a monitor). The problem is that chromium is blocking camera on unsecured websites.
We’ve seen this and attributed it to the video accelerator being preoccupied with encoding video. Where did you see the error associated with unsecured websites?
Edward
I see this on vizy.local too. The only error output I’ve seen so far is this (in the Chromium developer tools console):
DevTools failed to load SourceMap: Could not load content for http://vizy.local:5000/assets/bootstrap.min.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
[email protected]_9_1m1628887230.14.0.min.js:24 [Violation] ‘message’ handler took 469ms
[email protected]_9_1m1628887230.14.0.min.js:24 [Violation] ‘message’ handler took 241ms
[email protected]_9_1m1628887230.14.0.min.js:24 [Violation] ‘message’ handler took 241ms
The source map errors are normal, as are the react messages, which are just some requests that violate the maximum latency.
We haven’t investigated this too deeply, but we assume there’s a workaround. Are you wanting to run a local browser?
Edward
I think I might want to when away from home.
Connecting over the web through VNC and running in a local browser might be a way to safely expose the Vizy interface.
But I’m not sure if you’re planning some other way to do this.
While reading through the pet_companion tutorial, I came across a description of a built in capability to connect “… Vizy to a public relay server which forwards requests from clients (Web browsers) on the Internet.” If that works (and it’s secure), then running a local browser through VNC probably isn’t required.
Hello, we haven’t given up on the local browser issue… Another idea to connect remotely (outside your local network) is to connect to a computer on the same network as Vizy using remote Chrome desktop. This way you don’t burden your Vizy to do both the video encode and decode simultaneously. Chrome desktop is a nice utility and uses direct connections through firewalls (like Zoom and others do using peer-to-peer communication but doesn’t require hole punching) and the client runs in your browser. (VNC requires a separate client application – you could use VNC to connect remotely to a computer on same network also, but probably requires hole punching through your router.)
Our plan is to offer an ssh tunneling option in the short term (the relay server that you mention). It uses ssh encryption and allows you to connect using a browser and a special URL. This will be ready in the coming weeks (fingers crossed.) It will use some free server options like localhost.run. And I’m told that we’ll eventually replace this with peer-to-peer connectivity, which will be great especially if you’re in a country that doesn’t have a nearby relay server. 
Edward