include entities not in entity registry in config entities#4867
Conversation
| div { | ||
| overflow: auto; | ||
| max-height: 600px; | ||
| max-height: calc(100vh - 300px); |
There was a problem hiding this comment.
Isn't this very limiting on mobile ?
There was a problem hiding this comment.
This shouldn't have been in this PR 🙈 but, no It just makes sure the scroll container fits on the screen, will fine-tune it a bit.
| : "hass:cancel"} | ||
| : entity.disabled_by | ||
| ? "hass:cancel" | ||
| : "hass:pencil-off"} |
There was a problem hiding this comment.
I like the pencil-off icon, good choice.
There was a problem hiding this comment.
Is the icon truly needed? The entity's check box is grayed-out, signalling read-only status. A quick glance on the left already indicates which entities can/cannot be edited. The no-edit icon repeats on the right what is already communicated on the left.
Whereas the exclamation icon draws one's attention to an anomaly (entity is unavailable), lacking a unique_id isn't an anomalous condition but shares the same column.
There was a problem hiding this comment.
A user needs to know why the checkbox is disabled, there is no explanation now.
There was a problem hiding this comment.
I agree. However, I don't believe the pencil-off icon provides that missing explanation. It simply reiterates the meaning of the dimmed checkbox: this table-row cannot be edited.
Suggestion:
Perhaps by hovering over the checkbox or table-row (and/or if you click the table-row) it reveals an explanation like:
Cannot edit this entity because it lacks a unique_id. Refer to configuration.yaml file.
Anyway, I don't mean to belabor the point but, in its current form, it tells me twice that I can't edit the table-row (and without a hint as to why).
There was a problem hiding this comment.
It does show that it is not editable on click in the settings dialog.
There was a problem hiding this comment.
Check the screenshot, it does tell you why.
There was a problem hiding this comment.
Your original post's edit-history shows the screenshot was added 3 days ago, same time when I made my previous post. My mistake; I didn't see you had amended your original post.
I suggest the message also mention configuration.yaml to answer the reader's question "If not from the UI then where?" However, even without mentioning it, the message achieves the goal of clarifying why the entity cannot be edited in the UI.
BTW, I believe the message's text should use the conjunctive adverb therefore as opposed to the adverb therefor.
There was a problem hiding this comment.
It doesn't necessarily have to be in configuration.yaml for example the group entities from hue don't have unique ID's but are set up with an integration flow.
There was a problem hiding this comment.
True, but all entities defined in configuration.yaml are not obligated to have a unique_id. Traditionally, it's a prime source of entities than do not appear in the Entities list and why I suggested it be mentioned. Nevertheless, even without referring to the YAML file, the message explains why you can't edit the entity and that's very helpful. It's all good.
FWIW, the few flow-based integrations I've used (Homekit_controller, LIFX, and the currently in-beta UPB) all generate entities with unique_id's. This gave me the impression that it's the norm for flow-based integrations.
Off-topic: As for the Hue integration, without knowing why it fails to generate unique id's (a design constraint?), I'd say it's anomalous (and probably should create them).
There was a problem hiding this comment.
Well every integration should try to do it, also a lot of integrations that are set up with configuration.yaml have them. In the case of hue, it is a technical limitation just for groups, lights and sensors do have unique id's.
| "ui.panel.config.entities.picker.filter.show_unavailable" | ||
| )} | ||
| </paper-icon-item> | ||
| <paper-icon-item @tap="${this._showReadOnlyChanged}"> |
There was a problem hiding this comment.
I don't know if this should be an option. They are active, they have states etc otherwise they wouldn't exist. I think that we should always show them.
4 participants
Can use some optimizations, states refreshes too much.
Closes #4708
Open for suggestions for this text: