I also had this issue. I figured it out.
If you used the hass-daemon method to install then do:
If you used the all-in-one script, then do:
Adding here, just so that somebody requires this information in future.
Using systemctl can sometimes take up to 5 minutes just to stop, not counting restart, so I make one minor change in a file and it takes up to 5 minutes to stop and up to another 5+ minutes to fully start up with all my zwave devices ready to go. So I’m waiting like anywhere from 5-10 minutes between one single configuration change.
I know it was stated that the way HA is designed, it would take a whole lot of reworking in order to be able to do live config changes and have them ready immediately, but come on… I have been working with HA now for about a month, I have almost everything the way I want, but I tinker all the time, and it has gotten to the point of unbelievable frustration.
I guess my question is, if it would take so long to redo the code for live reloads of config changes, then why was HA not designed for that from the beginning so that there wouldn’t be a need for such a massive rewrite. Why was the decision made to restart the whole service on every minor little config change. Its just crazy!!
Its like telling me to reboot my laptop every time I want to save a word document.
Is this a limitation with how python works or what exactly is the main reason that everything has to be reloaded? I can understand restarting when adding new devices, like sensors and switches, etc, or even adding new platforms to the configuration.yaml, but automations, scenes and scripts are the 3 things that most people are constantly updating and adding, so live reloading of those is more what I am after.
It’s possible to do a live reload of some of the config now, but I think that only extends to groups? I don’t remember what all it reloads.
I had similar issues with hass taking forever to stop, and it ended up being due to the sqlite database. It was pretty big, and I was using a slow sd card. I’d recommend enabling the purge_days option to trim the db a little bit, and/or get a faster sd/microsd card if yours is on the slower side. You can rename homeassistant.db to something else and start hass then stop it to see if the slowness is related to that or not.
If you have the choice, using mysql or postgres instead of sqlite should help too.
Yeah, I started with a fresh database a few days ago, so its currently only at 67mb, but I don’t remember the speed of the SD card I’m running on my RPI2, I’ll have to check into that and see if its a slower card or not.
I was thinking about changing over to a mysql db, but not sure if its more damaging to the card with read/writes than using sqlite. I like the idea of running my entire home automation on the compact size of the RPI2, so not liking the idea some had of offloading the db to a USB hard drive that is bigger than my raspberry pi lol
Ultimately, I just hope there is some major rewriting on HA to make it more feasible to do updates, because as of right now, I’m about done doing changes just because I can’t stand the constant restarting of the whole service. I used to be a SmartThings user, and I have tried every other option out there… domoticz, openhab, you name it, and nothing compares to the feature set and openness of HA, but not sure how many more times I can restart HA after the smallest change before I abandon it and try to hopefully find an alternative that doesn’t make me pull my hair out.
I’m sure for some people that are using mqtt sensors or hooking up to other hubs, the restart may be quick, but for those of us with z-wave devices, it averages about 6 minutes to fully boot up where I can actually start controlling my devices. Thats just unacceptable when the only thing you changed was a mistaken indentation on a single line of a single yaml file. Its just absolutely nuts.
Anyway, thanks for the tips!
You’re probably right about running mysql/postgres being more damaging to the card. I’m currently using postgres on my rpi3 just to see how well it works, but haven’t really monitored i/o usage or iops =\
I agree with hoping for a live-reload of the entire config. That’s one thing I do miss from openhab; it’d check for changes to the config every X seconds and reload automatically. I’ve at least gotten to the point of not needing to make changes everyday, but it’s definitely something that’s frustrating during the initial config.
I don’t have very many z-wave devices (less than 10), but I can usually stop and start hass in 10-15 seconds, and maybe another 30 seconds or so before everything’s fully working. Your 6 minutes seems like it’d be a lot higher than I’d expect. It’d probably be a pain, but I’d start commenting out different platforms in your config to see if you can determine what is making it slow.
A good feature request would be to monitor platform/component start-up time, and at least log a warning about the slow ones.
10-15 second shutdown and 30 seconds to fully working?!?!?!? Wow, when I only had a couple of zwave devices on the system while testing in the beginning, I was already at about 45 seconds to fully working, though I am running this on my RPI2 and not my RPI3, so that could account for it taking a bit longer at that time for mine to boot over yours.
I currently have 30 zwave devices, but that will be pushed up to closer to 50 in the not too distant future. If it would shutdown in under a minute and then boot up again in under a minute, I’d stop complaining. I just don’t know if it is the number of zwave devices I have or my platforms. I’ve gone through there many times and I don’t have a whole lot going on that I can imagine is slowing things down, then again, I may have quite a lot more automation going on than most people do. I have 35 scripts and 66 automations, not counting a plethora of input_booleans, input_selects, input_sliders, virtual sensors, MQTT sensors and shell_commands, so not sure how much those slow things down as it loads them all up at boot. Could be a combination of things.
Even with everything I have running on an RPI2, when its fully booted, I have no lag, delays or anything. All my devices and automations are instantaneous and fluid. The house runs like a well oiled machine, its just the boot time after a config change that is a real pain, but other than that, everything surprisingly runs buttery smooth!
This may not be a great solution but in the interim, have you considered setting up another HASS environment just for testing. That’s what I have done anyway. I installed HA on my Synology NAS and use it for testing components, automations, scripts etc. I only move it over when I’m confident they work. My startups/shutdows are in the order of seconds (No ZWAVE, all mqtt) but I’ve done so many that I even got sick of doing them. I can only just imagine what you must be going through.
P.S I only did this not long ago basically for the same reasons you’ve outlined.
I made a script that autoupdates homeassistant when certain files are changed:
sudo systemctl restart home-assistant.service is the one I needed. Thank you. 
Just weigh in, stop takes ages for me too.
So I tend to use kill instead of stop - quick (and probably dirty and a bad idea but it works for me).
The slow stop of homeassistant started happening to me. I’m new to home assistant, I only have 2 devices, a wemo switch and a zwave home power meter. The install of home assistant is less than a few days old. I noticed this started after I entered only three customization entries.
customize:
switch.wemo_mini:
friendly_name: Wemo Mini Switch for Printers
icon: mdi:flash
sensor.aeotec_dsb09104_home_energy_meter_power_5:
friendly_name: HEM Clamp 1 Watts
icon: mdi:flash
sensor.aeotec_dsb09104_home_energy_meter_power_3_8:
friendly_name: HEM Clamp 2 Watts
icon: mdi:flash
sensor.aeotec_dsb09104_home_energy_meter_power:
friendly_name: HEM Total Usage Watts
icon: mdi:flash
Home assistant log enntires:
pi@pi:~ $ cat /home/homeassistant/.homeassistant/home-assistant.log
2017-08-03 23:02:42 WARNING (Recorder) [homeassistant.components.recorder] Ended unfinished session (id=31 from 2017-08-04 02:46:28.632698)
2017-08-03 23:02:43 ERROR (Thread-8) [pywemo.ssdp] Found malformed XML at http://192.168.1.188:9080: status=ok
2017-08-03 23:03:11 WARNING (Thread-6) [netdisco.ssdp] Found malformed XML at http://192.168.1.188:9080: status=ok
2017-08-04 02:01:31 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
2017-08-04 03:18:15 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
2017-08-04 04:06:05 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
2017-08-04 04:58:42 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
2017-08-04 06:05:39 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
My DB size:
-rw-r–r-- 1 homeassistant homeassistant 963M Aug 4 06:55 home-assistant_v2.db
Since I noticed the size of my DB was almost 1GB after a days worth of sensor input, I started digging into that. Looking at other posts, it seems this may be the cause of the slowdown. The long time it takes to both stop home assistant and to view graph data for the sensors are all symptoms of the DB growing wildly. I’m not sure why it’s so huge since the only real sensor data is from the Energy monitor and that data (even if its sending it every second) should not take up gobs of space. I wonder if a lot of unnecessary information is being logged to the DB, instead of just the sensor info.
hi,
how to reboot over ssh when the webfrontend didnt respond anymore?
using the newest hassbian image
after half and hour the process didnt work anymore, it runs, but the webui diodnt respond
thanks
https://www.home-assistant.io/docs/installation/hassbian/common-tasks/
Stop, Start, Restart HASS:
sudo systemctl stop [email protected]
sudo systemctl start [email protected]
sudo systemctl restart [email protected]
In my experience you need to be diligent in seeing what actually gets recorded. I can some up with some cool ideas to create sensors but then fail to think about how data might be kept or anticipate duplicate info.
For example, I have a temp sensor in office which reports with 1 decimal but i prefer to keep it to whole number. So I made a template sensor with round.
Well, this means I should hide the original sensor from logbook and history since all I care about is the whole number custom sensor I made.
You may have entities which report back every few seconds and this fills your DB.
There are queries you can run against the HA database which will count the number of hits a given entity records. Use this to identify those which are filling up your db. They can be ignored from the recorder or history.
This is all annoying to be sure but I feel expected given nature of project.
It’s very confusing to me, to see at one time the homeassistant user being mentioned as the user to start it from, and the other time I see the ‘pi’ as user.
For example here (https://www.home-assistant.io/docs/autostart/systemd/) I read:
“with [your user] replaced by the user account that Home Assistant will run as (normally homeassistant).”
Yet I see tons of commands doing “sudo systemctl start home-assistant@pi” and concurrently I see tons of commands doing sudo systemctl start home-assistant@homeassistant
So I’m very confused :-P.
Specs:
So when do I need to use the pi user and when the homeassistant user?
I haven’t used a Pi in a while but it’s just your user / login account.
When Home Assistant was setup an account should have been created in order to run the software. In the old days it was hass but has since changed to homeassistant
This is the command I use to start home assistant
sudo systemctl start home-assistant@homeassistant
It depends on how you installed Home Assistant.
If you installed Hassbian, or followed the Raspberry Pi install guide you’ll be using homeassistant. If you followed the basic install guide then probably you’ll be using pi.
In your case, homeassistant
Yeah I found that out in the end. It technically did work with the pi user but it had no write access to it’s own configuration folders so I already was wondering why there was no known_devices.yaml and why I got tons of issues. But now it works fine :-). It’s somewhat confusing because you never do something with the homeassistant account in the commands, only for the actual start of the program you need it.
There are times you may want to run commands as the homeassistant user.
I have a bunch of shell commands in my setup (which is why I don’t run HASSIO). The commands run under the homeassistant user account and I will switch to the home assistant user…
sudo su -s /bin/bash homeassistant
and then run the command to confirm it works.
You also switch to the homeassistant user when you wish to upgrade
$ sudo su -s /bin/bash homeassistant # switch to homeassistant user
$ source /srv/homeassistant/bin/activate # activate the virtualenv
$ pip3 install --upgrade homeassistant #upgrade home assistant