It’s in user options
1 Like
I was only referring to the portion I quoted of yours, which is why it got quoted…
You’d probably like the object taxonomy used by Premise.
Premise Home Control is the home automation software I started using in 2008, 2 years after the product was discontinued (its development started in 1998). I still use in (together with Home Assistant).
In Premise, everything is object-oriented. You have classes for lights, outlets, relays, refrigerators, pumps, blinds, etc. Each of these classes inherits from simpler ones like power, dimmer, temperature, digital_output, etc.
So an outlet inherits from power whereas a light inherits from power and dimmer classes. There are many existing classes available to represent a vast array of common devices (sprinkler, fountain, glass-break sensor, etc etc). However, if there is no class to represent what you have in mind, you can (fairly) easily create your own (using a GUI). For example, I have a custom Door class that is composed of:
- contact sensor for the door
- contact sensor for the deadbolt
- relay for locking the deadbolt
- relay for unlocking the deadbolt
In other words, you can throw together existing ‘things’ to create a more complex ‘thing’. So instead of using the default door class, to model all monitored doors in my home, I use my custom door class. This is the essence of Premise; plenty of flexibility to define new things using existing ‘building blocks’.
The reason I gravitated to Home Assistant (aside from the obvious that Premise hasn’t changed in ~15 years) is because it’s the closest thing I’ve seen to Premise … and is being actively developed. Over time, I hope to see more of Premise’s ideas incorporated in Home Assistant.
1 Like
LOL… You can tune a piano but you can’t tuna fish!! (old Joe Walsh song)
Well after all this discussion about devices and entities and my new enlightened understanding I guess what would make sense to me is to take a physical device like this Jaysco smart plug https://www.amazon.com/gp/product/B07P889L8M/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 and create two entities for it:
Plug Entities:
switch.jaysco_xxxx
outlet.jaysco_xxxx
Then you use your switch for your input flow and the outlet for your output flow.
I think i get your quandry. For the Jaysco plug, there is a physical swich on it but for something like the leviton outlet https://www.amazon.com/Leviton-DZR15-1RZ-Controls-Resistant-Receptacle/dp/B01N6HT2YN/ref=sr_1_5?crid=3L6KFG8D2KRLP&keywords=zwave+outlet&qid=1569178212&s=hi&sprefix=zwave+%2Ctools%2C301&sr=1-5 its really meant to be a outlet to be controlled by a wall switch. So in this case I would only have 1 entity:
Leviton Outlet:
Outlet.Leviton_xxxx
Now in your workflow you use a separate wall “switch” to control your “outlet”
Makes perfect sense to me anyways
Yep. From how you’ve described it I think we both hope to see more of Premise’s ideas incorporated. From my perspective… there’s a guy… Rodney Mullen… most known for being a pro skater, but he did a couple TED talks… in one of them he explains skating as “…how we all learn basic things. And then complex things. We take simple movements and then chunk them together in such a way that we form more complex ones.”
Oh I see… I meant in the lovelace config file can you use the include file directive to split the file into smaller files
YES. That is why I specifically stated if you switch to Lovelace YAML mode, you can use includes.
Not quite. But helps illustrate something I was thinking of mentioning earlier…
The switch on the outlet isn’t…it’s not an independent interface? It’s more of a sub-function of the outlet itself.
function.device._?_._?_
switch.outlet.zwave._?_
edit: …no… that’s not right either… because really… the switch on the outlet is a local-override… it tells the on-board zwave ?client? to toggle the state which triggers a local process to then update the zwave network about that nodes state change… the specifics of where what gets triggered within the devices themselves is beyond my knowledge…
regardless… the switch on the outlet itself isn’t an independent device and would be a subclass of the device itself.
Works perfect thanks!
1 Like
Doah… sorry I misinterpreted your reply. Thanks!!
I couldn’t disagree more.
A switch is a switch and could be used in many scenarios, how is the system meant to differentiate ?
A switch is a switch, whether it controls a light, a coffee machine, a speaker or flag pole. It’s how you use it that counts and you also have the ability to control what it is labelled.
You can not proscribe the freedom to name things or preselect the path they must use. The fact that you call them ‘outlets’ is an example. We don’t call them outlets.
FWIW, there are some things that are unlikely to ever be seen in Home Assistant because they would require profound architectural changes (far too disruptive). For example, in Home Assistant you turn off a light by calling a service and specifying the light you wish to turn off.
action:
service: light.turn_off
entity_id: light.kitchen
In Premise you just set the light’s PowerState property to false.
Home.Kitchen.PowerState = false
That’s vastly different and unlikely to ever be seen in Home Assistant.
Here’s another idea that would be nice to have in Home Assistant but might be too challenging to implement. In Home Assistant, you use platform to specify the entity’s connection to the outside worked (i.e how it acts on the real-world device). In Premise, there’s a similar concept except you can change an entity’s platform without having to restart Premise (the alteration is accepted immediately). In fact, there’s no need to restart Premise for any changes at all. You can create/modify/delete entities and automations and the changes take effect immediately (that would be a big stretch goal for Home Assistant).
You can even define an entity without specifying a platform. As strange as this sounds, it actually serves a purpose. It allows you to experiment, with entities and automations, without having (or affecting) the actual physical device. All the entity state-changes are displayed in a Watch window where you can confirm your automation’s logic is correct before you actually let it control real-world devices.
1 Like
It’s about how its presented. I’m still trying to wrap my head around what I’m trying to explain.
If you don’t call them outlets, what do you call them? I think your disagreement is more about terminology than it is about concept and I think if we can clear some of that up you might disagree a little less.
Really… pretty much where my expectations lie in general? It was an example I threw out there and it spun off on a tangent that I’m tired of trying to restate the logic of.
Really wasn’t meant to create so much disagreement.
My point was simply to indicate that setting a property to false is vastly different than calling a service. The underlying architecture, in Premise and Home Assistant, are world’s apart so its unlikely Home Assistant could dispense with the calling of services in favor of directly setting an entity’s state.
Ultimately, both accomplish the same thing but go about it their own way. I prefer Premise’s way because I don’t need to recall the name of a service. If I want to set the thermostat’s CurrentSetPoint to 23 C then I just write:
Home.Thermostat.CurrentSetPoint.Celsius = 23
Done. No need to look up the name of the service to set the thermostat’s temperature. It’s this kind of ability that is unlikely to be adopted in Home Assistant due to significant architectural differences.
1 Like
After more thought maybe it should only be:
outlet.jaysco_xxxx
Where the physical switch controls the power to the outlet and your remote switch controls the power as well. The only way you get power is by flipping the manual switch at the outlet or via a remote switch though zwave
But a regular wall outlet has no switch, even a smart one. You need the wall switch to control it.
It makes no sense that you are flipping a wall switch to flip another switch
It’s all largely irrelevant - Home Assistant uses switch for anything that can be turned on and off. Discussions about outlet or whatever … are just theoretical chat 
yes… mental masturbation lol 
To paraphrase @petro if you are flipping a switch to operate another switch, then you clearly haven’t thought about a sufficiently efficient automation and secondly, you have no one to blame but yourself as you connected the two together in that manner.