Month: February 2024

One thing that was confusing to me from the start was the seemingly overlapping functionality in __init__.py and config_flow.py, but I think I figured it out: async_step_*() in config_flow.py is for when a component is first set up, whereas async_setup_entry() in __init__.py is for when a config entry for the component has already previously been set up, and so an object can be instantiated for that entry.

As for “my API”, my impression (from both core and non-core integrations) is that if I had a published Python package for the device, I’d just import it (like, for instance, RuuviTag integration imports ruuvitag-ble), but if/as I don’t, I should create the API in a subdirectory of my integration and import it using dot notation.

Hence, naming the files inside the API directory is more a question of general Python convention, rather than something HA has opinions about.

---

Anyway, while I understand all the complications I keep stumbling over make HA component development scalable, it also makes my tiny button project way more complicated than it should be. There appears to be no way to build a minuscule MVP with just a few lines of code, to be then extended with all the bells and whistles that would make it look and play nice.

Instead it seems easier to just hack some existing code to work with my device (which I’ve already done, semi-successfully). But that means then having to clean up tons of someone else’s code, or, what’s more likely, just leave it all as an ugly hack, never to be published anywhere.

1. Run systemctl edit getty@tty1.service
2. In the override file, enter

   [Service]
   ExecStart=
   ExecStart=-/bin/journalctl -b -ef
   StandardInput=tty
   StandardOutput=tty

3. To see it right away (without reboot), run systemctl daemon-reload followed by systemctl restart getty@tty1.service
4. To stop the console from blanking, edit /etc/default/grub, add consoleblank=0 to GRUB_CMDLINE_LINUX_DEFAULT, save and exit. Then run update-grub and reboot.

(I adapted the service override from Remy’s old post.)

The documentation keeps referring to “my API”, but leaves everything about it up to imagination. How should I name the file? What code should I put there, and what should I not?

---

The MyEvent example, which I adapted for my event.py, keeps failing to load, because it “has no attribute ‘async_setup_entry'”. I get it to shut up by adding a dummy by that name as a function — not as a method.

---

I grab some logging code from someone else’s Bluetooth integration and adapt it to my _async_has_devices(), to see if I need to do any actual filtering. But none of it ever gets run, despite HA announcing a device being detected by my integration.

In the end I decide it’s not going to be as easy as I’d hoped with the config_flow_discovery scaffolding. I’m going to have to invoke Bleak to be able to subscribe to BLE notifications, which are what my button uses to communicate press events, and which, apparently, are not part of HA core for now. So I revert the config_flow.py changes and go back to the longer version.

---

The first TODO there is for user data schema. I won’t have users input any configuration, so out it goes, as does all of validate_input(), and async_step_user() in ConfigFlow. Likewise for PlaceholderHub (“Remove this placeholder class and replace with things from your PyPI package”).

According to “Discovery steps“,

“When an integration is discovered, their respective discovery step is invoked (ie async_step_dhcp or async_step_zeroconf) with the discovery information.”

This means it should be async_step_bluetooth() for mine. I wish it was listed, along with all other variants, instead of just the two examples, to help googling. An accompanying example would be even better.

The last item on the list of things the discovery step should do is:

“Invoking a discovery step should never result in a finished flow and a config entry. Always confirm with the user.”

Again, not even a hint about this in the documentation, but most core integrations appear to implement a async_step_bluetooth_confirm(), and call it at the end of async_step_bluetooth(). There’s also _set_confirm_only(), which seems like what I need, but again, no documentation anywhere.