Not really. Keep each entity’s name (the exact term is its object_id) fairly simple. You can use Groups and/or Areas to organize them. If you want to include custom meta-data to an entity, the common practice is to stuff into its name but I don’t recommend it. It’s neater to define custom attributes. They’ll appear along with the entity’s other attributes and they’re easy to search for when using templates.
1 Like
Thank You, didn’t know you could add custom attributes. So much to learn.
Read everything posted by @123 you’ll find a goldmine of Jinja2, templates, and Boolean logic reductions that should be in a best-of book for any advanced user.
+1 I use areas for rooms and outdoor spaces, and then use groups to gang entities together that cross areas or are subset of areas. At our house, I have several exterior landscaping lights that I want to turn off at different times (they all turn on at a few mins after sunset). They are all in the “outdoor” area, then I make groups of lights for the different times, and then I have automations that set them off by group. The only pain with HA is that you have to edit yaml to make a group - their is no UI support for editing groups as far as I can tell. This is one of the few big misses in HA.
Also, another difference with HS is that you can expose a group to Google Assistant, and then have voice control for that work in that room. So I can take a subset of the lights in a group (or all the lights), expose them to Assistant in the Nabu Casa configuration, and place them in a room defined in Google Home (I use the same names for rooms and areas in HA as I do in the Google Home app). Then when I am in the room and it has a google speaker or hub in it, I can say turn on the lights, or close the shades, and it all happens by voice. HS never hanlded all the assistant device types properly, so I don’t need the workarounds for using “open, close, lock, etc…:” I needed in HS. If HS doesn’t do a better job of integrating with Alexa and Google, they are doomed.
You don’t need to do any of this is if you just have a few lights etc… But for complicated setups, it really improves WAF.
Originally, everything was done by defining it in YAML … and then you had to restart Home Assistant for the change to take effect. That was a ‘culture shock’ for me coming from Premise where you can do anything (add/remove integrations or entities, change one thing in a script, etc) and never have to restart it. Even today, Home Assistant is still not at parity with Premise’s transparent reloading abilities (and possibly never will since they employ very different internal architectures).
Home Assistant is an open-source project largely built by volunteers and the paid employees of Nabu Casa (if you use Nabu Casa’s remote-access service, your subscription fee pays their salaries). All it takes is for someone, with requisite software development skills (in python), time, and interest, to create and submit the “make groups via UI” feature (submissions are posted to the appropriate GitHub repository).
FWIW, there’s a boatload of very useful enhancements in the Feature Requests section that have never been implemented. Why not? Because no developer has been sufficiently inspired to create them. In other words, no matter how good we think the feature may be, its merit doesn’t somehow bump up its priority (there is no pipeline or prioritization); it’s all up to the “kindness of strangers” and only if they’re sufficiently interested.
EDIT
I overlooked to mention that there’s an existing Feature Request that you may wish to vote for (unless you already have):
https://community.home-assistant.io/t/make-groups-in-gui/289945
Combined a bunch of automations into a blueprint and added some functionality for creating groups. Hopefully, it holds us over until a better group interface is added. Take a look!
Hello and this is my first post here. I’ve got over 150+ over on the HS forums 
I’m a fairly happy HS4 user and am one of the seemingly few that find it a significant improvement over HS3 although I don’t care at all about the mobile stuff, I use something called HSBuddy for a mobile dashboard and it works great.
Anyway, I’ve been playing with HA on a Pi4 and have a Nortek Z-wave/Zigbee interface on it and they both work for those integrations. I tried adding the Insteon setup (since I have a ton of those products) and it connected and pulled in all the devices, but then HS4 stopped talking to the Insteon hub so I had to disable it for now. And Mike, thanks for the post about the DSC Envision issues, I haven’t gotten there yet as I know the Envision module will only talk to one host at a time for some reason, so mine is still on HS4. I like triggering lights at night when opening DSC monitored doors.
My primary questions are, after reading through the hundreds of posts here trying to find answers to them, are:
- I use the HS counters and timers extensively. Not sure how easy it would be to emulate that stuff in HA - I use a lot of counters as flags so if there’s a way to create virtual devices (on/off or whatever) then that would probably work. But HS’s integration of counters and timers made events easy. I see there’s something called “hass-variables” but it’s unclear to me if those survive reboots. An example of a counter I use is “pool-setup” which is either a 1 or 0. Daily timed events occur that look for that counter value and run a pool filter for a period of time if it’s a “1”. Another is “holiday_lights” that trigger outdoor outlets for lights when I set them up and change the counter value. Again, a virtual device would suffice for these items. I know I can go and enable/disable automations, but flipping a counter value is really a simple “switch”.
-
In regards to timers, those are also useful to me and I’m not sure if there’s a way to do this in HA. The basic idea is that I create a timer, give it a name, and events can either “start”, “stop”, or “reset” and they remain in place (their time values) after a reboot, until they are changed again. The values can be referenced from events (i.e. is timer xxx greater than 5:00).
-
One feature that was promised in HS4 was the “if-then-else” integrations into events. This feature seems dead at this point based on what I’ve read about it. Wondering how that works in HA – in other words based on conditions can I run different actions? Currently in HS I have to create multiple events to do this; i.e. event 1 fires based on a trigger, then it runs event 2 with the caveat that the trigger conditions are met, etc.
I will say that I’m very happy HA is linux. I’ve been using HS on a Win10 box just so it’s native. I never liked the mono implementation of it. But I would have preferred my SH system to be on linux.
Well, thanks for everyone’s contributions and very informative posts in this thread. And I’m looking forward to seeing what the future holds in my smart home world – all while keeping the WAF as high as possible!
Side note - I work at Google and am very active in an internal group called “Home automation” or something like that, and just about everyone there uses HA so that’s another reason I’m willing to give things a go here!
Oh also – entities, states, services, blueprints… all new ideas to me!
My first challenge was trying to set a Philips Hue bulb to an RGB color. I thought it would be straightforward but it wasn’t initially. Turns out I have to use that “service” called “light.turn_on” instead of the device directly. I used some yaml code somewhere to make it work.
My mind was shocked when I went back just now to see what that code was called and the visual editor loaded instead of the yaml editor, and the action looks totally different than before, when it was just a device action. The action is now “Call Service” and it has all the light options, including RGB options in an easy to use visual editor. Very cool!
Welcome Dennis,
I would recommend reviewing the automation triggers and conditions in HASS and evaluating your current events against them. You may find that what drove you to choose counters and timer devices in HS can be done a different way. HASS supports variables in automations, loops, and some other things not supported in HS that allow for multiple HS events to be collapsed into one HASS automation.
It does appear that HASS is less robust around keeping states over a reboot than HS. Here is a thread on making timers survive a reboot Restore active/paused timers after a restart - Share your Projects! - Home Assistant Community (home-assistant.io) that may be useful.
I’m in the early stages of evaluating my HS event logic using the same logic. I’m compiling a comparison of HASS triggers and conditions to HS triggers and conditions and working on documenting automation patterns so I can apply them to my HS event conversions.
Slow and painful work, but I’d rather not have to redo things once I put them in HASS.
The State Trigger’s for option can be used in place of situations where a standalone timer is often employed.
The following will trigger when the door is opened and left open for at least 15 seconds.
trigger:
- platform: state
entity_id: binary_sensor.door
to: 'on'
for: '00:00:15'
If the door is closed prior to the 15 seconds, the trigger doesn’t fire (and the countdown is reset).
An important point to remember is that all automations are reset after a restart or just executing Reload Automations (which happens transparently whenever you use the Automation Editor and save a newly created or modified automation). What that means is any automation that is in-progress, perhaps iterating a repeat, or counting down a delay, or idling within a wait_template or wait_for_trigger, is instantly cancelled and reset. The same is true for a State Trigger’s foroption.
tl;dr
Pretty much anything that waits for a specified amount of time is reset by a restart/reload.
Active/paused timers are also reset after a restart (and Reload Timers). However, I created a method to mitigate it (link posted above).
To mitigate this ‘reset the world’ behavior, various design patterns have been devised. After a restart, you can’t make an automation pick up exactly where it left off but you can ensure it, at the very least, gets re-triggered again. You can see some of them described here:
Thanks, that helps those of us migrating from a different automation platform.
HomeSeer kept “entity states” across a restart, I’m curious do all HASS entities go through an “unknown” state after restart until the integration determines the current state? I’m guessing this would impact automations that triggering “from” a specific state. Generally in HomeSeer there was no “unknown” state except some Z-wave entities. If you shutdown a plugin (the loose equivalent of integrations) the state simple never changed again.
HomeSeer has a device state “save at shutdown” and “restore at startup” built into its core, assuming HS is shutdown gracefully. Other than effort, is there a technical reason this couldn’t be done in HA? I have a lot of events in HS that rely on the “state” of a device and I can’t easily move those to HA.
1 Like
Well, you don’t know what happened while the system was off, right? A light switch may have been turned off. It might have become dark. So assuming that states are as they were when the system powered down is risky. The safer behavior is to have the states unknown at startup until they report or are polled.
In a nutshell, the state value of most Helpers:
input_numberinput_booleaninput_selectinput_datetimeinput_textcounter
is saved/restored on shutdown/startup. Timer also falls into the Helpers category but is an exception to the rule. 
The state value of all other entities is derived from their respective integrations on startup or, in the case of entities based on the Template integration, computed on startup.
unavailable and unknown are valid states. Obviously they’re undesirable states but nevertheless useful for indicating when something goes awry. unavailable typically indicates an entity no longer exists whereas unknown indicates the entity’s value can’t be acquired.
For example, sometimes one of my WiFi-based switches drops off the network momentarily then reappears. When it drops off, its state value is unavailable. I can use that in an automation to report when it winks in and out of existence:
- alias: 'Monitor Switches'
id: monitor_switches
trigger:
- platform: state
entity_id:
- switch.whatever_1
- switch.whatever_2
to: 'unavailable'
- platform: state
entity_id:
- switch.whatever_1
- switch.whatever_2
from: 'unavailable'
action:
- service: persistent_notification.create
data:
title: 'WARNING {{now().timestamp()|timestamp_local()}}'
message: '{{ trigger.to_state.name }} changed from {{ trigger.from_state.state }} to {{trigger.to_state.state}}.'
The first State Trigger detects when either of the two switches changes state from anything to unavailable.
The second State Trigger detects when either of the two switches changes state from unavailable to anything else.
If I am made aware the problem exists and can detect a pattern of when it happens then maybe I can figure out why it happens (because normally the WiFi coverage is good). In one case, an exterior porch outlet, located a foot above the porch and with a fair connection (-56 dBm through a brick wall), frequently dropped off and reconnected in the summer despite a previously flawless record of operation during fall, winter and spring. The cause was determined to be the addition of various RF-blocking things on the porch (in summer) … like a full watering-can often placed next to the outlet (directly in its line-of-sight to the access point).
Thanks everyone for the great feedback and helpful information.
I realize that I still need to find a solution for what I am calling virtual switches/devices, something I can manually flip on a dashboard (card?) to control timed events, like should the pool filter run on a timed schedule. We don’t always have the pool set up, so I’d want to have a switch I flip off to disable those events. As I mentioned before, this is one example, and yes, one could argue that I could simply disable those events that run the pool filter. I guess I like the idea of a master switchboard to control certain events and whether they will occur.
So, is there such a thing as a virtual device where you can pick states/values? One of my HS4 events changes 3 virtual devices at midnight each day. The devices are called daily_color_hue, daily_color_sat, and daily_color_dim. I set them to values I’ve selected for each day for some lights in our family room. Each day they come on in the morning in a different color (preset by me). The event that turns on these lights simply sets those 3 values for each lamp to whatever the virtual device values are, if that makes sense. This gives me my changing colors depending on the day. As I think through it, I suppose creating “scenes” of all the pertinent lights for each day and having 7 of them that can only run on their specific day would also accomplish this. Someone else mentioned that moving to HA will probably require some rethinking of how I do things in HS4 and this is one example of that.
I’m not as concerned about timers surviving a restart; heck, HS4 used to crash for me quite frequently (usually it was related to some .net thing) and I had to sort out a reliable watchdog to kick things back in gear. The most recent complication was introducing DeConz and a Conbee zigbee stick into the mix. There was now a precedent for which items started when, and to ensure tcp ports weren’t conflicting (i.e. http 80).
But I have a totally different feeling about something linux based running on reliable hardware. Can I ask everyone’s opinion about how reliable HA is? Does anyone have to deal with things crashing? Are there systems in place to watchdog critical components and start/restart them as necessary? Just curious how robust the whole system is. Not how reliable z-wave is, or any integrations, just the core system itself. I’m going to make an assumption that it’s reliable and once it’s running it’ll keep doing it’s thing as long as the hardware is running. Please enlighten me if that’s not a valid assumption.
I’m still a little confused what an “entity” is but I’m still reading docs and I’m sure it’ll become clearer to me. I just added pushover notifications via an addition to the configuration.ini file. It’s also unclear to me why just adding some configuration data to that file can implement a new service. I don’t recall downloading anything for pushover (in HS it’s a plug-in that’s installed, like an integration). There’s also the useful service called “light” that is built in, so I guess pushover was just another thing built-in… if I am guessing correctly.
Anyway, as you all can tell things are new to me so pardon the slight stream of consciousness as I work through things.
Thanks again!
Dennis
See Configuration - Helpers for the virtual devices you want. They should fit your use cases very well.
Wow – yes the helpers are awesome! That’s exactly what I needed. It took me a little time to figure out how to manage the helper entities but I believe I got that sorted out. My thoughts were that a toggle was a device I could change, but it’s a service: input_boolean.turn_on thing not a device thing.
Saw a timer there; still looking into how to control it. Wonder if the helper states survive a reboot?
Things I’m still researching that I used on Homeseer:
- sending an email in an automation (this has to be really easy)
- calling a URL to run a script on an external server (in an automation)
- delayed automations, i.e. turn this light on and 30 minutes later turn it off
- setting a device’s value to the value of another device or helper
- automated backups (scp/rsync/ftp) to a nas or other external storage
Also things that would be interesting if they are supported:
- looking to see if there’s a way to have two different actions based on a condition (if-else)
- integration with a separate Raspberry Pi - controlling outputs and reading inputs. I used an HS4 plugin for this before and I’m sure there’s a way to do it with HA. The external Pi has a relay control board that I use for low-voltage circuits.
Thanks again for all the help and advice! I’ve got a good friend who’s trying to migrate HS3->HS4 and my neighbor who are both very interested in following my footsteps here.
1 Like
I switched over from HS to HA two years ago and haven’t looked back. Loved HS – great product – but love HA even more.
For me, I found the Automations complex. I implemented Node Red (as an add-on via the Supervisor), and do almost all of my automation logic there. This is definitely not intended to be a statement that Node Red is “better” than Automations. I truly believe it’s a matter of how your brain works… and for me NR is easier to grok. And it can do all of your points 1 - 4.
For automated backups, see the fantastic Home Assistant Google Drive Backup.
I started on a Pi4, and it was fine while I was learning and experimenting. But within a few months I repurposed an old Dell laptop, installed Proxmox (after a learning curve for that), and installed HA there following the scripts found on this forum. It’s much faster and (in my opinion) a much more stable environment to run the household. Of course, your mileage may vary .
2 Likes
Thanks, I’m playing and learning on the Pi4 for now but my end goal will be to install HA on my spare Intel NUC I was running the old HS3 on. I think that’ll be a better machine for it in the long run, although my second choice will be to run it on the small ITX PC I built for HS4 but I need to run things in parallel for a while during my migrations.
I’ve been learning a lot and have come across Node Red on several occasions, including in the HS4 world, and have a tab open for a YT video called Node-RED Basics with Home Assistant. I’ll start there and see how it “sinks in” for me
I’m really impressed so far with HA - two things I had recently talked to my friend about were 1) we wished there was something simple to just report low battery levels on anything battery powered, and 2) some vacation option that learned from previous behavior and imitates that. Well lo and behold! There are blueprints for both of them and they were super easy to implement!
The only thing I’ve had trouble with is trying to get more icons. I found a set of Hue icons that work for me but the .js isn’t working so the pop-up examples don’t work when selecting an icon. But I can type in the name, like hue:bloom and it works that way, so that’s OK with me. I tried installing something called fontawesome but couldn’t get it working at all. I think it might be related to the HACS setup I needed to do for the hue icons. If folks recommend I stay away from HACS I’ll listen to that advice.
I’m comfortable in a linux environment so have no issues diving into problems as they arise, so HACS is interesting to me (for the time being).
Dennis