What is an Integration, Device, Entity, Component, Platform?

Configuration
35

These naming and classification issues are often the artefact of software abstraction. When you want to support a large array of different devices/behaviours/services you have to create abstractions and group different types of behaviours. However, not everything fits neatly into any one particular set of abstractions.

You can propose different abstractions, groups, classifications and some sets will be better for some things and some for others, but you will always end up with some outlying weirdness.

Switch is a classic example, as the word “swtich” is both noun and verb, so is ambiguous. “A switch” can be seen as a device that allows something to be controlled - a light switch affords switching something. “To switch” is to actually enable/disable/select/toggle, power on, power off a thing - a plug outlet “can be switched”… and of course in our whacky world of automation a light switch can switch a plug outlet on!

It doesn’t matter if you base your abstraction/naming/classification model on verbs or nouns (behaviours or properties) there will always be outliers. If you attempt to use a mixed bag of nouns and verbs it might just be confusing.

The other aspect that often causes issues is the perspective and context. When you look at things on paper or a whiteboard during design things appear clear, but when you come to implement them and find that some things you labelled as distinct actually turn out to be pretty much the same thing and are so close to being the same thing, you end up using the same construct to define them.

This is not new in Home Automation, but has been a challenge for software engineering since it began. Take a course in computer networking and you will find any network can have multiple views that look completely different depending what questions you are trying to answer or what properties of the network you are trying to communicate. Not just one or two, but sometimes dozens of seemingly distinct diagrams of the same network.

I could propose different naming/abstractions for home automation, but it wouldn’t matter as I doubt there is a perfect model that will please all and not have ambiguity or confusion somewhere. In my own home automation software I hid the confusing details close to the devices. If I want to control heating, I use a heating controller, whether that uses one type of switch, relay or another, or actually swtiched 6 different things or if it turns the heating on by posting a facebook message is hidden there in. But I am not dealing with the 100s of different devices available all at once like HA is. I’m only dealing with the handful I have and can add code to support different ones as they are needed. A privileged position that not many are in.

2 Likes
36

It switches the thing that’s plugged in to it on and off. What category do you think would be a better match?

37

Hi,

Goto Developers tools, then States, then select group.all.devices Sorta wish States could be renamed to Devices. It would make more sense to me, because I believe State is a simple attribute for a device.

38

I’m thinking that if the cognoscenti are confused the rest of us have no chance :rofl:
Seriously, it is mostly a problem when communicating an issue as we don’t all share a common vocabulary, hence sometimes we use the wrong word and confuse each other.
I think the above discussion has helped a lot though

1 Like
39

because a switch has two distinct states - on or off. And switches are used as a power control device.

And an outlet has the same two distinct states and use.

they are functionally equivalent.

the developers could have made outlets and switches into two separate domains to be more precise but there wouldn’t be much more to be gained in functionality.

No, “states” are not “devices”. And neither is an “entity”. A device is a piece of equipment. A state is the condition an entity is in right now.

The old frontend UI before Lovelace was called the “States UI” and it was relatively restricted on how much it could be customized. That “pretty nice format” is an auto-generated listing of all of your *entities" (not devices) because that was the way it used to work before Lovelace if you never defined a thing called a “view”.

that would be “group.all_devices”. a minor change but a huge distinction in function.

That entity is a list of all of you devices that are a part of the “device_tracker” domain.

I doubt that’s what you are looking for.

really, you could create a card and successfully added an entity to it called “all.entities”? I would be surprised if that were true.

As far as I know, an entities card only accepts entity_ids as it’s contents. “all.entities” isn’t a valid entity_id.

40

You sound like an old fart like me. :slight_smile:

I felt like I just opened a can of worms in my brain. Until last week I’ve never looked at or played with Home Automation, until my alarm system (Honeywell Vista) crapped out on me. I had some guy come out to look at it and after I saw his huge quote + monthly fees, I looked around my house and counted 4 motion sensors and 5 door/window motion detectors. After thinking about it, I said to self, self: you could do this yourself, and do it the way you want with all the latest coolest gadgets.

I started dreaming of all the things I could do with my remote control or a web app to do all the things that a harmony hub could do for entertainment and all the surveillance and security things I could do like the ring you see on tv, and all the control I could have over my lights, fireplace, and curtains. Wow, this is going to be cool.

So I started my little project a few weeks ago, and it didnt take long to get hit with a dose of reality after I couldnt find a decent zwave siren/chime to use. It hit me that Home Automation isnt the panacea I thought it would be. It is just a component of your home for controlling appliances and that home entertainment and home security are totally separate components. They all have their own set of devices and lingo and requirements.

After coming to this realization, I was a little discouraged. But not too much since I can see these three areas of your home are beginning to overlap each other and eventually will get mashed up into a single comprehensive component that beautifully gives you control over your “Whole Home”.

But that aint the reality of today, so until that day comes, I can see its going to be a bitch to develop a comprehensive unifying model where all the lingo is well defined and syntactically correct.

Actually, its kind of exciting, because I can see big opportunities for the ones who can pull this off.

p.s. until i get my secrity system working, I’m going old school and using a baseball bat! lol

41

5 posts were split to a new topic: Honeywell Vista

