I have some entities that I have no idea what they do: select.ikea_of_sweden_tradfri_control_outlet_18c147fe_on_off_startuponoff number.study_lamp_level_start_up_current_level sensor.tze200_cwnjrr72_ts0601_6bef52fe_basic_rssi sensor.pixel5_sleep_segment sensor.pixel5_beacon_monitor sensor.pixel5_app_standby_bucket button.lumi_lumi_sensor_magnet_aq2_identify
And yes I did try to read the docs and google. And I still donāt fully understand them and Iām a power user/contributor.
These are device specific. Integrations typically donāt know device information and just present what the device offers via itās api. E.g. integrations say āGive me your informationā and the device just plops all the functions it can do without any indication what it is or what it does. Adding things like this would be a feature request, not really a WTH.
True in some cases, especially for sensors.
But not so for modifiable entities. In the integrations I have written/edited when I create an entity it is because I have used a particular API call or calls in the underlying python lib. I nearly always know what that API call should do.
But thatās not true for all APIs. Zwave attempts to manage this but there is still a ton of devices that do not have this information. Itās literally a fulltime job for 1 guy, and no, itās not just sensors. Itās pretty much any configuration option for any smart device.
Hmmm, I guess. And particularly true for HAās implementation of open standards ZigBee, Z-Wave, Thread, Bluetooth where it may not really āunderstandā what the device it is interacting with actually does beyond how the client implements the standard (device classes etc). The dev could still offer (an admittedly not very helpful) description like A cover entity associated with {device} which supports {[features]...}. Or a generic description like {device} makes available the ZigBee identify standard, this is usually a flashing status light or some obvious fluctuation in state which draws attention to the device
That is perhaps a reason we couldnāt have a useful autogenerated description for every entity. But perhaps, in the absence of a general solution, we could still ask devs to generate descriptions where possible. Or even have the community generate them in a blueprint-like wayā¦
example: Hereās a basic config for a single switch, these are all the manufacturer specific configuration options that come through to home assistant that do not share any configuration options with other devices from other manufacturers.
OK, I can see that for very open standards- like Z-wave then you are completely at the mercy of the manufacturer to have descriptive names - or some massive database.
However, I think my point still stands for other non-implementation-of-an-open-standard integrations.
Said in a more direct way, and from the perspective of a user. I think it should be considered basic functionality of a product (HA) for its functions to be obvious to its user.
Speaking as an (amateur) dev I appreciate that that can be a very hard problem to solve in all cases.
P.S I have edited my reply above to include some examples of what might be achievable in open standards.
Your edits are already being done through the entity name btw. Itās just not carried out on older integrations that donāt use devices. Everything is split out into context on the deviceās page.
Probably a better and more centralised solution! Would require a whole new subsection called āindexā or āglossaryā of the docs for each integration though.
and google. And I still donāt fully understand them and Iām a power user/contributor.
