Comments (9)
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
from rtl_433-hass-addons.
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.
from rtl_433-hass-addons.
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.
from rtl_433-hass-addons.
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.
from rtl_433-hass-addons.
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
from rtl_433-hass-addons.
@pbkhrv can we chat somewhere on the future of rtl_433?
from rtl_433-hass-addons.
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.
from rtl_433-hass-addons.
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.
from rtl_433-hass-addons.
My add-on is doing great!
from rtl_433-hass-addons.
Related Issues (20)
- rtl_433 MQTT Auto Discovery (next) does not start HOT 12
- How can you tell which version of rtl_433 you're actively using? HOT 6
- How to install in HA Core? HOT 4
- 0.4.1 Stopped receiving HOT 66
- Is it possible to Filter devices and add fields to data to InfluxDB ? HOT 3
- Auto Discovery publishes SCMPlus time value, skips the rest such as gas meter consumption. Case sensitive? HOT 3
- Device added by Auto Discovery doesn't persist across reboots. "This entity is no longer being provided by the mqtt integration" HOT 2
- on AmbientWeather-TX8300 report Battery statur from rtl_433 MQTT Auto Discovery (next) HOT 6
- DEVICE_TOPIC_SUFFIX config problem HOT 8
- Enable devices disabled by default in config?
- New repository HOT 2
- New version 0.8.0 not working HOT 5
- rtl_433 MQTT Auto Discovery will not run after update HOT 6
- Support RTL-SDR Blog V4 Dongle HOT 3
- No MQTT topic visible HOT 2
- Latest version says rtl_433: option requires an argument: F
- Getting started HOT 4
- Config for device trigger conflicts with existing device trigger HOT 3
- rtl_433 does not start anymore HOT 4
- No MQTT topics created - No error in logs HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rtl_433-hass-addons.