Device repository with getHaDeviceInfo() included

#6 · open · 1 comments

View on GitHub ↗

wildekek

Thanks for making such an excellent project, this is by far the easiest way to integrate LoraWan devices into HA. The getHaDeviceInfo() discovery support really makes all the difference. It keeps a good separation of concerns on where the metadata from devices and entities should live: outside of HA and in the LoraWAN server. Great design. To make this even better, I'd like to propose to load a LoraWAN device templates repository that includes HA discovery information by default. In my opinion, a repository that contains only a few devices with discovery works better than a repository with lots of devices that do not work. I'm really curious if you agree here, or have a different point of view. The way I see it for this project to grow, is that we should take a cue from Zigbee2mqtt and make it work with 'batteries included'. You install the add-on, start it, add a device, and magically have it show up in HA. Then we could make it easier for people to add their own devices in the future and extend the repository. I'd be happy to extend the project this way and make a PR, let me know if you're on the same page.

Comments

modrisb

I see pretty big difference between zigbee and lorawan devices: the 1st publishes device information on registration (like USB devices via descriptors), but lorawan requires user to know (select/prepare) device type to connect with by naming device template. Therefore zigbee approach unlikely will work for lorawan: no quirks or other type of patches. Adding integration information to codecs would be really great thing, looks ttn/chirpstack already have stable format for device templates and codecs. Most naturally would be to add extra section to their codec.yaml: like integration: home_assistant: filename: getHaDeviceInfo.js . This most likely will require changes on TTN side (probably minor) and on ChirpStack template import code. Keeping getHaDeviceInfo in chirpha repo might be an option, but requires strict template naming rules including suffixes that are used by many manufacturers (like Dragino LHT65N-DS and LHT65 should have different HA integration structures).