search

AppDaemon / appdaemon

:page_facing_up: Python Apps for Home Automation
Other
851 stars 418 forks source link

Allow making any widget clickable #282

Open epruesse opened 6 years ago

epruesse commented 6 years ago

It would be nice if it was possible to assign an onclick action to any widget. In particular, the navigation action would be useful.

My use case would be having overview type widgets (clock, weather, camera, device_tracker, ...) switch to another dash with more detail. E.g. have a small camera widget and show a fullscreen dash for that cam if it is clicked. Or show the full weather report dash if the weather widget is clicked.

mmmmmtasty commented 6 years ago

I second this

On Sat, 7 Apr 2018, 9:16 am Elmar Pruesse, notifications@github.com wrote:

It would be nice if it was possible to assign an onclick action to any widget. In particular, the navigation action would be useful.

My use case would be having overview type widgets (clock, weather, camera, device_tracker, ...) switch to another dash with more detail. E.g. have a small camera widget and show a fullscreen dash for that cam if it is clicked.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/home-assistant/appdaemon/issues/282, or mute the thread https://github.com/notifications/unsubscribe-auth/ANdfTjsoMhgNhU4P1anUVI5RGCYSPSe_ks5tmGfBgaJpZM4TK-ER .

scorfman commented 6 years ago

Third'd. A use case for me would be: I have a widget that displays an animated weather RADAR gif. On touch, I'd like to full-screen it till next touch, or until timeout.

kabturek commented 6 years ago

what other actions apart from navigate are you guys thinking about ?

epruesse commented 6 years ago

If I understand the architecture of appdaemon right, most of this would be accomplishable by having a way to customize translation of JS events into HA/Appdaemon events.

epruesse commented 6 years ago

Plus perhaps having a widget that has multiple sub-widgets it can show. I suppose, one could do this already by having a few more dash'es representing the alternate views. The combinatoric problem could be addressed by just not allowing multiple widgets to be in alternate view state. Still, it'd bloat the config somewhat (upstairs, upstairs-with-weather-forecast, upstairs-with-second-cam, upstairs-with-aunt-time, ...).

kabturek commented 6 years ago

initiate detail view -> navigate does exactly that (with timeout etc) map alternate input actions -> custom/or extended light widget multiple sub-widgets -> we have "sub-dashboards" to simplify this http://appdaemon.readthedocs.io/en/latest/DASHBOARD_CREATION.html#advanced-dashboard-definition

epruesse commented 6 years ago

initiate detail view -> navigate does exactly that (with timeout etc)

Yes, but how would I make say a weather widget call navigate? I can do this with two widgets:

weather_widget:
    widget_type: weather
weather_dash_widget:
    widget_type: navigate
    title: Detailed Weather
    dashboard: weather_detail

What I'd like to do is use save the space for the extra button. It's natural to click on the weather widget to get more info on it, more so than looking for another button elsewhere on the dash.

Something like this ...

weather_widget:
   widget_type: weather
   action_type: navigate
   dashboard: weather_detail

map alternate input actions -> custom/or extended light widget

I suppose here I was asking for a different feature. Some more actions besides post_service_active and post_service_inactive. Agreed, that's a different issue.

multiple sub-widgets -> we have "sub-dashboards" to simplify this

Yes, technically that would work. It gets pretty redundant and cluttered quickly though. Even using "sub-dashboards", I'll need an extra .yaml for the line(s) showing the alternate widget and another .dash for the assembled dash. Every widget with an alternate view needs one extra "sub-dashboard" for every sub-dash it's included on and one extra .dash for every dash it's on.

I'd love to have something like this:

weather_widget:
   widget_type: rotating
   timeout: 5
   sub_widgets:
       -  widget_type: weather
       -  widget_type: weather_summary
          entity: sensor.dark_sky_hourly_summary
       -  widget_type: weather_summary
          entity: sensor.dark_sky_summary
kabturek commented 6 years ago

Yes, but how would I make say a weather widget call navigate?

sorry i wasn't clear - this use case would be contained in the initial idea to add click/navigate to (all? most?) widget

I think the other two requests are a good idea but i would treat them as other features.

i like the initial navigate idea and might look into this if no one takes this.

dcolley commented 5 years ago

how about an "action | on_click | on_tap" declaration


my_action_declaration:
    type: [ web | http | skype | callto://mom ]
    url: http[s]://my.security.cam.ip/login

my_camera_widget:
    widget_type: camera
    title: My Camera
    refresh: 1
    frame_style: ""
    entity_picture: !secret cam_url
    click_action: action my_action_declaration
ReneTode commented 5 years ago

the plan is to have predefined javascripts that can be assigned to possible widget actions. so you can assign longpres(double click)s to navigate and short press(single click) to change a light switch. or swipe to a color change.

the javascripts will have the same as custom widgets. they can be designed by everyone, but there will be a lot of predefined actions.

the trouble is that we only start working on that after the release from AD 4 (which is way overdue through circumstances)

DaveDixon commented 1 year ago

Upvote. Navigation is what I need - I have two custom widgets, navsensor and navcamera. I use navsensor for navigation to/between alarm, lighting, and climate dashboards. I use navcamera to cycle through a list of cameras. I can't think of other use cases, since navigating to another dash always does the trick for me.