Yes, you always have to restart. Or if you’re just using the default automations.yaml file, you can go to the config pages and reload automations. I guess this is the missing piece of the puzzle! lol 
EDIT: Configuration -> Server Control -> “RELOAD AUTOMATIONS” under Configuration reloading.
EDIT 2: My comments above assume you’re editing the file directly. If you’re changing the automation via the Automation Editor, then I think it’s automatically reloaded if you change and save the changes.
Sorry, does this mean anyone working on this forum (trying to help others) will need to buy, setup, run, populate (a new pi and HA) and ‘learn’ to use the new fangled automation manager, in order to continue to assist ?
I thought the ‘major’ breaking changes were supposed to come with 1.0.0 ???
Since I’ve done some development I keep a checkout (or whatever you call it in git) so it’s easy for me to use that to run a test system with the latest & greatest (which I run on a different port, so I can run it at the same time as my main production system.)
Major? What do you consider major? I think anything that breaks what I’ve been doing is major, and those changes come about every release and have been for the year or so I’ve been using HA. HA HA HA
Pun intended ! 
Not sure if I should applaud or request to have you shot ! 
Er no !
I use all packages and when I reload automations then all my automations are reloaded, same with scripts.
The only things I need to restart for are changes to sensors and new input_whatever etc.
Sorry, only really just processed this.
A few points
I recognized some of the new Device Automation lingo but was surprised to see true/false representing a binary_sensor’s states. That would be departure from the norm for Home Assistant.
FWIW, I wanted to experiment with the new Device Automation feature (on my test system) but everything I have is MQTT-based and there’s no support for that (yet). Can’t create a Device Automation when there are no Devices.
Refresh my memory; I don’t recall saying … whatever this is.
I run two instances of Home Assistant (production and test) … but it’s easy for me because every entity’s platform is MQTT.
I may be putting words in your mouth, if so I apologise.
(I’ve read so much of late I can’t recall specifics)
I thought there was a guy complaining about the HA software develoment numbering system
And a ‘respected’ poster here (so it can’t be you 
) pointed out that HA DID follow that numbering system.
Though Phil has poinetd out that HA is quite ‘egalitarian’ and will introduce breaking changes at whim ! (see Phil, I’m putting words in your mouth now ! )
Anyway it was just an incidental observation about how this seems 1) significant, 2) before 1.0.0 AND 3) how difficult this is going to be to support.
Feel free to correct as you guys may recall the specifics better than I
I just tested it by creating a template binary sensor, an automation to test things and two input booleans (one that turns on/off the binary sensor and one that gets turned on by the automation).
I used the automation editor (for the very first time - don’t really like it…) and I can confirm that for the template binary sensor to trigger the automation no states other than on or off (with no quotation marks) would work to trigger the action. I tried true and false (without quotation marks) and "true" and "false" (with quotation marks). As I said I even tried the on/off with quotes and it wouldn’t work either.
At least we have more info.
I have a vague recollection of a discussion about semantic versioning …but I don’t think I brought up the details of it. However, I do recall that balloob strives to limit breaking changes to major versions.
Thanks for confirming it.
FWIW, if there was effort to adopt true/false, in addition to on/off, it wouldn’t be a problem for me (the software I’ve used for many years uses true/false exclusively). However, I think there would have to be a very compelling reason to do that given that it is so late in Home Assistant’s development (> 6 years)!
Since I started this, I thought I should do another test the proper way.
I tried both pairs of states on/off and true/false in the trigger part of the automation, with quotes everytime. I edited automations.yaml through ssh with nano, and did a full reboot of the system after each edit.
I can confirm only on/off works, and true/false does not work.
Sorry about the confusion (but I have to say HA is rather confusing for a newbie, not only because the two sets of states pop up alternating in different areas of HA …)
Rather than use ssh and nano, if you enable samba then you will be able to access the file system, so it just becomes a network drive.
Then you can use your favourite editor.
A different ethernet (IP) port.
My test system is very basic and I only add entities I’m testing at the time. So, e.g., Z-Wave devices are only on my production system. I can use presence detection on both simultaneously (life360 & google_maps), but I don’t do that for long usually. Don’t want to upset the servers. 
I think that’s because the Automation Editor must put quotes on the values. Did you see what was in the actual YAML file when you did that? I can tell you that on and off without quotes would not work, because YAML would turn those into True and False.
Yeah, you are exactly right.
Here is what the automation editor created when I tried to put quotation marks onto on/off:
- id: '1569630771766'
alias: test binary sensor
trigger:
- entity_id: binary_sensor.test
from: '''off'''
platform: state
to: '''on'''
condition: []
action:
- data:
entity_id: input_boolean.bool_test_result
service: input_boolean.turn_on
so the editor is escaping the quotes with other quotes but it doesn’t look like it’s doing it correctly. So it fails.
And again the automation editor causes things to be more confusing for new users since every example of a working automation they will ever see on the forums will have quotes around the ‘on’ & ‘off’. So if they try to use that in the editor it will fail to work. 
I’m not sure i understand why the editor doesn’t give you a drop down of valid entries for at least the things that have explicitly defined possible states. Like on/off for switches & binary sensors or home/not_home for device trackers. I think it would help to eliminate some confusion.
Yeah, you might have guessed, we’re finding it confusing too
If you have it working can you please mark Phil’s post as having solved your issue ?
It helps keep things tudy and anyone serching that may be interested will see that there may be some light at the end of this particular tunnel.
Not exactly. It’s taking the value you enter, and then quotes it. If you enter 'on', it can be quoted this way: "'on'", or this way: '''on'''. Either is correct. The reason it doesn’t work is because the state does not have quotes in it. Apparently the Automation Editor wants you to enter the state, and then it quotes it to make sure it works.