I’ve been playing with HA for about week and I have gotten most of my items to discover and customize. I have setup some groups, automatons and scenes and at least tried a script. What’s confusing me I think is all the the *.py things linked to out of github. I get the feeling that these are addon’s for HA but that some may have already made it into the HA application itself. I guess I’m looking for an explanation of the HA application architecture. How do I know when I need one of these *.py extensions vs the standard functionality of HA?
What do you mean? Most of HA is written in Python, so it’s full of essential *.py files.
For anything you see detailed in the components list or in the Getting Started guide, you won’t need to do anything with any .py files. Your configuration will be in your YAML (configuration.yaml)
so the py files I keep seeing referenced in the forum, are those early attempts at something that may be part of the core now, or one-offs where someone decided they could do it better, both? Do they typically replace something in HA and require a rebuild, or are they typically stand alone and called from HA some other way? I’m just concerned not knowing the structure and how things work, that I’ll implement something that hoses my HA install and leave me having to rebuild everything. Which isn’t really that bad since I tar up the install including all the YAML files to a thumb drive when I reach a good stopping point.
Typically, those are posted by people working on fixing or extending existing functionality. Those changes generally make their way into updates that everyone gets when they upgrade HASS.
Is there an easy way to tell which ones have already made it in, and which ones are pending?
Like I said, if it’s in the components list, it’s in. With anything else, there’s not an organized way to tell short of reading through the PRs on GitHub.
1 Like
Usually if someone is working on something here (meaning in the forums) it will have a pull request referenced if they intend to submit it for addition to the core code. If they don’t, it doesn’t mean that it won’t be picked up by another user and developed into a working Component later - the WeatherUndergroud component is a perfect example of this - but it usually means it’s an idea shared but not submitted to the HA code base.
On GitHub you can see these pull requests (PRs) and their current state; i.e. whether they are being tested, still worked on, dead issue, etc. When you see the tag Merged on the PR it means that the code has been merged to the DEV version of HA in preparation for a release.
The PR is where the code is tested on it’s own merits, the DEV branch is where it gets tested for how well it plays along with all the other HA code. Once it’s been determined the code is safe and has been tested well enough, Paulus will create a New Release PR with the version number clearly labeled. Inside that PR you’ll see all the code fixes and new features that will be added once he and the team are satisfied that they have tested things as well as they possibly could.
This is why I spend time in the GitHub repo even though I am not a developer. I get a heads up on what’s coming down the pike as well as looking at all the reported issues so I can better help people here. Hope this helps.
1 Like