Restart / stop Home Assistant? Systemd


#1

Sorry if this has been covered before:

I have a working HA setup, running on a raspi using systemd. I am struggling with how to stop and then restart after changing the config.

Running sudo systemctl stop [email protected] takes about 15min to execute but then doesn’t seems to fully stop the application. ps aux | grep home-assistant still returns:

pi         763  0.0  1.8  22068 17704 ?        Ss   01:21   0:03 /usr/bin/python3 /usr/local/bin/hass --config /home/pi/data/home-assistant/
pi        1413  2.4  3.0 270124 29144 ?        Sl   01:21  11:56 /usr/bin/python3 /usr/local/bin/hass --config /home/pi/data/home-assistant/
pi       13438  0.5  1.8  22068 17656 ?        Ss   09:22   0:02 /usr/bin/python3 /usr/local/bin/hass --config /home/pi/data/home-assistant/
pi       13603  1.4  2.5 199624 24224 ?        Sl   09:22   0:06 /usr/bin/python3 /usr/local/bin/hass --config /home/pi/data/home-assistant/
pi       16267  0.0  0.2   4280  2008 pts/0    S+   09:30   0:00 grep --color=auto home-assistant

It’s no surprise then when I try and run manually to test a new config using hass --config /home/pi/data/home-assistant I get a HTTP port allready in use error.

The only way I’ve found to stop HA is to restart the machine which is far from a streamline workflow for testing config.


Thanks for your help, I’m loving playing with HA.

FYI Here is my setup so far, I’m running HA on my OpenEnergyMonitor emonPi Raspberry Pi energy monitor and interfacing with power readings and control via MQTT:


#2

I also wonder what is the proper way to restart the HA. This is what I did all the time…

sudo systemctl stop [email protected]
sudo systemctl start [email protected]

…and it happen almost instantaneous. Sometimes, like you said, it takes longer than usual to stop. When that happen, I just sudo reboot


#3

There must be a better way. This issue is really effecting my ability to further configure HA since everytime I change the config I need to restart. This is crazy! Sorry if I’m missing an easy method.


#4

You can restart HA by calling the homeassistant/restart service. Open the hamburger menu then click on the “remote” icon. Then you can select “homeassistant/restart” on the right hand side and press the “Call Service” button. :smile_cat:


#5

My usual way to restart any service is

sudo systemctl restart

Works for me.


#6

Bear in mind, that restart time depends on the components you load too. If you use Z-Wave for instance, it has to wait for openzwave to finish shutting down the driver, controller and write to disk. That can take a little while sometimes.


#7

Not the norm, but I run a screen named hass and just run hass from in there.


#8

i too am running into this issue where every time i need to restart HASS i hav to reboot my whole pi


#9

I also had this issue. I figured it out.
If you used the hass-daemon method to install then do:

  • sudo service hass-daemon restart

If you used the all-in-one script, then do:

  • sudo systemctl restart home-assistant.service

Adding here, just so that somebody requires this information in future.


#10

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.


#11

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.


#12

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!


#13

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.


#14

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!


#15

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.


#16

I made a script that autoupdates homeassistant when certain files are changed:


#17

sudo systemctl restart home-assistant.service is the one I needed. Thank you. :+1:


#18

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).


#19

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:
[email protected]:~ $ 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


#20

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.