I don’t think one should take the term switch too literally. It’s just a generic way of referring to a component that can turn a device on/off.
It’s like the term cover. It controls awnings, garage doors, shutters and basically anything (motorized) that can be used to cover an opening. Similarly, the term climate controls HVAC devices. I suppose it could’ve been called thermostat but climate is more generic and can refer to devices that have no physical resemblance to a traditional thermostat.
Yeah, youre right, its really no big deal. Whatever gets the job done. You call it an entity, I call it a virtual device, you call it a swich, I call it an outlet. No big deal.
However Its hard to ignore my real life experience when envisioning what I’m trying to accomplish. In this case, in real life my experience was watching my electrician physically wire a wall switch to a power outlet. When you flip the switch electrons physically flow from the switch to the outlet via the wire. But of course thats not at all how this smart stuff works.
So I suppose there are good arguments that say your workflow should model reality, or one that models more abstract traditional non-smart devices.
For example Im using a Flirc with my tv remote to fire hassio events. I think I’m using a tv remote, but hassio thinks its using a keyboard. So which device do I use in my workflow? A tv remote or ascii keyboard? Fun thinking.
I have a fountain connected to an outlet. The outlet is controllable. In Premise, I have a choice of modeling it as either:
controlling the outlet (true, literally)
controlling the fountain (true, but indirectly via the outlet)
For my purposes, I chose option #2. I want the appearance of controlling the fountain. The fact that I’m actually controlling the outlet is less important. In this scenario, the outlet is just a means to an end.
FWIW, I have two controllable outlets and neither is modeled as an outlet (but as the appliance connected to the outlet). In Home Assistant, you don’t have a choice; you simply model it as a switch (it’s not fancy but it works).
Maybe enhancing Home Assistant to allow user defined Groups would be at least a partial solution to this conundrum. If not that maybe provide for alias names, like they do with the “Friendly Name”?
I’m not following you here; Home Assistant’s groups are user-defined already.
Did you mean user-defined components? In other words, allow you to create a new component called ‘outlet’ that’s based on the existing switch component?
Because if that’s what you mean then I doubt that’s feasible without some major changes under the hood.
That’s because of the reasons as I already talked about in those long posts above.
The first part of the entity_id (the thing you are trying to change in your example) is the “domain”. You can’t easily (if at all…) create a domain on a whim. You have to stay within the domains already available in HA.
And this is where the transition away from yaml configuration toward GUI configuration causes a disconnect in knowledge. Most newer people who don’t have any experience programming things manually won’t really easily understand when I try to explain that “most top level code in the configuration.yaml files correspond to the domains available.” if you don’t spend any time in that file or in trying to manually configure things then you won’t understand what “top level config” is.
With all due respect, even just musing about the inability to rename cover to awning demonstrates a lack of understanding of Home Assistant’s fundamentals. I urge you to read the documentation and review the examples it provides. Otherwise, you’re going to have an extremely difficult time with Home Assistant.
I didn’t think you could change it, i just thought it was called group not domain.
Here’s where I went awry from a previous post:
You’ve described a group … which is a far cry from what your original statement said about clicking “all.devices”.
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).
I confused group for domain. sorry about that. all your posts werent for naught
Well that’s wrong. I just misused the word domain for group from misreading a previous post. I was using group generically cause that how i read it.
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).
Maybe enhancing Home Assistant to allow user defined DOMAINS would be at least a partial solution to this conundrum. If not that then maybe provide for alias DOMAIN Names, like they do with the “Friendly Name”?
Note: if you take my post in context with the proper name, its obvious I dont believe its something you can do.
Sorry about using the incorrect term. Please forgive
Whether confused or misused, wondering why one can’t change a domain’s name is still indicative of a tenuous grasp of the fundamentals. Components are the ‘building blocks’ and an entity’s domain name indicates which building block it is using. Home Assistant doesn’t support renaming these building blocks or giving them aliases.
I had already speculated in a previous post that perhaps that’s what you meant when you first used the term ‘group’. I also explained that it would require a significant change in Home Assistant’s architecture. Not the least would be revising the Lovelace UI to render entities with made up domain names.
Feel free to make your case as a Feature Request but given the amount of development work required to make this change, it’s a case of “the juice ain’t worth the squeeze”.
Well I wasnt really requesting a change, I was merely speculating whether having the ability to create a user defined “domain” would make it easier for people to model their workflows.
But I get your point that its too tough to do, so no need to discuss such heresy again.
Just jumping in to say that what you are terming a “switch” (i.e. a device with buttons that are pressed as part of an input workflow) HA thinks of differently. These devices generally don’t get modelled as entities in HA because they are stateless - you press the button, the command is sent, the button resets to its previous/neutral position. Most HA components/integrations model this as an “event” - something that an automation can listen for and react to, but not as an entity itself.
You’ve hit the nail on the head when trying to describe why for an “outlet” there aren’t two entities (i.e. outlet.leviton and switch.leviton) - it’s because that button on the device is (in 99% of physical devices) local-only - it provides a real-world, manual way of turning on the outlet. If, however, pressing that button sent a command over e.g. a Z-Wave network, HA could potentially catch and interpret it and model it as an event. So, for example, Z-Wave switch/dimmer physical devices that include the central scene command class fire events in HA when their buttons are pressed/double pressed/held, etc (and, an entity for the switch/light is created to control on/off/dim).
Interesting. I took a different approach at the core of my automation. I didn’t focus on “things”, I focused on the outcomes or requirements of what the automation is trying to achieve. Mostly this comes from starting with heating as my primary use case. If you think about it, an automatic construct (schedule whatever) wants to maintain a temperature in a room. When that temperature is no longer being maintained it simply raises a concern or demand for something to be done about it. Either heat it or cool it.
The thing that raises this demand doesn’t care or need to know how or why that is actioned. It doesn’t know about heating, boilers, radiator valves, switches, air conditioners, fans, pumps etc. It just says, “I want heating in the living room”. A separate bit of programming entirely looks at these demands/concerns and decides what “can” be done about it. It raises more demands, but much more specific. Like living room radiator demand, boiler demand.
This processor doesn’t need to know the particulars of how the boiler or radiator valves work or which protocol they are using, like Z-Wave or Danfross, it just states it’s demands.
The actual integration logic exists close to the devices themselves. They are fairly simple bits of code which watch for demands that they should serve and does so by switching, turning up, disabling things at the actual “switch”.
So in contrast to HA and OH and others, I don’t turn my heating on by looking for a switch integration and setting it’s state to ON. If I want to override the automatics, I raise a demand for the heating in the room/area I want and let the automation decide based on conditions and factors I probably don’t need to know, how it can deliver that demand.
It keeps the nomenclature and verb space focused on what is trying to be achieved and not “how” it is achieved or by what.
A lighting example might be that a schedule has determined that it’s after 6pm, the solar panel says it’s dark and motion was detected in the living room. A demand for living room lights can be raised. However the processor seeing that can also look to see what condition the living room is in. Are the curtains closed? Are the lights already switched on manually? Is the TV on? It might decide to do nothing or it might decide to set the mood lighting to “soft” and raise a demand for 50% dimming on the main light or wall lights, whatever.
For safety, demands expire. If whatever schedule raising the demand stops raising that demand, it will expire and the processor will stop raising specific demands to service it. The “things” at the very end of the chain will do whatever they feel appropriate when there is no demand for them and return to a “safe” state, most likely OFF.
The light switch in my living room, an RF 433Mhz battery power duffer, when pressed, bounces through a few protocols like MQTT and eventually raises a demand for living room lights. That demand is picked up by the lighting controller and switches the lights on.
I am mulling over how to model “demands” and “demand processors” in HA, or alternatively integrating HA into the demand system by providing an service to raise or query demands.
Oh, and schedules (the main automation) do not deal with “sensors” or “switches” or gadgets or gizmos. They simply look at the published data, where that data came from, they couldn’t care less.
You may not realize it but you just described the way HA (and I assume most automation systems) work at the fundamental level. It’s kind of funny actually. You described an “automation”.
You’re heating system “raising a demand” is caused by some sort of sensor that you needed to define in your control system for it to listen for the event from. That’s a trigger in HA.
Then it looks at more sensors or switches (that you have also defined in the controller) to see if the conditions are OK to cause the action. Those are called conditions in HA.
Then based on the above things then the controller decides to turn on/off some output device that again you have defined in the controller that it can act on. In HA those are called actions.
I think one of the key differences is that I work with states and poll them. HA is event based.
Academically this can be hand waved away as semantics, but it does have significant impacts on the rest of the design.
While “turning the heating on” is an event, for me that “event” happens right next to the heating switch and it’s about the only place the heating coming on is an event that has a state machine watching it. In a previous version I didn’t even have that state machine and just spammed the heating with “Turn ON”, “Turn ON”, “Turn ON”, “Turn ON”… every minute, but it created issues elsewhere.
The heating ‘needing to be on’ is a state that when polled will attempt to turn the heating on. If you turn the heating off, it will turn it back on again. If you turn the whole house off and on again my system will turn the heating back on again. If it’s missing an arm and half a leg it will shout, “A meer flesh wound!” and turn the heating on.
I actually had to disable this (using a state machine) for lights or it would turn them back on again when I turned them off.
EDIT: If you are asking the obvious question, “How DO you turn the heating off then?”, the answer is to raise a demand for it to be off for a period of time. The automatic demand raisers cannot override an existing demand… however manual intervention can.
Well if you look at javascript, which is an event based system, they use a subscribe/callback model for their events and no polling is involved. It’s quite efficient and I would be disappointed if HA is using resource intensive polling to generate their events.
