Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blacklist or whitelist for modes #23

Closed
nils-z opened this issue Feb 10, 2019 · 9 comments
Closed

Blacklist or whitelist for modes #23

nils-z opened this issue Feb 10, 2019 · 9 comments
Labels
enhancement New feature or request released

Comments

@nils-z
Copy link

nils-z commented Feb 10, 2019

My zwave thermostats have 5 modes but I need only heat and off. The three unused buttons take up a lot of space in the UI:
It would be nice to have an option for hiding modes.

image

@nervetattoo nervetattoo added the enhancement New feature or request label Feb 11, 2019
@nervetattoo
Copy link
Owner

Yeah; I can see how this is very cluttering.
I almost should get myself a more complex thermostat component just to see these cases for myself!

Adding an option is simple enough so I guess I'll be adding one of these flavours for configuration.

hide:
  mode:
    - heat_eco
    - manufacturer_specific

hide:
  mode: false
mode:
  include:
    - on
    - off

@fredrike
Copy link
Contributor

Perhaps the icon mode could be added to the configuration:

mode:
  - type: on
    icon: mdi:on

@KarimGeiger
Copy link
Contributor

I'd really appreciate both of these features. If I could get rid of the "an" mode and add an icon to the "boost" mode, it would be absolutely fantastic!

screenshot 2019-02-26 at 15 18 02

By the way, thanks for the awesome work so far, and also thanks for keeping it up with the development and adding new features. The change from dropdown to buttons looks great 👍

@nervetattoo
Copy link
Owner

This will happen folks, just be patient as I find the time 🗓

@nervetattoo
Copy link
Owner

Thinking through this a little bit more my current intention is to go with the following approach, I'm sharing it first to hear if people think this makes sense.
I will deprecate the hide.mode and instead introduce the modes top level key. modes will be merged with the entity reported modes by default, meaning you can override items there, but you need to explicitly configure each item you want to change, or else it will use the defaults and look like today. I'm on the fence about also allowing to specify it to not merge, mostly because its hard to find a succinct config structure while supporting that in a good way.
Without disabling merging, the only use case that becomes hard is if you want to only include these two sensors out of 7 reported ones

Anyway, here's the planned config:

modes:
  weird_mode: false
  off:
    name: Make it cold
    icon: mdi:whitewalker
  on:
    name: On
    icon: false
    color: <any valid css color>
  wonky_mode:
    include: false

It also supports the shorthand from hide.mode:

modes: true|false

If I decide to allow disabling merging I'm leaning towards a special key in the modes map:

modes:
  _merge: false
  off: true
  on: true

Are there anything you feel is not supported with this? I think it covers all requests and feedback I've heard quite extensively, but just to be sure I want to let this sit here for a day or two before I implement the changes.

@KarimGeiger
Copy link
Contributor

Sounds perfect!

As for the disabling of merging, for me personally, this isn't really necessary. I think one can invest the time to adjust the configuration and disable all entities by hand. Of course it would be nice to have, I can imagine, but it's another feature that needs to be supported if it breaks, so I'm not sure if it's worth the trouble. Did you get any requests for that specific feature?

@hcoohb
Copy link

hcoohb commented Feb 28, 2019

Hi,
Love this card and would love that function to remove some modes from the UI.
To me, the 'merge' part start to gets complicated... whereas listing all your modes to be able to disable some is still acceptable I think.
Thanks a lot

@KarimGeiger
Copy link
Contributor

Awesome work, thanks!

@github-actions
Copy link

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request released
Projects
None yet
Development

No branches or pull requests

5 participants