44

And as far as media players are concerned there’s these at a minimum: https://www.home-assistant.io/components/#search/media

45

That is what I was trying to say… a state is just an attribute or condition of a device and so it would make more sense to me to look up the device to find out what state its in.

Correct me, but my understanding is that an entity is simply a unique id assigned to devices for hassio to refer to in automation scripts and other stuff. If thats true, than an entity is also simply an attribute of device and again It would make sense to me to look up my device to find its state and entity id.

I’m using

    cards:
      - type: entities
        entities:
          - entity: group.all_devices
        title: Entities
    badges: []
47

Thanks.

Well i do use directv, sonos, kodi, amazon firestick, and visio tv so I saw some that should be useful.

48

OK, I will…:wink:

I’m pretty sure this was covered up thread but, again, a “device” is a physical piece of hardware. A “device” potentially has one or many different functionalities or aspects to it. Each of those functionalities has to be accessible to the home automation system for you to be able to do anything with it. Those accessible functionalities are split out into “entities” that HA can interact with. Each “entity” has a “state” and could have other related “attributes”.

Let’s take one example as the Aeotec Z Wave mutli-sensor. It provides a sensor for temperature, humidity, lux, motion, vibration (and one more I can’t remember but you get the idea). each of those functions for one device is split to it’s own “entity” and is assigned to a standardized “domain” along with a follow on specific id (in the format of “domain.id”) so for most of these for the Aeotec sensor they will be in the “sensor” domain. But there is also a “binary_sensor” domain for the motion sensor. and there is another “zwave” domain for the non-sensor related stuff like the name of the device, battery levels, node id, etc.

Another example is a smart bulb. when you add that one device you now have several other functionalities that are encompassed in that one device. there is the power state of the bulb itself (on/off) and the other attributes of the bulb could be color/temperature/etc. Which is why a lkight bulb is it’s own separate domain. Because you have to be able to control those different attributes than provided by a switch (or outlet). And then some bulbs provide power monitoring so you need another sensor for that. And then there is the catch-all functionality of the device as in the node, etc, etc, that isn’t specific to the light or sensor functionality itself.

I don’t disagree that it would be better to have every configured device listed somewhere along with the associated entities and that is starting to happen. It’s just that not all devices are supported yet. And one requirement for a “device” in order to have it properly associated is that it has to provide some form of unique id when the device is integrated pr paired to the system. Not all devices will/can do that so there may never be a time when every device will be listed in the device registry.

EDIT to add:

And some of this is kind of an arbitrary design decision that was made a long time ago so it could have been done differently. It just wasn’t. And some things are a lot harder to change now.

2 Likes
50

“all.entities” isn’t anywhere close to being “group.all_devices” and I was questioning the “successful” use of “all.entities” in the entities card.

And “group.all_devices” isn’t what you want it to be. As I mentioned, it’s just a list of all the devices you have in the “device_trackers” domain.

1 Like
51
  1. You’ve described a group … which is a far cry from what your original statement said about clicking “all.devices”.
  2. The entity_id is group.all_devices not group.all.devices. An entity_id is composed of a domain (like group) and an object_id (like all_devices). A period serves as the separator between the two (and reserved for that purpose).

We’re all on equal footing when faced with misinformation.

2 Likes
52

Yes it was discussed here: What is an Integration, Device, Entity, Component, Platform? - #12 by HeadHodge

This is a great post and I think I totally get what you’re saying now.

What you are calling a Device l called it a Device also. What you are calling an Entity I was calling it a ‘Virtual Device’.

I was also thinking out loud earlier that maybe a better term for Device would be Product and that a better term for Entity would be Device, or Logical Device, or Virtual Device. A Product doesnt have to be a physical device, it could be software (like an emulator/simulator) too. I think an Entity is a too generic term. If you look at relational database lingo, an entity is anything with a unique entity id used for linking 1 to many relationships.

But I’m flexible, i can talk Device and Entity lingo, now that I understand it better, Thanks!!

53

I understand now, thanks!!!

54

Got it… thanks. I apologize for my sloppy notation, because I did not understand your naming convention. But now I do.

55

That’s the phrase I was looking for!

I knew it had a more descriptive name compared to just “id” but I couldn’t remember it off the top of my head.

I almost said “device_id” but decided against it because I was pretty sure that wasn’t right and I knew it would just confuse things even more. :laughing:

1 Like
56

BTW My favorite “entity” so far is notify.notify lol

57

Thanks everyone (human.all_topic_replies) for your help to free me from my brick of ignorance!!

58
  • “Lights” for lights
  • “Switches” for switches
  • “Outlets” for outlets
  • etc.

Think about it. A switch (in the context of a physical.device) should be a physical interaction. Be it a GE in-wall EZ Smart Switch (mains power only, no physical device connection (ie: mains-powered light circuit) ), zwave-only), or a Sylvania/Osram (stick-on-the-wall, battery-powered, zigbee) 4xbutton switch…

An outlet is something that can be switched… switches and outlets are at opposite ends of the process flow. For the most part- switches are an input and outlets are an output.

Ultimate goal being better categorization of devices and how it could allow for things like better, clearer device setup and event scripting.

1 Like