#Documentation for Actions

90 messages · Page 1 of 1 (latest)

stiff rain
#

I'm attempting to create an automation (or something) so that whenever a motion sensor is tripped, my office light becomes red.

To do this, I'm creating a "New Automation", and in the "then do" section I have the following by default:

type: turn_on
device_id: 109a76a1a8be6aabece76b3663b2ab85
entity_id: cae5a0423a25ec2d114ee71d8a5b91fe
domain: light

Where can I find the documentation for "type" there? I am curious to know what the available types are, as an example.

And what syntax do I have available in this section?

I'm aware of the documentation, with the relevant section seeming to be here: https://www.home-assistant.io/docs/automation/action/

However, it never mentions the keyword 'type'.

Home Assistant

Automations result in action.

tranquil quiver
#

You are using device actions, which are defined by the integration that creates the device. There’s some documentation here but it’s aimed at developers and not users.

stiff rain
#

So, the 'type' there is because the integration providing the device uses that as a keyword?

tranquil quiver
#

You may benefit from this post on what alternative to use instead

stiff rain
#

Makes sense.

tranquil quiver
#

The type key is there because that is the architecture of the device action in HA. The value specified after type and what it means is defined by the integration

stiff rain
#

I'm guessing the integration also provided the template?

#

What I'm attempting to do is learn enough of this yaml interface so that I can change the colour of the light.

tranquil quiver
#

Device actions are only for UI. You want plain old actions for yaml

stiff rain
#

Fair, I feel yaml is what I'm after.

#

Lets consider this example from the post you referenced:

  - platform: numeric_state
    entity_id: sensor.mobile_battery_level
    below: "20"```
#

What's the 'platform'?

tranquil quiver
#

For charging the color of a light, in the UI, add an action, and in the dropdown select “light” and in the next selection choose “turn on”. Then you’ll get a bunch of options and one of those is color. Once you have it configured how you want, switch to yaml to see what it looks like

stiff rain
#

So it's the type of the trigger, effectively

tranquil quiver
#

Yes, and next month the word platform (in the context of triggers) will be replaced by the word trigger

stiff rain
#

So the example becomes:

  - trigger: numeric_state
    entity_id: sensor.mobile_battery_level
    below: "20"```
tranquil quiver
#

All the main keys will be plural also, so yes except the first line will be triggers:. The idea is that you’ll have triggers: followed by a list of triggers, conditions: followed by a list of conditions, etc…

stiff rain
#

Very nice.

tranquil quiver
#

For yaml actions, start by using the UI but instead of choosing device, choose “light” and then choose “turn on”. Then you can configure the color or other specifics, and then switch to yaml to see how it looks

stiff rain
#

The main complication I have with using the light.turn_on action is that I don't want to turn the light on if it's not already on.

So I guess I should add the light state itself as a condition.

tranquil quiver
#

Yes. It’s not possible to change the color without turning it on unless the actual hardware supports something very unique, and then you’d have to send something special like setting a zwave parameter

stiff rain
#

One thing I often struggle with is not knowing the possible attributes or their potential states.

tranquil quiver
#

So if all you want to do is change the color but only if it’s already on, then do as you suggested and use a condition. If you want to change the color so next time someone turns it on it will already be a different color, you’ll need something more complicated

stiff rain
#

For example here, I'm attempting to explore how I can determine if the light is already on:

tranquil quiver
#

If you want to check if the light is on, that would be the state, not an attribute

stiff rain
#

