Why the heck is a restart needed for each an every change to configuration.yaml?

Ah seems my comment got missed in htere lol…its for mobile_app both android and iOS both require restarts anytime a device is logged in.

Dude thank you and all the core developers for doing all this :pray:

Yep this is by far the most common support issue with the mobile apps for iOS and Android that I’ve seen. People install the apps and then are wondering why they can’t send notifications etc, and it’s because they haven’t restarted.

Another thing it’d be useful for is managing notify groups, currently you have to restart for that.

Would be super helpful if a notify reload service could get added as part of this effort.

1 Like

I added notify to the end of the list that I’m working though. :crossed_fingers: that I can get to it before 0.115 beta.

Filter sensors are next:

3 Likes

One more to add:

  • google_assistant

Google Assistant has a request sync service already. Is there something else missing?

Statistics is up next

If I add more devices to the YAML to expose, I have to restart HA to refresh the available devices.

I noticed that if you include the domain like for example script you can create a new script, reload it and then sync your devices with google and it will pick up the new script without needing a restart.

right but I’m using the entity_config

snippet:

...
  expose_by_default: false
  secure_devices_pin: !secret google_device_pin
  entity_config:
...

and only exposing a select few devices/scripts.

It’s not that bad to restart for it, but it’s been on my wishlist :stuck_out_tongue:

1 Like

I don’t have a google home device, but I’m going to work on making homekit reloadable from yaml. Someone might be able to reuse some of that work for google assistant.

Generic IP Cameras are done here:

2 Likes

I’ve updated the list of what is being worked on here:

Generic Thermostat is next:

3 Likes

This is awesome! How do we actually leverage this though? This meaning the whole list of things you just made reloadable without restart.

What I mean by this is in order to have groups restartable from the UI, my understanding is you need to have your configuration.yaml say this:

group: !include groups.yaml

and you need to then have a file in /config called groups.yaml which contains all your groups.

So when you say you made one of these things reloadable without restart, what does that mean for configuration.yaml and file organization? Will it work no matter how I have my configuration organized or is there a specific file I have to use for each one of these? I have everything in packages right now so trying to gauge how much re-organization I’ll have to do to leverage this new capability.

Also I was looking for the doc PR link to explain this but I didn’t see one on the few I checked. If that’s in-progress and just not linked you can just shoot the link over and I’ll read through.

There were not any changes to the core group config reloading. The change for group is that the light and cover platforms are now included the reload.

The helper homeassistant.helpers.reload.async_reload_integration_platforms will take care of finding the config regardless of where it is configuration.yaml and reloading the configuration for each platform that the integration provides.

2 Likes

Oh wow really? I had no idea, that’s great! So I can organize my config the way I want and I’ll rarely have to restart anymore, this is fantastic. Thanks!

Reloading HomeKit via yaml is up if anyone wants to give it a try

Reloading the mobile_app.notify and group.notify isn’t as strait-forward as I had hoped. I don’t use the mobile app notifications so, it might help jump start this if you could point me to any issues that have been opened about what error is thrown if its attempted to be used without reloading.

Also, these are now in review:

Min Max

Trend

Ping

Filesize

2 Likes

That already works

So there is no error in particular, its just that the users notify.mobile_app_* service call does not get created until they restart Home Assistant. The only time a user would see an error was under a certain condition where they previously had the notify service and for some reason had to clear out the integration and start fresh. During that time if they did send out a notification the system will give out a generic entity not found error. Once they restart, the service call is created and the notifications get sent out again. I can’t really speak to any other specifics here honestly I would need to defer that to the main devs.

What I can tell you is that the service call gets created based on the provided device name. If a user decides to change that name later on they can do so in the app itself however they need to restart for the new name to take effect.

mobile_app now registers the services right away without the need to restart


rest.notify, group.notify, telegram.notify may be finished by 0.115, but at this point there are other cleanup that need to happen so its unlikely.

8 Likes

Small requst while you are busy:

  • reload python_script
  • reload mqtt configured in yaml

As @sparkydave says “That Works”
It has worked for about the last 14 months (for scripts and automations) so I’m not sure what you are talking about here.
I admit that the input_* helpers were added a lot more recently.
But as frenck says. the base is being moved towards allowing a lot more so restarts are required less and less

Edit: As @bdraco above proves in abundance !
:rofl: