How can you tell which version of rtl_433 you're actively using?

[Jsalas424]

The problem

How can I confirm that the version being used in HAOS matches the latest commit in RTL_433 master?

What addon are you reporting the bug for?

rtl_443

What is the addon version?

next?

What type of MQTT Broker are you using?

Home Assistant Mosquitto MQTT Broker

Addon log messages

rtl_433 merged in commits to add support for a new sensor: https://github.com/merbanan/rtl_433/pull/2605#issuecomment-1728224471

I uninstalled and reinstalled rtl_433 (next) in HAOS and now I'm trying to confirm that I'm using the latest version with commit [945bc65](https://github.com/merbanan/rtl_433/commit/945bc658cbc51fe916dce97e0912543ddd6c2ef2) . 

The logs reflect `rtl_433 version nightly-9-ge826a465 branch master at 202310101825 inputs file rtl_tcp RTL-SDR` but I can't tell how to match the text from this output to commit/version numbers on rtl_433 master. Am I missing something obvious?

Additional information

No response

[catduckgnaf]

You cant really, this is the issue. This is why I want to take over this add-on since its being unmaintained. If I don't hear soon I will fork.

[deviantintegral]

I ran into this too at one point. I remember asking in an upstream issue, and there's some reason I find why the version string doesn't line up with git commits.

We don't do anything unique in the HA addon - you would get the same result if you checked out the code locally and built it.

You can see the git commit hash from master that was used in the GitHub actions logs for each build: https://github.com/pbkhrv/rtl_433-hass-addons/actions/runs/6558257508/job/17811466141#step:9:822

You can also infer the commit from the timestamp. With 202310101825 (this should be UTC)... woah!

ge826a465 looks to be a bug - there's an extra g at the beginning. If I run git show e826a465 I get the right commit! I don't see an open issue upstream, so I'll file one.

[catduckgnaf]

I ran into this too at one point. I remember asking in an upstream issue, and there's some reason I find why the version string doesn't line up with git commits.

We don't do anything unique in the HA addon - you would get the same result if you checked out the code locally and built it.

You can see the git commit hash from master that was used in the GitHub actions logs for each build: https://github.com/pbkhrv/rtl_433-hass-addons/actions/runs/6558257508/job/17811466141#step:9:822

You can also infer the commit from the timestamp. With 202310101825 (this should be UTC)... woah!

ge826a465 looks to be a bug - there's an extra g at the beginning. If I run git show e826a465 I get the right commit! I don't see an open issue upstream, so I'll file one.

I believe there is a better and more transparent way to utilize trl_433 in ha. I would love to discuss.

Do you have any interest in passing the touch and helping? Or do you insist on needlessly gatekeeping a project you barely have an interest in?

[deviantintegral]

Please, let's avoid negativity directed towards individuals in our discussions. We're all volunteers here!

As I mentioned in https://github.com/pbkhrv/rtl_433-hass-addons/issues/156#issuecomment-1707381895, my availability did end up being booked up until the end of October. Note I don't have permissions on this repository to manage committers myself, but as I mentioned above I'm glad to click buttons to keep development moving.

To get back to this specific issue, https://github.com/merbanan/rtl_433/issues/2675 has been closed with a small improvement in the version string (no more nightly) and clarified that the version string comes (nearly) directly from git describe. As I think the leading g isn't broadly known, the best way for us to resolve this issue is to update the next README to document how to read the version string.

[catduckgnaf]

Please, let's avoid negativity directed towards individuals in our discussions. We're all volunteers here!

As I mentioned in #156 (comment), my availability did end up being booked up until the end of October. Note I don't have permissions on this repository to manage committers myself, but as I mentioned above I'm glad to click buttons to keep development moving.

To get back to this specific issue, merbanan/rtl_433#2675 has been closed with a small improvement in the version string (no more nightly) and clarified that the version string comes (nearly) directly from git describe. As I think the leading g isn't broadly known, the best way for us to resolve this issue is to update the next README to document how to read the version string.

There are many issues with home assistant and rtl_433 that I think can be better solved by having more control. The discovery script is essentially useless, and the main add on itself lacks a great deal of transparency.

For now, the main add on mostly works, I made some improvements to the default template. I will work on better integration with rtl_433 separately. I understand your point of view, but I am interested in greatly improving, not just maintaining rtl_433 on ha

[deviantintegral]

Docs updated! https://github.com/pbkhrv/rtl_433-hass-addons/blob/main/rtl_433-next/README.md