Device Automations

Development
1

There’s an architectural enhancement underway based on this defining PR:

I’m embarrassed to say that I’ve read balloob’s description a few times yet have failed to understand its real-world implications. :thinking: :man_shrugging:

Given that I learn best from examples, can someone provide one of how we will use ‘device automations’?

Is this something that will simplify the creation of automations via a UI? What will that process look like? What will its YAML equivalent look like?

2

It enables platforms to expose user friendly actions, conditions and triggers.

E.g. with deconz remotes are only hass events, but through device automations they will expose the different button presses as available triggers to use through automations frontend.

3

OK, so instead of triggering via the event platform, and having to know which event to monitor, you select the button and it provides a list of the triggers you can use with it. Do I have that right?

4

Exactly right!

5

I found this recent Pull Request 3637 showing a screenshot of how it will look in the Automation Editor:

I think this will be a significant improvement, especially for new users.

In YAML automations, this new capability will have a harder time to show its strengths. However, if the Visual Code plugin will support Device Automations, then that will definitely be helpful.

6

You can also see my PR for deCONZ here: https://github.com/home-assistant/home-assistant/pull/26366

528×884 69.1 KB

3 Likes
7

Well done! :+1:

I believe this approach, to creating automations, will prove to be more intuitive for many users (notably first-timers).

I’d like to share with you a screenshot or two of home automation software that was first conceived two decades ago. I’ve been using it (Premise) for over a decade. In fairness to volunteer developers of Home Assistant, this was a commercial product (created by a small team of ex-Microsoft developers and professional systems integrators) that sold for about US$1000 back in the day (and then released for free, in 2006, when it was discontinued).

Shown below is a tree-view of areas (buildings, floors, rooms, etc) and the objects they contain (“Devices” in Home Assistant parlance). I wish to create an automation for FoyerLight so I right-click it, select New > Script and it presents me with a list of properties I can use for the trigger:

Premise%20-%20Object%20Properties%20for%20triggering%20Light
Premise%20-%20Object%20Properties%20for%20triggering%20Light336×559 11.7 KB

Effectively, this is what Device Automations will offer for Home Assistant, namely guidance for selecting appropriate triggers.

Returning to my example, if I select the PowerState property, the tree-view now shows that FoyerLight has a script called OnChangePowerState.

Premise%20-%20OnChangePowerState

I then proceed to write code for the automation (using the built-in editor with syntax highlighting, code-completion, and debugger). This is where Home Assistant’s Automation Editor has an advantage because it provides additional guidance for creating the balance of the automation (conditions and actions).

You may have noticed the dialog-box has two tabs: Bindable and All. I won’t get into the details of ‘bindable’ and just summarize it as the most relevant properties for that particular object (a light). If I wanted to trigger on some other property of FoyerLight, I’d select the ‘All’ tab and see this:

Premise%20-%20OnChangeProperty%20-%20All%20Light%20Properties
I can create an automation that triggers when there’s a change in the object’s name, icon, group membership, etc.

One more example, this one is for buttons:

Premise%20-%20Object%20preoperties%20for%20triggering%20Button
Premise%20-%20Object%20preoperties%20for%20triggering%20Button315×535 8.13 KB

Thanks to you, Home Assistant will have an edge here because, in Premise, you have to refer to the documentation to know the values of ButtonState (hold, release, etc).

I really think this new approach will be a game-changer. Keep up the great work!

2 Likes
8

Thanks for the screenshots of the other system. That is very helpful. I think that one of our weaknesses is that we don’t do enough exploration of what other people come up with.

Some extra (unorganized) notes to help clarify device automations:

  • Device automations will not just be for triggers, but also for conditions and actions.
  • Device automations can be defined either via YAML or the UI. In YAML it is a bit more difficult right now to figure out all possible options. UI will have a filtered list. (Maybe we can get this into the VS Code extension?)
  • Everything that device automations do, should be able to be done with the other trigger types for automations. We don’t aim to get something be “device automation” only.
  • Actions usually are more configurable, like setting color / brightness for a light. We don’t have a proper UI solution for this yet. I have been thinking of extending our scene integration to add a “create scene from current state of these entities” functionality, and use that in actions.
  • Listed triggers are provided by all integrations that provide entities related to this device. Let’s say we have a WiFi light bulb, which has light triggers (turn on/turn off etc). Since it’s WiFi, it is also picked up by the Unifi integration and so now we will also have “Connects to the network” and “Disconnects from the network” as available triggers.
  • Some lists of possible triggers can get very long in the UI. We will probably allow integrations to mark certain triggers as feaetured, which will be shown first. A user can click a “Show all possible triggers” option at the end of the list to show non-featured ones too.
  • Most of the built-in integrations do not have support yet. Hopefully in 0.100.
  • Any integration is completely open to provide anything they want as a trigger/condition/action.
  • This all works for custom integrations too.
  • All device automations will be able to be localized in all supported languages
  • With the recent introduction of advanced mode, once device automations is mature, I am planning to hide in simple mode all automation functionality that relies on internal HA things (states/events/services). So Simple mode will just have things that a user can understand without knowing our system: devices, sun, time.
5 Likes
9

Oh, and to get back to your original question, the YAML equivalent (and this is also what the automation editor will generate):

- id: '1566498630483'
  alias: Test template condition
  trigger:
  - platform: device
    device_id: "7a92d5ee74014a0b86903fc669b0bcd6"
    domain: light
    type: turn_off
    entity_id: light.bowl
  action:
  - service: camera.turn_off
1 Like