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

Configuration
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
59

Is there a way to display the lovelace overview panel without the sidebar, in order to make it look like a standalone app?

Also, is there a way to split up the raw cards config file with includes, like you can with the configuration.yaml file ?

60

Switch to Lovelace YAML mode. Please refer to the documentation, but this disables front end management.

1 Like
61

I’m trying out my HA lingo on you. Do you mean switches are triggers and outlets are a service?

62

Except that they are at opposite ends of the control process. Switches are an input, outlets are an output. Whether it’s a physical, digital or scripted switch… it’s still the start and the outlet is the end.

I’m suggesting a change in perspective in response to the changing environment. In the past, device selection was severely limited by… various factors. Technology of the times, patent-trolls… what have you. Things are changing and devices aren’t just limited to in-wall, mains-powered, closed-platform devices anymore.

Things are opening up… and it’s becoming more about spectrum than options.

I’m trying to suggest change instead of ‘how it is was good enough for how it used to be, why change?’

63

Um… … …?yes?

…to borrow and expand your previous analogy… my brain kinda feels like a can of worms… but after how you do what you do to get the juice out of a can of tuna.

64

I’m doing that already, but I don’t see a way to hide the left sidebar. you can minimize it but can’t figure how to hide it. I tried http://192.168.0.116:8123/lovelace/0 but that didn’t work