Thanks. I’ve been using uptime but thought there was something more practical than that. Now I’m a bit confused, do you mean I could still use the same kind of changes from to like most entities?
What is the state at restart that’s causing you trouble? If it’s unknown or unavailable, see the post above yours. If it’s zero, you could state that too to avoid triggering from that state, but zero might otherwise be relevant and thus cause ambiguity. The other option is to make a template sensor that wraps the current sensor, but it will come down to the same thing you can do on the trigger.
not having read all here, but if you want to prevent triggering on ha start, create this binary sensor
template:
- trigger:
trigger: homeassistant
event: start
binary_sensor:
- unique_id: ha_restarted
# name: Ha restarted
auto_off: 100
state: 'on'
and a condition in your automation for this entity being ‘off’
conditions:
condition: state
entity_id: binary_sensor.ha_restarted
state: 'off'
it’ll allow 100 seconds for your system to settle
2 Likes
Consider this automation below. I used this one since I tested. I borrowed my humidity sensor for test.
triggers:
- trigger: numeric_state
entity_id:
- sensor.bathroom_average_humidity
below: 50
conditions:
- condition: template
value_template: "{{ trigger.from_state.state not in ['unknown', 'unavailable'] }}"
actions:
- action: system_log.write
metadata: {}
data:
level: debug
message: test
Then I used the developer tools → states and manually set the states:
- Set the state to
51 - Set the state to
49→ automation triggers, condition goes through - Set the state to
unknown - Set the state to
49→ automation triggers, but condition fails this time, and automation does not continue
You can analyze the automation behavior from the traces view. The trigger variable is listed there.
At this point I am wondering why numeric_state trigger doesn’t have the not_from optional parameter to specify that if transition is from non-number state, it doesn’t evaluate it.
2 Likes
Got it! Was too tired when I read it. Yes, condition sounds good. I have the helper uptime at the moment but the condition sounds better to me, neater. Thank you
1 Like
My thought exactly. I was like hmm? After checking for peoples solutions I just thought, why can’t just there be the standard that from unknown/unavailable it won’t run any sort of automation unless specifically told to. I’ve obviously only just started so I just thought there was something I was missing. Nevertheless this way works great. Probably my favourite. And I can just save it somewhere so I can easily and quickly grab the code and paste on condition.
Hmm set the states, I briefly looked at states but didn’t know you could set states. Great way for testing things like these. Thank you
1 Like
We’ll need some votes here
1 Like
I have a question:
An argument to use device IDs is when an automation targets a device, and then later an integration adds another entry to that device and you would want to target that new device too.
For example you have an automation that triggers when a light turns on – so you trigger on the device. Later the integration adds another light to that device so the automation now triggers on either light.
Are there integrations that commonly add new entities of the same device class to the same device? I’m just trying to understand how realistic or common that is.
Personally, if I added a new light I wouldn’t imagine it would automatically get picked up by an automation unless I had written the automation to do that in the first place.
Ive not seen it as a regular practice.
Reason. Most ‘devices’ are physical and developers try to reveal the things you a control so I don’t see one thing of a type provided whole they omit another. More likely is one provided and the rest hidden.
It does happen occasionally when integrations are updated and features that were previously unavailable are exposed. I’ve seen it personally when Zigbee quirks are updated. But, as Nathan said, it’s not really a common occurrence.
For light entities the most common thing you might see would be controls added for an indicator light or a screen’s backlight. The one’s that worry me a bit are switch and button entities, since it is common for those to be used for reset or restart.
1 Like
Ok, thanks. I’m trying not to harp on this, but directing (especially new) users into using device IDs for this unlikely edge case doesn’t seem like a great cost/benefit choice. After the recent brouhaha on the dev tools link, I wonder if communication could be improved.
You’re focusing on one of the very minor reasons to avoid using devices. I’ll make sure to direct any questions about replacing a device in an automation your way.
With an entity, it’s simple. Add the new device, rename it’s entity in question from the onboarded entity_id to the old device entitiy’s entity_id. 1 edit. No automation updates.
With a device, you have to manually go through every automation and select both the new device and offending entity.
What would you rather do?
1 Like
I wonder if you misunderstood what I was saying. (And you can simply direct any questions to this great thread. 
)
For good reason (thank you @Stiltjack) it seems like the majority (consensus?) that offer help here see why using device IDs can be troublesome. Yet, it seems the UI steers new users into using device IDs.
I’m curious if there’s a reason the developers seem to be doing that considering the down sides outlined in this thread. An integration adding more lights to the same device seems too edge-case to justify it.
In this case it seems like this could be directly turned into an entity name trigger, right? The entity’s ID is listed after all.
type: turned_on
device_id: 8db213f403c1d561435b62ac5badb031
entity_id: a739f8198dc99f1cc6e868e1a0802861
domain: light
trigger: device
With the new Purpose-specific triggers and conditions, the entity ID is not referenced.
trigger: light.turned_on
target:
device_id: 8db213f403c1d561435b62ac5badb031
options:
behavior: last
Yeah, although it’s often easier than that – just name the new device the same as the old and the entities match up. (Which is one reason I name all my devices with ZUI Smart Start.)
There’s a steep-enough learning curve for new users, so it’s not that fair for them to ask for help about an automation they set up using the UI and to be then told not to use device IDs.
1 Like
Because D comes before E.
Which is why there’s been appeals to rank the entity option higher and to explain the consequences of devices within HA. It’s natural for users to think in terms of devices, so one cannot blame them, but it is frustrating. With the addition of the event platform a couple of months ago, I think there’s now zero reasons to expose the device option. I would personally have built the device option in a way that it still directed you towards entities. The complexity of devices and their IDs should really be hidden from users and should be considered an implementation detail.
2 Likes
Except when it’s not in English and it’s still sorted like that. I still think it was done on purpose, because the devs consider devices to be easier to understand by new users than entities (and they are right in general). Either way, this is going to be replaced by the new purpose-driven triggers, where the UI is really confusing (at least to me), but it prioritizes areas, not devices.
it prioritizes the group based options, not necessarily just areas. It can also target entities or devices too. I don’t believe it’s fully complete for devices just yet. But entities, helpers, areas, labels, floors are partially complete.
I checked now how it (=the current/old design) looks in English, and I’m astonished, that even though it’s sorted alphabetically in English, in Polish it’s neither sorted alphabetically, nor the same way as in English, but even differently… The time and location is between device and entity in Polish version. This feels to me like the device was put on top, and the other two are sorted alphabetically. I think this was done deliberately, not an effect of alphabet sorting.
Alright, I believe you. I honestly tried using that UI for a bit, but it was still missing a lot of triggers, and I was quite confused by it.
You’re using the old menu. The labs menu is what will be the default in the future. It’s sorted alphabetically aside from device.
EDIT: Ignore the colors, I haven’t updated my theme in ages.
I know. Sorry, I was not very clear. I was talking about 2 different things, one was the current/old menu (the sorting there is not alphabetic), and the other thing was the new menu, which I find confusing.