New component best practices?

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.

Not a dev, just a user with an opinion so this is just from that perspective.

This makes the most sense. The internal IDs should be appended to “plm.” as it makes the most logical sense when trying to troubleshoot things.

I think this is the approach that fits the best for most users and follows standard conventions.


We are well under way with a C++ project called autohubpp.

autohub plus plus, is an open source server running on linux to provide a gateway between an Insteon Serial/USB PLM
or Insteon HUB1. Both devices are supported simply by changing the information in the yaml configuration file.

The autohubpp server provides a websocket API as well as a REST API.

Some time ago, I cobbled together a python/home assistant component to communicate with autohubpp. It works well for testing purposes but I am not a python developer.

Would you be interested in developing a component for home assistant to support autohubpp? Would you be interested in contributing and/or using autohubpp? Take a look at autohubpp.