HA allows various ways of scripting and automation. I am still blown away of how much stuff can be done in the HA application itself, be it the UI, an embedded editor for YAMLs or extensions like NodeRed.
If you’re proficient with Jinja templating and YAML you’ll get things done. I am. But is that a development experience I am completely happy with?
Not quite, as I keep comparing this to a native development environment. So questions like this might come up:
- I can discover many options in the UI, but eventually, I’ll end up using YAML configs. How do I easily discover APIs and constructs without code completion (or browsing docs all the time)?
- How can I cleanly structure reuse? Yes, we can create and call (utility) scripts, services and automations, but I believe all these items live at the same (top) level. How do I ensure I’ll still find stuff? And blueprints are not more than gists I clone. That’s hard to maintain.
- More complex logic might deserve some (automated) test code beyond live rollout and running through the house to check.
- Other quality tools (black, linters, …) might be interesting.
- How can I debug? Can I set a breakpoint to inspect the data that is passed to my automation? The tracing feature for automations is terrific but it’s not a debugger.
- Maybe I want to use my own IDE?
As a Python developer I looked at the options to script automations in Python, but the above kept nagging me. I wanted a real developer experience.
Python automation options
I looked at these:
- The built-in Python scripts integration is a good first start, but quite limited in features.
- PyScript is much more capable and a very cool project. It’s only a subset of Python though and one of the things it lacks is support for classes (hope I did read this correctly). I’d like to use classes for organization of my logic and not wholy rely on function composition.
- AppDaemon is real Python and does have reuse in mind. As an externally running application it is limited in terms of what it can do within HA, but on the other hand, it is decoupled. And that allows us to run it from anywhere… IDE, I’m coming!
There were more options that crossed my path, but none of them seemed to be in use very much, so I’ll leave them out.
AppDaemon (AD) is a stand-alone application written in Python. It talks to HA over a web (socket) API. This allows running an instance of AD on your local development machine. In fact, you can run one AD within your production setup and connect with another development instance to the same HA, if you like.
The setup of the development machine is:
- Create a virtual environment and install the
appdaemonpackage. Immediately, you are able to call
appdaemon -hto get the CLI help page.
- Install your preferred development tools into that venv.
- AD is looking for configuration to load, typically from a folder called
config, create that as part of your working area. It usually contains this content:
appdaemon.yamlfile. It will be almost identical to the one on the production system, just the own
httpinterface should be set to
appsfolder. This is where your AD apps will be created.
- I use git not only for versioning, but also to (literally) pull updates onto the production system. Watch out to not overwrite anything but AD apps. I use a Github repo as shared repository.
- In the IDE/editor or your choice, consider creating run/debug configurations.
- Take a look at the
-Doption of calling AD, it allows you see your module’s debug log messages in the console.
Having this in place, start reading the AD docs. For me the best initial page was Writing AppDaemon Apps. It explains most of the concepts to get a good first grasp.
And now, start coding, set breakpoints, go to definitions of AD methods to learn, how they do things etc.
To get the best experience (at least in PyCharm), I am using the asynchronous approach (all callbacks are declared as
async def). Besides providing good code completion this allows for very simple sequence programming, as asynchronous sleep can be used.
Here are some impressions of the development experience:
Prepared run configuration
I hope this can be useful for some developers. It would have helped me getting over that initial difficulty of choosing a Python development solution. Let me know how you do development of automations and of course help me correcting false statements or assumptions I might have made.