Has anyone, who is using VirtualBox, been able to use the “Share Folders” (See pic below) to mount a host folder to HA’s Media folder?
I don’t think VirtualBox shared folders works with hassos. You need VirtualBox Guest Extensions installed on the guest os for shared folders to work and I don’t think that’s possible with hassos.
I am a 10 yr homeseer user that converted to HA early this year. I run in HA in a guest VM, and put the zigbee and zwave sticks in a raspberry pi. This has the advantage of allowing you to put the radios in the best location from a device connectivity POV instead of wherever the server is running. Also, it allows you to move the sticks closer to things like locks that want the stick to be nearby to pair. It’s really not that hard to setup, and I find zwavejstomqtt to have very good device support.
What I really miss from HS is good diagnostic data for or Zwave., The topology map in zwavejs2mqtt is totally wrong. It’s worse than useless because it makes you think things are routing a certwain way when they aren’t. If you ignore it, it works reasonably well, and I am using a HS 700 series stick with it and it’s working fine, though I have to say my deconz zigbee network (carried over from the wim’s zigbee plugin) works faster and is rock solid.
Entity search is great, and once you make more specialized dashboards, it’s a lot more convenient to use than HS, which really had only one way of viewing things. I have one dashboard for HVAC, another for the Pool, one for lighting, and another for music, etc… It’s fast and works well. Don’t limit yourself to trying to make one master view do everything - I had the same issue being a HS user for 10 years. You’ll be happy to went with the new model, esp for use with the mobile app which works really well, esp if you use the nabu casa frontend that gives great google and alexa integration…
HS was working pretty much OK for me, but when they broke google home integration, and the customer service folks were useless because I was running it on windows server virtualized as “not a supported platform”, that was the last straw.
1 Like
Great advice.
My initial impression appears to indicate a strong naming convention it’s really important in home assistant??
Would you guys be so kind to share your convention’s?
I’m not sure if naming conventions are really important. I think the important thing is to abandon the assumptions and notational concepts of the old system or at least try to compare them to the new to see if they should be abandoned.
Remember, there’s a difference between “familiar” and “better”. It can be frustrating to approach a new automation platform when you are casting about for familiarity. Keep an open mind until you get your bearings.
One thing I would advise is embrace the documentation of Home Assistant. HomeSeer users are used to the forums as a poor substitute for documentation, don’t assume the same is true for Home Assistant. I’ve found the documentation to be generally excellent, especially for users who have automation software experience.
For example, HomeSeer had fixed requirements for Location1, Location2 (originally Floor/Room). You could not avoid using that construct. Home Assistant has no such requirement, so it feels a little unnatural. The search filters in Home Assistant are fee text, so you don’t have to worry about filtering or sorting by Floor/Room.
Devices in HomeSeer are not devices in Home Assistant. Device, Entity, and Attributes all make up what HomeSeer would call a device.
Virtual devices in HomeSeer can be a number of things in Home Assistant, the most relatable being Input Variables.
Automations and Scripts relate to Events in HomeSeer. Home Assistant appears to me to be more conducive to reusing automation and script code for multiple devices, where HomeSeer events are not. You can duplicate code in Automations similar to Events in HomeSeer, and the UI Automation editor is capable for that.
HomeSeer Plugins are the same as Home Assistant Integrations. As I write this there are 1858 integrations.
I’ve been playing around with Home Assistant for maybe 3-4 months and I still consider myself a newbie. So much to learn. But with 20+ years of HomeSeer experience, I’m confident I’ll get there.
1 Like
Pure gold, thank you!
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).