Move repo to its own organization on github?

[pbkhrv]

The problem

First off, thank you @deviantintegral for carrying the torch for this add-on. I haven't had the time to maintain it, and I recently disconnected the SDR from my Home Assistant box (after retiring my 433mhz devices).

It might be a good time for the repo to grow up and move into its own organization on github, to better reflect the communal nature of the project.

What do you all think?

What addon are you reporting the bug for?

rtl_443

What is the addon version?

0.2.3

What type of MQTT Broker are you using?

Home Assistant Mosquitto MQTT Broker

Addon log messages

No response

Additional information

No response

[deviantintegral]

I agree! There’s certain things like docker container images that are not as easily visible.

I also don’t have many 433 devices, but enough I’m still using this. I expect to for the foreseeable future. It also reduces the chances that if GitHub starts to charge for features like container storage that you get billed for it unintentionally.

The one thing I’m not sure about is how gracefully Home Assistant handles repository redirects, if at all.

I’m pretty busy for at least the next week, and possibly until the end of October. But we can at least start thinking about all of things that would need changing and plan them out.

[catduckgnaf]

Hello, I would love to do this. I have some time, and I have some thoughts and ideas. I am willing to help carry the torch, and start the work and spend time .

I made a discord here, https://discord.gg/y5wkyxsk if anyone wants to or can join.

I also started this repo here. https://github.com/catduckgnaf/rtl_433_ha

Good to flush out some ideas. Right now the new repository works.

I am very interested in maintaining the discovery script outside of the rtl_433 project. There are too many people who find it easier to manually config.

I think ideally the discovery script would be an integration with the rtl_433 docker image, or an all in one and configurable.

For now, I want to get working on the discovery script to add my door sensors for example.

Would love to with permission work on it with @deviantintegral

[catduckgnaf]

Things are moving along, work to be done. I think one branch on "master" with the autodiscover script being easier to edit is great progress.

[catduckgnaf]

I take that back about it working, :) But I am all over it. I am going to go through all the building your first add-on etc. I have laid out what I believe are some good steps and ideas. and submitted a pr here.

[catduckgnaf]

At least for now discovery works with next and non next.

OK, here we go again. I wouldn't mind either of you helping me kick start and figure out some minor things.

My plan is only to use "next" as its master, and more supported. The discovery script currently works for both, however it is still discovering all devices with my script. I notice in the script there is the ability to only add specific IDs. Ideally we can control that from either the template config I updated with all IDs. OR I added an option in the discovery add-on to select the ID's you want. However I need to debug that a little bit, as it is ignoring me. :)

https://github.com/catduckgnaf/rtl_433_haos_autodiscovery_addon

https://github.com/catduckgnaf/rtl_433_ha

[catduckgnaf]

@pbkhrv can we chat somewhere on the future of rtl_433?

[deviantintegral]

I'm really glad to see work towards a proper HA integration. After several cycles of using the current autodiscovery script with a less technical HA user, it was clear that the current autodiscovery setup is hard to use at best and leads to many extra devices at worst.

However, we have many users currently using the current addons and are happy with them. I doubt we can easily migrate users from an addon to an integration. So, I think we'd need to have a period of time where both systems are supported, and we suggest users migrate to an integration when it becomes stable.

One quick thought: I wonder if it would make sense to refactor out much of the underlying autodiscovery script into a python module that could be shared with both projects. Or even not a real module, just making the autodiscovery script have specific classes or methods that are considered public APIs. In an ideal world, if rtl_433 makes a big change or adds a new device class, the underlying mappings should be able to be updated in the same upstream pull request.

[catduckgnaf]

I'm really glad to see work towards a proper HA integration. After several cycles of using the current autodiscovery script with a less technical HA user, it was clear that the current autodiscovery setup is hard to use at best and leads to many extra devices at worst.

However, we have many users currently using the current addons and are happy with them. I doubt we can easily migrate users from an addon to an integration. So, I think we'd need to have a period of time where both systems are supported, and we suggest users migrate to an integration when it becomes stable.

One quick thought: I wonder if it would make sense to refactor out much of the underlying autodiscovery script into a python module that could be shared with both projects. Or even not a real module, just making the autodiscovery script have specific classes or methods that are considered public APIs. In an ideal world, if rtl_433 makes a big change or adds a new device class, the underlying mappings should be able to be updated in the same upstream pull request.

I was looking into that, and that is why I thought at first it would be best for us to incorporate changes to the discovery script. RTL_433 is a big project, and I think for many who might want to improve, it is too much. I agree, there is zero reason for the discovery script to go away, but the more I thought about simply trying to improve it, the more I thought "We can do better" I do think a "community maintained" discovery script is a better idea regardless. Making it easy to see the code, and prevent large upstream breaking changes from effecting our base.

I also think, from my pre-research into rtl_433 and options, that they have an http websocket api. I think this would be a better approach. I believe it would make it easier for running things in the long term. I have not dug into it yet. I have followed some projects that have had similar approaches, and it looks doable. I took a step back to think, and I do what to start messing around with the http ws before committing that road.

I am definitely a bit over my head, but will be diving more in. Of course any feedback you have is appreciated.

[catduckgnaf]

My add-on is doing great!