Devices & Services

[balloob]

Context

Device automations are great, but are limited to devices. I think that we made a mistake calling it a device, as it means that we don't have a similar construct for services like Google Calendar.

Proposal

There are two solutions. One is that we introduce a whole new concept that is going to be 95% similar to devices, but then for services.

The alternative is that we overload the device concept to also be allowed to be used for services. This is already done by AdGuard, where the service is represented as a device. This makes device automations work out of the box.

This issue was triggered by home-assistant/core#26997

@frenck has also touched upon this on Discord

I personally believe that naming another part of our stack Service is the right thing to do. I do not like the word "Thing" because by trying to avoid confusion across the stack (we have service calls in the core), we end up with a word that is too generic to describe what it covers.

I have discussed this with Frenck too and he proposed to use Devices & Services for UI. I like that a lot. Internally we would keep using the word device.

Google Calendar Example

We should distinguish between services and sub-services, each their own entry. So in the case of Google Calendar we would have Google as a device and each calendar as a device.

Consequences

Things like AdGuard and Calendar will be able to provide device automations.

[pvizeli]

I agree to open it for all kind of grouped services.

I personally like the "Thing" renaming. Because we are free and with less confusion to abstract "things" handling as a kind simple handling.

[dgomes]

I agree, and "Thing" is already established, we should go with it.

[balloob]

Things is an established term for developers, not for the general public. You see bigger brands generally use the term "Works with X"

[pvizeli]

If we speak about "Thing", I would know that is an integration abstraction or bundle for automation action/condition/trigger (maybe later more).

If you speak about a "device", It going to be ?? A real "device", a "device" with an abstraction like as representation or a lot of other stuff that goes to my brain and in the end, I need to ask you what kind of "device" you mean.

[ties]

If you speak about a "device", It going to be ?? A real "device", a "device" with an abstraction like as representation or a lot of other stuff that goes to my brain and in the end, I need to ask you what kind of "device" you mean.

In any case, it would be good if the difference between the term picked there and others (e.g. entity) is understandable for the general public.

Terms such as "thing", "unit", and "entity" are not that informative, they are akin to a top type (such as any or Object) in that they can mean anything.

[balloob]

Yeah, that's why I like the terminology "Devices & Services". It covers 95% of the things.

[Hedda]

+1 for "Things" taken from today's meaning of IoT => https://en.wikipedia.org/wiki/Internet_of_things

I personally agree that the word "things" is a bit of a corny and might currently be considered overhyped, it is still a fact that the word "things" in this context is today already established as the industry standard synonym because of the word being part of "Internet of Things (IoT)".

The terms "Internet of Things and "IoT" is surely here to stay, and I personally believe that the feeling of corniness when saying "things" in this context will soon go away as home automation and thus also the term Internet of Things becomes common and part of most peoples lives, just as smartphones, tablets and smart TVs are today more common than not. That is, for the general public.

[ties]

What about an alternative route: Call this automations (alternative: automated tasks) and rename the old automations to advanced automations?

This establishes the norm of automations working at the device/thing/unit/entity level and offer logical actions that you actually want, instead of effectively being scripting where you need a lot more conceptual knowledge.

[emontnemery]

Does it add value to bundle entities of a service as we do with devices?

If not, there's a third alternative to the two proposed by @balloob: Allow integrations to expose automations through their entities just as devices are allowed to?

As an example, sun should expose some helpful automations to trigger on dawn/dusk and there most likely is no need to support multiple sun "things".

[balloob]

Things might be the industry standard name, but that's not how users perceive it or what works in communication with users.

Just check some smart home pages from major brands:

https://store.google.com/us/product/google_home_smart_home?hl=en-US

https://www.amazon.com/b/ref=aeg_lp_sh_d/ref=s9_acss_bw_cg_aegflp_4b1_w?node=17934679011&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=merchandised-search-6&pf_rd_r=SQYWEZ6YPPSKJCWP9HYW&pf_rd_t=101&pf_rd_p=02147624-e148-4901-b449-773097cfa62e&pf_rd_i=17934672011

https://www.smartthings.com/

https://www.wink.com/

https://getvera.com/

[dgomes]

one of them is actually called smartTHINGS ;)

[frenck]

I know I used “Things” (quoted) as a placeholder, because I lacked a better word to use. I don’t like it.

Devices & Services has my vote

[dshokouhi]

Why not simplify things and just call it a product? Google Calendar is a product from Google. Nest Hub is a product from Google. Don't get specific about things being tangible or not. The moment you have to explain to a user the reasoning behind your terminology its already a loss. Things should be cut and dry from the beginning.

Smartthings is a bad example here because while they do say "Works With" on their website in the app itself it says "Add device" where previously it actually said "Add a thing". Also all of the items listed are physical.

But why do we need to differentiate between devices and services? Does the user actually care? Probably not. To them they just want to know if their product will work and be compatible.

[pvizeli]

Ident, "Things" are like copy from others. What is about "Gears" or "Gadgets"?

[balloob]

So this was about the internal type of services and it got completely derailed, closing this issue.