Managing DALI gear through abstractions

[sl-wallace]

I'm currently working on building a DALI integration for Home Assistant. I've got some code so far which broadly works, although needs much more testing and optimisation before it could be considered usable.

I'll make the source for it available once I've got something a bit more stable, but I'm wondering what the best way to go about it is – at the moment I use python-dali as a separate library (with a few modifications, which I'm getting ready to submit as pull requests). On top of that I have classes which define what I've called "proxies". These proxies are initialised at start-up by scanning the DALI bus for gear, then each proxy keeps a copy of key pieces of data from the corresponding piece of DALI equipment (most importantly the level, but also things like serial number etc), which can then be queried on demand from any higher-level application. The proxies abstract away all of the DALI commands, and have simpler methods like turn_on, which takes care of the relevant commands. State information, such as level, is queried as needed over the DALI bus. I then have a separate Home Assistant component which uses these proxies to map into the necessary objects that Home Assistant uses.

My question is – does this "DALI system" code belong in this library? Or should I maintain it as a separate project? In following the Home Assistant guidelines, an integration should not have device-specific code itself, but should rather create a layer on top of a more general library. This makes sense, as it would mean the library I've created could be used as a basis for some other system without needing to remove the Home Assistant parts. I'd be happy to try and integrate my code into this project if it would be useful, but I can equally appreciate wanting to keep things separate.

[dgomes]

Hi @sl-wallace

I think you can use python-dali directly in the HA integration without any issues, I used to maintain such integration https://github.com/dgomes/home-assistant-custom-components/tree/master/dali

[sde1000]

(Will comment properly in about a week and a half - I'm running the bar at https://emfcamp.org/ this week and it's taking all my time!)

[sl-wallace]

I think you can use python-dali directly in the HA integration without any issues

Fair enough @dgomes – I'll take a look at your repo and perhaps do a similar thing.

The other thing I have written is a driver for the Lunatone "LUBA" protocol interface. I couldn't quite figure out what the deal was to fit that in with the existing driver architecture, so it's standalone at the moment. It does support most of the same methods as python-dali, to the extent that things like sequences work with the driver I've written. I think the biggest thing I stumbled on was the dual implementations that some of the drivers seem to have, both async and aync. Since my use-case is to run this from Home Assistant, and that now uses entirely async stuff, I wrote my driver with just async in mind. Now that it's largely working I'll take another look at how I might be able to merge it into this repo, but is it a requirement that the drivers here support both sync and async? Or would a LUBA driver that only works with async be acceptable?

[sde1000]

Regarding whether your "DALI system" code belongs in this library:

What I'm trying to do with python-dali is express as much of the DALI standard in code as I can. Most people with DALI equipment won't have a copy of the standard (because it's expensive), and so won't be able to write code to make use of their hardware. This library is intended to enable them to do that, partly by being useful executable code and partly by having lots of embedded documentation that explains how the code relates to the standards. [TODO: generate nice online documentation from the docstrings!]

So: does your code express a part of the DALI standard, for example by abstracting access to the variables in part 102 table 14? Or is it more "opinionated" than that, adding its own semantics on top of DALI? That's the main issue for me. If it's "opinionated" I'd be happy to include it under examples, but if it's a substantial bit of code it might be better off as its own project.

---

Regarding your "LUBA" protocol driver:

There isn't really an existing driver architecture; the drivers module is "anything goes" at the moment and I'll happily take anything. I do have a plan to implement a more formal driver interface in the future (essentially: recognise that programmers making use of DALI want to deal in terms of commands and responses, whereas drivers only need to deal with frames, and make a bridge between the two that references information from part 101 of the standard) but that relies on me having free time and nothing else to do, or a compelling reason to prioritise it. (Historically, "irritation"!)

Async-only is fine by me. Concurrency style isn't a big issue, it's always possible to wrap one style in another.

[sde1000]

(I should also say, the Home Assistant integration sounds like a cool project and something I'd like to make use of myself!)

[sl-wallace]

Or is it more "opinionated" than that, adding its own semantics on top of DALI?

I'd say my code is definitely more opinionated than that, it mostly forms a base layer for the Home Assistant integration and so abstracts away most of the DALI semantics altogether. Having it as a separate library I think does then make sense, I'll continue to maintain it as such – and also drop a link to it here once I can release the source for it.

---

the drivers module is "anything goes" at the moment and I'll happily take anything

OK cool, I'll work on refactoring that then to merge into here – it will then also make my "system" layer code simpler, by not having to maintain a driver level there as well.

[sl-wallace]

I think this issue can be closed then, the answer to my query is that I'll maintain this "DALI system" library as a separate project.

Once I've got it released as open source I'll put a link to it here, for future reference.