[SDRMR] Possible conversion to an integration

[cpyarger]

So, While this current version works, we are currently unable to give any added sensors a unique_id in home assistant. This leads to an issue where we are unable to use the built in methodologies for changing the sensor names to something a bit more user friendly.

this is due to a limitation in the rest api which is used by addons

Integrations do not have this limitation

Any thoughts on this?

[pasyn]

I did some research and came to the following conclusion:

To convert this addon to an integration we would have to rewrite it in JS along with the functions required from rtl-sdr and rtlamr. This would require a lot of work to say the least.

Another option would be to split the function between an addon and an integration. The addon would be essential what it is currently while the integration would act as an intermediary and write entity values to the registry. This option is messy and complicates setup significantly.

A possible third option would be to use the templating function of the REST api. As far as I can tell, since templates are technically an integration, they have the ability to set unique ids. This would only require some tweaks in the json output to HA.

[cpyarger]

I don't have any knowledge of the third option, Can you point me to some documentation or examples of what you mean?

[pasyn]

https://developers.home-assistant.io/docs/api/rest
/api/template

https://www.home-assistant.io/docs/configuration/templating

https://www.home-assistant.io/integrations/template/

Upon further reading, it is now my understanding that the template integration is not the same thing as "templating" or "rendering a template" as referred to in the rest api docs. I wish this was clearer in the docs as the naming convention would imply otherwise.

But I did find that by adding the following to my config.yaml, I could set the UniqueID of my meter sensor and rename it from the UI.

template:
  - sensor:
    - name: "23876447"
      unique_id: "23876447"
      state: ''

My understanding from the community forum is that the template integration in config.yaml sort of preallocates/preregisters the entity allowing the Unique ID to be set in the registry. The addon will simply update the state of the already existing entity.

https://community.home-assistant.io/t/ha-core-rest-api-post-unique-id-for-entities/216122/2

[cpyarger]

Sigh, template sensors ugh. Doing my best to make it so those are never needed lol. I guess, The fourth option is to allow a map between sensor ID and sensor name in the addon, Maybe with a default based on sensor type?

[pasyn]

I understand. I wish there was a solution that only uses the REST API.

Im not sure that I completely follow what you mean by mapping in the addon. Are talking about adding the ability to change the name of the entity from within the addon?

Addressing the template method again, it should be possible to automate the editing of the config in such a manner that the user never has to. For example, the addon would create /config/packages/sdrmr.yaml where it would maintain a template sensor for each meter id being read by the addon.

[cpyarger]

Im not sure that I completely follow what you mean by mapping in the addon. Are talking about adding the ability to change the name of the entity from within the addon?

yes

Addressing the template method again, it should be possible to automate the editing of the config in such a manner that the user never has to. For example, the addon would create /config/packages/sdrmr.yaml where it would maintain a template sensor for each meter id being read by the addon.

I understand that's a valid method, but not one I want to be using. getting away from template sensors is the whole reason I built this addon

[pasyn]

Goatcha! That should be straightforward enough to implement. Do you prefer prefixes in the entity names such as gas_meter-387327906 or water_sdrmr-1540485337? Or would you like to go the route of specifying an entity name for every meter id entered in the addon options?

Prefixes have the benefit of working when meter id is not specified and all in range meters are reported. And they can be changed from the default value in the addon options. Although I do not see reading all in range meters as a valid use case. If anything it should be discouraged for the sake of privacy.

[cpyarger]

Legally, Privacy is not an issue here, It falls under the heading of yelling out your window (:
Prefixes would be better, but honestly, I think I should look into making the changes in the rest api. or seeing if there are any plans to.

Any idea if there is a method using apparmor?

[pasyn]

Apparmor would not be applicable. It is a kernel security module that controls access to operating system resources. Similar to SELinux AFAIK.

I agree with you about checking into the future of the rest api. I also think prefixes would be a good short term solution.

I found something else interesting while searching through the HA developer docs. The documentation is vague and limited but it could provide another route to registering entities. The supervisor api provides access to mysql and mqtt services.
https://developers.home-assistant.io/docs/add-ons/communication#services-api

This is what I am currently researching:

Option 1 - Addon can post mqtt topic to HA mqtt integration. The mqtt integration should be able to set Unique_ID. Downside is that it requires the mqtt integration to be set up.

Option 2 - Addon posts entity directly to HA mysql database. No integration setup required. I don't know if this is even possible.

I will update when I learn more.

[cpyarger]

I lean more towards option 2 being the most viable method. Second biggest reason I made this addon was to get away from MQTT, While I know a lot of people love it, I hate having to have yet another service and thing to worry about.

Maybe something like this as a workflow

RTLSDR->REST Post -> if RETURNs 201 -> SQL add unique_id
RTLSDR->REST Post -> if RETURNs 200 -> Do nothing