I’m well under way with an insteon_plm component. I’m reaching the point in development where I have to make some aesthetic decisions and I’d love some guidance. Notably:
Is there a entity_id naming philosophy? INSTEON devices are identified interally using a three byte address (usually expressed as hexadecimal). Currently I’m setting the entity_id to “light.aabbcc” which seems to be aligned with what I observe from other components within hass (hue and zwave for example). Other components seem to include a prefix in the entity id (like sensor.sun.sun or sensor.dark_sky_humidity) using dot or underscore delimiters respectively. For components and platforms with generic, human-focused naming, it seems like “light.bedroom” is ripe for collisions. My sense is that light.plm.aabbcc or light.plm_aabbcc would be a safer approach. I’m not seeing any consistency or consensus from existing components and platforms, though. What’s the best approach here?
Additionally, since the INSTEON PLM is an ancient, relatively dumb device and protocol, it has no notion of friendly names at all. Looking at other platforms, it seems like there are two primary methods for addressing this. I can write my own yaml file to the config directory and then expect the user to edit that file after new devices are added and supplement the component’s device list with the additional data. I see that presence tracking seems to behave this way (known_devices.yaml) as well as platforms like insteon_local and to some degree the openzwave stuff. Another approach I’m seeing is to just leverage the homeassistant/customize section of the configuration. This works fine, naturally, but it seems a bit flat and difficult to scale, and largely unused by the more mature and modern components I’m seeing in modern hass. Is there an approach here that is is friendlier to the future plans and development of the project as a whole? I’m happy with any approach, really, just lacking the context to make an informed choice.