Ah, beautiful. So for that, I can check that the brightness (I guess case doesn't matter?), is at least 1. (It is currently 255)

tranquil quiver
#

Every entity in home assistant has a state. That is the main “value” that an entity provides

#

That will be listed under the state column in the dev tools page

#

Most entities also have attributes, which are other pieces of information attached to the entity

stiff rain
#

Ah, so 'state' has special meaning. That's cool.

tranquil quiver
#

In an entity is a light, it will have a state of on or off (or can also be unavailable or unknown)

#

So in the ui for conditions, select entity -> state

#

And leave the attribute dropdown empty

stiff rain
#

Aha!

#

So i'm supposed to leave that empty if I don't care about the specific attribute.

tranquil quiver
#

Correct

stiff rain
#

I'm noticing that as I update the identifiers of the entities, as I prefer to have them set to names that logically make sense to me...

#

I can't change the whole thing?

#

(update is in grey, so I assume that means I can't change that part of the name?)

#

The full automation I have right now is as follows:

description: ""
trigger:
  - platform: state
    entity_id:
      - update.aqara_motion_and_light_sensor_p2
    to: Detected
condition:
  - condition: state
    entity_id: light.office
    state: "on"
action:
  - action: light.turn_on
    metadata: {}
    data:
      rgb_color:
        - 237
        - 51
        - 59
    target:
      entity_id: light.office
mode: single

But it would make more sense if it was obvious which aqara motion and light sensor it's refering to, so I was looking at updating that identifier.

tranquil quiver
#

Yes, to be clear that entire line is the entity_id which is used by the backend and yaml code to be the unique reference to that entity. The name is the field on top, often known as “the friendly name” which is used all over the frontend (dashboards and the UI).

The first part of the entity_id is called the domain and that is defined when the entity is created and controls what the entity is and what it represents. It cannot be changed. You cannot edit that text and simply change a light to become a sensor for example.

stiff rain
#

Ah, so the identifier also contains meta data. I had assumed it was just a convention.

tranquil quiver
#

Yes and home assistant interacts with different domains differently. There is a light.turn_on action that can turn on anything in the light domain, but it can’t turn on a sensor and there doesn’t exist a sensor.turn_on action

stiff rain
#

I'm noticing something strange.

#

This entity: update.aqara_motion_and_light_sensor_p2, appears to be the device, and that device uses a different entity for the "Occupancy" status?

tranquil quiver
stiff rain
#

I'll have to go through that.

tranquil quiver
#

Devices do have device_id’s but you won’t need them except for advanced topics

stiff rain
#

Ah, so that's explaining why I was often seeing references to firmware attributes, etc.

tranquil quiver
#

Yep

stiff rain
#

I'll change that in the yaml instead to: binary_sensor.side_door_sensor_occupancy

#

Can I trivially simulate the automation, instead of walking all the way out to the actual sensor itself?

zinc fjordBOT
#

To test an automation there's three stages you can follow. Testing the action, the condition and action, and the whole automation:

  1. Use Configuration -> Automations to find the automation and then select Run in the three dots menu. If this fails your problem is in the action: section, and details should be found in your log file
  2. Use Developer tools -> Services and call automation.trigger on the automation with skip_condition: false. If the first passes but this fails then the problem is in your condition: block
  3. Use Developer tools -> States to find the trigger entity, click the name, then change the state (at the top) to something that'll trigger the automation before pushing Set State. If this fails then the problem is with your trigger: section, or the automation is turned off (you can check that in Automations, automations that are turned off will show Disabled)

You can also see this section in the docs about testing and automation traces.

stiff rain
#

Hmm, now the room is pretty dark. 😆

#

I have a red tint, but it seems to be significantly dimmer.

#

Can I have "When a state changes to anything except detected"?

#

I suppose I could do 'if state changes at all', and then in the condition, add 'not detected'.

#

Doesn't look like it.

tranquil quiver
#

There is a not_to option in the state trigger (link)

#

The alternative you suggested is also possible, but in this case less efficient

stiff rain
#

I see, the former requires I drop into the yaml, which is fine.

#

So this seems to be working well - thanks for your help. 🙂 (And I have more reading to do! 😆 )

Had the idea that I should use colour to indicate if someone has arrived at the door. Lets see how annoying that gets - hopefully less annoying than flashing lights.

#

I did notice another odd thing: Setting colour to 255,255,255, doesn't seem to be full white.

#

Yep, it changes the colour temperature as well.

tranquil quiver
#

Depends on the device. Some lights will have both color and white leds (and some even have warm and cool white leds). Setting rgb just controls the color LEDs

stiff rain
#

As in, that automation seems to set the colour temp to "null".

tranquil quiver
#

You’d have to play around with what you want to set. There are options for color temperature

stiff rain
#

I notice that if I tap on the light I can change the colour...

This sets the colour temp to 6535 kelvin.

However, in the automation, the maximum temp is 6500 for some reason.

#

Looks like when setting it to 'red', it sets kelvin to null.

tranquil quiver
#

You may have to send a kelvin value when setting the color. But check your yaml to make sure a null kelvin value isn’t being sent

stiff rain
#

I've worked out just now I can either send kelvin, or send colour.

tranquil quiver
#

Honestly that makes more sense. Were you trying to send both originally?

stiff rain
#

Yes, because the developer page showing states shows a colour and kelvin setting.

#

Was trying to match it back to that.

#

Could I configure an automation to set the kelvin temperature back and forth a few times?

#

(ie, to flicker it)

tranquil quiver
#

You have to do a repeat loop using actions and delays. Unless the hardware supports setting an effect

stiff rain
#

I very much doubt the hardware supports an "effect", but how would I check?

tranquil quiver
#

you'd see the option on the control of your light:

#

You'd also see effect_list as an attribute of the light

stiff rain
#

Oh very nice. Looks like mine don't have that - what's yours?

tranquil quiver
#

that's an esphome device, so I can make the firmware support whatever I want

stiff rain
#

Ah, very nice indeed. Fully custom hardware, or just reflashed with esphome?

tranquil quiver
#

it's just reflashed, it's the globe ambient light https://www.amazon.com/Globe-Electric-50239-Automatic-Changing/dp/B08X72JY3V