Fullscreen mode for the camera widget

I am updating the camera widget to allow fullscreen mode when the image is clicked. If this works as expected, I will do a PR to have this included in a coming release.

There are two config options:

  fullscreen_timeout: 3  # Timeout in seconds. Defaults to 30 seconds
  nofullscreen: "on"       # This will turn off the full screen function. 

This it how it is supposed to work:

  • With no config options: Click on the image will enter fullscreen and go back after 30 seconds.
  • With fullscreen_timeout: 3. Goes back after 3 seconds
  • With nofullscreen: "on". Does nothing
  • Click or touch while in fullscreen: Goes back and resets any running timeout.

Please try it out and post any issues here so we can get it working in all browsers.


@ReneTode, @TheLaw
1 Like

@tjntomas

Wallpanel (Android System Webview): Does not function
Fully Kiosk Browser (Android System Webview): Does not function
Chrome: Creates duplicate box below stream when exiting full screen.

We need to extract the OS string or browser id for these two. Then I can add alternative code since they do not support the standard browser fullscreen javascript function. It’s just a matter of using CSS instead of the javascript function.

Chrome however works in all the various flavours I have tried. On which OS are you running the Chrome browser that gives you the behaviour you mention, and what Chrome version?

@tjntomas

Not sure how to find the requested info for Android System Webview.

Running W10, latest update (latest chrome as well). Browser cache cleared, but no change. The previous implementation worked on the same setups.

ok, I’m also on W10, latest Chrome and working. I’ll add some debug code to get some logs in the javascript console. I’ll add a popup to display the navigator details for the Android System Webview when the widget loads.

Aslo, post your widget definition. I might have missed something there.

camera:
    widget_type: camera
    entity: camera.deck_camera
    title: Deck Camera
    base_url: "http://192.168.x.xx:xxxx"
    stream: 1

If the camera timer takes the user back to the dashboard, there is no additional window. It only occurs on manual return.

Update: After clearing cache fully (not just CTRL+F5) I no longer receive a new window, instead the camera feed goes black on manual return.

I suspect this worked with the previous implementation, because it added to the variables.yaml of my skin. With my skin disabled the functionality works.

What do you have in your skin specific to the camera widget?

@tjntomas

Other then a black background, nothing. When I remove the following code, on return the stream is actually gone. What I was seeing before was the background I had added.

camera_widget_style: $black_background
camera_title_style: "$style_title; background-color: rgba(0, 0, 0, 0.1)"

I tested the original implementation GIST (which is all added to the variables.yaml) and everything now works. What was conflicting before was Home Assistant moving the user to the stream URL, but you removed that.

Good that the Hack implentation works, I suspected that the <a> tag was the problem. I think I need to refresh the .src on return.

After updating a widget, you can add ?recompile=1 (or &recompile=1 if you are specifying a skin in the url) to the url to get Appdaemon to rebuild everything. Should help with “leftovers” in the cache.

Awesome, let me know when you’re ready for another test. That’s great info, recompile works wonders.

One thing I noticed with the new AD camera widget is that on an HA restart, because the open dashboards are requesting old tokens, HA starts a ban flood until the dashboards are refreshed. Your widget does not have this issue.

To get around this I have all my tablets refreshing on restart via MQTT commands, but ideally AD/Hadashboard should refresh dashboards to prevent this. Something to consider looking at since you’ll be submitting a PR.

Tested this with latest version of android webview. It does not do anything on click. This does work in Chrome without issue, though.