feat: Allow defining, per entity, if it should be an icon or label, and save that persistently

[guimatheus92]

Is your feature request related to a problem? Please describe. I'm always frustrated when I need to do some changes in the generated YAML file that could be done by code automatically.

Even though we can define if is an icon or label, we can define more common things for each entity or among entities.

Describe the solution you'd like I would like inputs of how could we achieve this goal, so that we can use later for others features.

• Should we create a .yaml file, where user can define some configurations per entity?
• Should we export a list of entities so that a user can define any configuration per entity?

Additional context I have a repo where a user can create a three way switch flow using Node Red automatically, that download devices and entities from a given Home Assistant, so I don't know if "listing" that to user could help somehow as well.

[guimatheus92]

@shmuelzon let me know your idea and inputs here as well please.

[shmuelzon]

Hey,

Even though we can define if is an icon or label

How can we define this? Right now it's hard coded according to the type of HA entity. Ideally, I want it to be something that's editable (and savable) as a part of the SH3D project. I didn't see and general notes or tags one can add to furniture so the best idea I have have is to use the name and maybe separate things using a semicolon (;).

So we can set the name of a furniture to something like light.kitchen;state-type=icon;other-key=other-val;.... The first part will always be the name and then other key/value options. We can start with the type of YAML representation (state-icon or state-label) and add, later on, other things like icon overrides, location overrides, etc. We could have used the description but that's now part of the title. Unless we decide to convert the description to the above format and the title will be title=xxx;state-type=icon... It might be cleaner that way instead of reusing the name field.

The location part might become problematic if we ever implement #28 since it might be different for each view...

[guimatheus92]

I was thinking about this during this week. What if we use YAML file as I proposed, and create a key in there, where user can input which entities he would like to update in the floorplan.yaml file in the end. For example:

# ---- Configurations related to entities from HA ----
entities:
  light.kitchen:
      state_icon: false
      state-badge: true

  light.bathroom:
      state_icon: true
      state-badge: false

This is just an example, but we can use for so many things such as: position for the icon, gif name, hold_action property, etc.

In my point of view, this would be better organized, better visual of the configurations, and would allow us to add or remove configurations easily. We just have to implement some verifications if user mess with the configuration or set a value to a wrong value.

[shmuelzon]

I agree that this way would be better organized but it would require an additional project file on top of the SH3D file itself. Then there's the question of how this file is loaded. I would hate for people to need to open yet another browse file dialog to load this configuration file. We could just require that it would be in the output directory but that might not be as intuitive. I need to think about it some more.

[guimatheus92]

Yeah, having a good UX is indeed important, otherwise user would have to open the .yaml file if he wants to change any standard configuration - which for me is fine - but might confuse others users. What if we create another tab in the pluging for this configuration, where it'll update the .yaml file automatically based on users changes? That way, he doesn't need to exit SH3D anytime. I don't know if that is possible though.

[shmuelzon]

We now have a mechanism to save the user's configuration persistently as a part of the project file. It's, basically, just a key-value store but that should be good enough. What do you think of an advanced button that will open a separate window where the user can modify different settings per light/sensor that's detected? Maybe just a list of all the detected items and, once selected, they can toggle check-boxes or whatnot to override the current behavior, e.g., remove it from the floor-plan, force it to be an icon/label, always-on lights, etc.

[guimatheus92]

Awesome, I am so glad you were able to introduce this feature this fast!

I like the idea of showing the entities found in the user project, so that he can decide whether he wants or which entities he wants to change.

Will you provide the "customization" options available for all entities? Because we have a couple of scenarios. And we don't want users "manually" setting what they want to change and not be equals to the options supported by the plugin.

I think though, this could be in another tab in the plugin, instead of a new window from the plugin (2 windows opens for example). What do you think?

[shmuelzon]

I'm OK with another tab but will this second tab also include the start/close buttons? Because if the user will be able to start the process from the second tab, we'll also need the progress bar there and it might turn out a bit awkward. Need to mock something up to see what it could look like.

I think there will be two types of customizations for now. Lights and the other detected entities, each with their own customization options and there might be a bit of overlap. And yes, we'll need to make sure only relevant options appear for each. And probably also a reset button in case someone messes some things up that will clear it all.

[guimatheus92]

I totally agree, some design to get a clear idea. Let me know if you need any help at all.

Regarding the features, we can improve in next steps to have more customization as possible, such as: changing icons, change icon location, change tap action, gifs, etc.

[guimatheus92]

I had an idea here, and I took the liberty of making a sketch to get your opinion. Figma design: home-assistant-floor-plan - you have edit permission if you want to play around.

1. The first idea would be to add another branch in the tree view, where all the default properties that the plugin would have would be located. The user would click on the icon to expand or shrink these properties to make viewing easier.

2. The second idea would be for the user to "click" on the entity in the list of entities, and would be directed to a second screen where it would show the same properties of that entity only.

[guimatheus92]

@shmuelzon let me know your inputs in the ideas above please, also feel free to do any changes.

[shmuelzon]

I think I prefer a second screen rather than increasing the tree. We might, later on, add properties to entities that be more complex that something that can be added to a tree