Awww thanks… that’s what I do, that’s how I roll!! lol
I think I just have a unique way of perceiving things that isn’t very compatible with other humans. 
1 Like
where did you learn this approach?
seems similar to how the brain works.
- Automation 1: A part of my brain projects into consciousness the feeling of being too warm. (In your logic this info is stored as a “demand”)
- Automation 2. my problem solver brain jumps in to consider possible ways to remedy the issue.
–Take off a layer of clothing
–turn on the AC
–close the blinds
–move out of the spot so the sun isn’t hitting you
the problem solver weighs these options (checks conditions, i.e. if at work, I can’t control AC or take too much clothing off), and ultimately arrives at one or some combination of solutions. - Automation 3: execute the solution
You’ve compartmentalized your automations and used ‘demand’ as the method for them to interact
2 Likes
That’s when people usually start yelling at me. lol
But I’m an old duck and it just rolls off me.
Here’s my current understanding after reading for a few hours:
Integration aka component: container for code that tells HASS how to work with a specified device or web service. from the dev docs: “Each [integration] is responsible for a specific domain within Home Assistant. [integrations] can listen for or trigger events, offer services, and maintain states”
Platform: rather than recreate the wheel, the author of an integration can choose to use an existing integration which provides same or similar functionality. i.e. wemo hooks into the switch and fan integrations - so the entity ids generated by wemo will have one of these domains. this is accomplished by creating the platform ‘wemo’ against/on the existing switch & fan integrations
Device: usually but not necessarily hardware. I think it presents in the ui as a group of entities. newer term, so there’s lots of talk in the docs about devices before “devices” were a thing in home assistant.
Entity: <domain>.<id> - developer docs say an entity “represents a device”, there can be multiple entities for one physical device, and the device doesn’t need to be physical, can be virtual, like a stock market sensor.
Domain: sometimes called device type, sometimes called component sometimes called entity subtype… not in glossary. not clear to me if a 3rd party integrator has the ability to create a new domain
Is there a list of all possible domains somewhere? these are what I found:
automation,binary_sensor,climate,cover,device_tracker,fan,group,input_boolean,input_select,light,lock,media_player,remote,sensor,sun,switch,vacuum,weather,zone
2 Likes
Oh boy… this is where I get to act smart, even though I don’t have clue. :slight_smile
I have never written a lick of Python. But after learning 10 or more languages they all start to look alike. So I decided to dive into the code located here: core/homeassistant/components at dev · home-assistant/core · GitHub
It’s a snake-pit in there, so go there at your own risk!! I spent oh maybe 2 hours staring at the code in there (like the code whisperer).
What I garnered from my visit is that there is no such thing as a Domain, Integration, Component, Entity, or Platform. It’s a figment of our imagination.
What is there, is a dump of Python modules. Not objects or classes, modules. A module is equal to single file of Python script. It appears there is no such thing as object inheritance. You can only include one module into another and use the module’s functionality.
It appears that module includes are used to create a hierarchy of functionality. For your wemo example, the wemo file is a Python which includes the binary_sensor, fan, light and switch modules. Which in turn the binary_sensor, fan, light and switch modules include the Group module. And the Group module includes the Core module.
This creates a hierarchy like:
Core
---------> Group
----------------------->Binary_Sensor
----------------------->Fan
----------------------->Light
----------------------->Switch
------------------------------------------------->Wemo
The naming convention appears to depend on a modules location in the module hierarchy.
The bottom of the hierarchy is called the “Integration” level
The next level up is the “Domain” level
An Entity appears to be a name (not a module) derived from an Integration module plus its Domain module.
So in this example the Entities are:
binary_sensor.wemo, fan.wemo, light.wemo and switch.wemo
But Domains can be used as Integrations by adjusting the hierarchy like:
This creates a hierarchy like:
Core
---------> Group
----------------------->Binary_Sensor
----------------------->Fan
----------------------->Light
----------------------->Switch
Since binary_sensor, fan, switch, and light are at the bottom, they now become Integrations with the following Entities:
group.binary_sensor, group.fan, group.light and group.switch
Every single ‘entity’ inside home assistant inherits from the Entity class in one way shape or form. For example, the MediaPlayer entity inherits from Entity class, the yamaha component inherits the MediaPlayer class. The core just handles entity behavior. Integrations themselves all contain a method that builds the entities that are created. Integrations can also override any of the properties and methods of the inherited class, ultimately changing the behavior. The domain these devices/entities are created in depends on the what domain/inherited class the developer uses. 3rd party developers can create new domains but you can bet your ass that the ‘main developers’ will shut that down if it doesn’t make sense.
If you want a list of domains in your system, run the following command in your template editor.
{{ states | groupby('domain') | map(attribute='0') | join('\n') }}
automation
binary_sensor
camera
device_tracker
fan
group
image_processing
input_number
input_select
input_text
light
media_player
person
remote
script
sensor
sun
switch
weather
zone
zwave
2 Likes
Hey @123,
I earned my reading badge yesterday!!! LOL
Reader
This badge is granted the first time you read a long topic with more than 100 replies. Reading a conversation closely helps you follow the discussion, understand different viewpoints, and leads to more interesting conversations. The more you read, the better the conversation gets. As we like to say, Reading is Fundamental! 
Thanks for the great response, very clarifying. Do you know where the entity class is defined? It would probably be obvious if I knew Python better.
This is down in the weeds a little, but the core module declares:
“”"
Core components of Home Assistant.
Home Assistant is a Home Automation framework for observing the state of entities and react to changes.
“”"
It claims to be a Python framework, but doesn’t appear to be a well structured or enforced one.
I’m use to using other frameworks like MVC that impose a certain structure which makes the purpose of each module more obvious.
i.e. MVC Framework - Introduction
The only reason I say this, is that I still can’t find my darn Flirc Device anywhere. The Integration name is “keyboard_remote”. As you can see on your list it’s not a Domain and it doesn’t appear to inherit from any Domain class. When I look at the code, it appears to have direct access to core event queue and all it does is shove events up the queues tailpipe. So it appears to be a rogue module running amok within the framework. This would not be allowed in a well structured framework. 
So an ugly little truth is exposed!! hehehe
I’m not sure, but couldn’t it be that there will be no entity created for this device and you only get events from the device. It’s the same for a Hue Dimmer switch I have, the reason being, that this device doesn’t have any state, you press a button and release it, an events gets fired and that’s it.
1 Like
That integration doesn’t create entities. It creates events only. The only way you can use it is by automating based on the events that occur.
platform: event
event_type: keyboard_remote_command_received
event_data:
device_descriptor: "/dev/input/event0"
key_code: 107 # inspect log to obtain desired keycode
This is confusing…
Not quite sure how to ask this, but wouldn’t you say an entity is a pair of 2 modules? One being the domain module and other the “virtual device” module?
For example there is a wemo module that loads up 4 domain modules, binary_sensor, light, switch, and fan.
So any of those modules alone would not be an entity, but combining them together would yield the entities: binary_sensor.wemo, fan.wemo, light.wemo and switch.wemo
I hope i’m right, thats the foundation of my current believe system
Got it. Is there a way to list all integrations like you did for domains? Someone showed me a way earlier, but i think it was a list of entities, not integrations. (edit I meant my integrations only not all integrations, though that would be nice too)
No you’re confusing the entity’s entity_id with the entity itself (Typically referred to as State Objects).
Wemo integration just uses those domains. So the wemo integration can create entities (State Objects) that fall into those domains.
So let me clarify some things.
Integration (Old School Component) A name for a package of python code that handles device communication to home assistant or api communication with home assistant.
Platform is typically 1 to 1 with Integrations (not true for all cases, but that doesn’t matter). It’s the ID that is used to call out an Integration when configuring devices. Nothing more. Example: the wemo integration uses wemo as the platform when we manually configure a switch. I.E. platform: wemo. Do not confuse this platform with platforms in trigger. They are not related, it just so happens that the same naming convention is used to identify what to grab.
Device this is usually the hardware. This may or may not be 1 to 1 with entities (State Object).
Entity this is the State Object. Integrations create this. Its where states are stored for a component. Home assistant core uses the Integration to update the State Objects when changes occur.
Entity Id is the identifier for the State Object. It’s made up from the Domain and the Object ID.
Domain is a way to organize State Objects into groups that make sense. Example: light, fan, switch, etc. Home assistant core will perform different actions depending on the domain. In all honesty, this is the reason domains exist.
Object ID is auto generated by the Integration, but can be overridden by the user. It’s meant to be an identifier that the user can use to know what entity (State Object) that they are dealing with.
4 Likes
Not really. Unfortunately.
1 Like
Congratulations. Rich irony indeed.
You’ve also earned another distinction. By referencing me in a post for absolutely no useful reason (unless goading trolling is considered useful) you’ve also earned inclusion in my Muted Users list. So congrats for that too. Irony indeed.
Farewell and good luck.
Looks like I earned two badges today even though 123 didnt take my post like I meant it. 
sigh…
He took something I said completely the wrong way recently too. I hope he didn’t mute me because I have learnt a hell of a lot from him/her and had some excellent answers to questions.
2 Likes
Did you mean device, instead of component?
This is really good stuff thank you very much!
I read your State Object link 3 or 4 times and the way I read it is that an instance of a State object only supports one state, and that everything else are stateless attributes.
For example a light has only one state on/off. Everything else are only attributes like brightness and color. Did I read that right?
If brightness change isnt a state change for the light how do i know the brightness changed?
Meant integration
No, they are merely implying that the attributes may not exist during at all times (or may not be updated).
The main state, and all it’s attributes are state changes.
If anything inside the state object changes, home assistant will react.
1 Like