I am trying to get my office lights to flash when my daughter gets to school…
I have configured the HA companion app on her phone, and my office lights are added through flux. However, as they appear as an entity and not a device, the option to do something with those lights when she triggers the school ‘zone’ does not appear in the GUI. I can only action things with devices. Is it possible to configure HA to think of these office lights as a device, and not an entity ? I had to use the configuration.yaml to add the platform: flux_led, but this creates those light controllers as entities.
The answer to your topic’s question is: no.
What you want to do doesn’t require that the lights are represented as devices. Automations can be triggered by a variety of sources and can act on a variety of things.
Explain how you are currently creating the automation and we can guide through the process of achieving your goal.
Thanks - that would be much appreciated.
I am using the automation gui accessed through the Configuration menu.
The screen shot is what I have.
Lower down on that screen when I want to create the action, I only get a list of devices to action. However, Office_Lights is an entity therefore is not shown. I would like to toggle them 4 times (so they cycle back to the same state as previous) with a short delay between each - maybe 5 seconds. Does this have to be done in the yaml and not the GUI ?
- Change “Action type” from “Device” to “Call service”.
- Set “Service” to “light.turn_on”.
- Enter the name of the light entity you want to turn on.
1 Like
Sheesh! Devices have made automations so much easier 
1 Like
Brilliant - thanks!
1 Like
Think of it as two different ways to solve the same problem:
Device-oriented Automation:
I have a red apple. What can I do with this apple?
- I can take a bite out of it.
- I can slice it.
- I can peel it.
- I can toss it out.
I choose to slice it.
Service-oriented automation:
I want to slice an apple. Which apple?
- The red apple.
- The green apple.
- The yellow apple.
I choose the red apple.
1 Like
And having the two options creates more confusion than it is worth.
1 Like
@tom_l, @123
I just don’t get the point of adding ‘device’ to the HA mix.
I’ve not being paying that much attention the last release or so.
- Why have they introduced it
- What benefits does it bring
- Is there a write up somewhere
TIA
“To make things easier”
I believe “device” was introduced as a means of modeling a physical device more closely (I believe openHAB uses the word “thing”). A device can comprise one or more entities. For example, my Brother laser printer is a device with entities for page count, drum life, etc.
Beyond that, device-oriented automations supposedly make it easier (when composing an automation) to present the capabilities of a given device. Here’s a red apple, you can bite/slice/peel/discard it.
The limitation of a device-oriented automation is that you are acting on a single device (the red apple, slice it). A service-oriented automation allows you to choose a service that acts on multiple entities (slice, all apples).
1 Like
@tom_l 0.99, eh that was ages ago, thanks for the link, I must have been hibernating 
I’m with you ‘easier’ equates to ‘bloody confusing’. No idea why it seems to be re-surfacing now. (unless the gui editor has ‘just caught up’.
@123 Ahh !
I know understand what you were reaching for earlier (I didn’t get it)
So : -
- service: apple.apple_slice
entity_id: apple.small_green, apple.medium_green, apple.large_red
Vs
- device: apple.large_red
- dice
- immerse_in_cider
- stew
- add sugar
So to re-iterate, do this one thing to multiple entities OR do multiple things to this one device
I understand the link as to a ‘hand’ having multiple entities (fingers, pressures, 1st finger position, 2nd finger position etc. That sort of relates back to the new template watch thing (bdraco).
The bit I didnt elucidate before was that entity_id (the hand) must watch all changes on the hand, but the hand is an artificial construct, so you must assemble all those entities into a group - which forms ‘hand’ and a watcher goes on that.
You know when something has changed because you need to write a new value (not the same as the previous value) to this ‘entity’ (not the whole hand), whereas you see something change in the group (hand), you then have to iterate through the construct. Hence my point that the new method ‘should’ be more efficient.
left_hand _1stfinger_pressure >= 14N - 1 watcher (but potentially 1,000’s of potential watchers)
Vs
Group all left hand entities together, set watcher on that group, a group item has changed, iterate the group to see what changed and how that affects the template (propably less watchers (just hundreds) but a lot of pointless triggers because they weren’t anything to do with 1st finger pressure.
Just a different approach is all - and why the two can’t co-exist.
Not quite.
Service-oriented:
- Select one of many actions (slice/peel/bite/discard).
- Select one or more objects (red_apple, green_apple, etc)
Object-oriented:
- Select one of many objects (red_apple, green_apple, etc)
- Select one of many actions (slice/peel/bite/discard).
In both cases, there’s a single action executed (selected from a choice of several actions). The difference is the first one let’s you execute the action for more than one object.
Hmmm !
You are implying (actually I’m inferring) that you can only execute one action on the selected ‘device’.
Such being the case, the user, has an inherently less flexible method of controlling ‘equipment’
This is counter productive as it means as a newbie that my first automation can switch one light on, as I advance, adding devices, I now wish to control 2 lights and have to completely rewrite my existing code to switch to ‘service’ code or I repeat the instructions on the new device making my code longer, less easy to follow. It’s a lose_lose scenario.
Or have I read that wrong ?
@tom_l is right, this is crazy
No I believe the problem is that the GUI editor has been pushed as the “default” way to write automations and the integrations that create ‘devices’ haven’t caught up.
So now all of the new people (those who have never written an automation the old way using services on entities) who are using the “recommended” way to write automations don’t have any way to know that if their “device” isn’t (a device I mean) then they have to use a different method to interact with it.
And the lack of adequate documentation for the GUI editor doesn’t help either.