0.46 update

Configuration
1

Totally confused with the upcoming changes and especially the amount of “breaking changes” in 0.46 release.

For example - https://github.com/home-assistant/home-assistant/pull/7846
Now it is ‘before’ and ‘after’ making sense. New logic - just “at” and “before”. Looking at github - two people participated and decided “the logic was too confusing”

Or “Cleanup telegram / Add url to webhook (@pvizeli - #7824) (telegram_bot.polling docs) (telegram_bot.webhooks docs) (telegram_bot.init docs) (breaking change)”
Have telegram set up. Breaking change… What shall i do than?

Plus really don’t understand why i’m loosing the ability to set lights of RGB and XY in a group to different colors - https://github.com/home-assistant/home-assistant/pull/7765
Never used it before, but why is there?

Most interesting commit - but will there be examples like “you had this before” and now after in the docs https://github.com/home-assistant/home-assistant/pull/7657

Don’t want to sound like a grumpy cat so the proposition

Breaking changes should be put up on community.home-assistant.io before being commited

Simple instructions for “dummies” on breaking changes

1 Like
2

I also find the first commit particularly disturbing as it might break the config of a big part of the community.
I left a comment on the merge request, we’ll see if allowing both keyword is a solution.

Edit: Actually it’s not a problem, the change is right and won’t break any config, it’s backward compatible.

3

Re: Telegram - several people in the dev gitter chatroom are having problems even after making changes suggested by the dev that did the telegram work.

Yay. I win “most interesting commit” This is a completely new platform. You can’t have had this before :slight_smile: Do you have any specific questions?

Re: breaking changes on the community
Do you have suggestions here? PRs that change functionality or configuration are required to have docs submitted to the home-assistant.io site. Those can’t be published before the code is released or the documentation won’t match the current feature set. You can peruse the stuff on the home-assistant.github.io github repo

4

HA is still a young project and moving quickly. Things will get broken to move the platform forward. Building in a lot of backward compatibility would slow the project down and clutter code; and not allowing radical changes would prevent new features from coming quickly.

I for one would rather have developers moving the platform forward; versus worrying about breaking the past. That comes once they hit 1.0 :wink:

At the end of the day you don’t need to upgrade unless you want a new feature; and if you want a new feature dealing with the breaking changes is a small price to pay. It’s your decision.

They don’t call it bleeding edge without a reason :wink:

5 Likes
5

After being renamed to at???

That doesn’t make any sense at all …

If I write a clause that says:

At: 15:00:00
Before: 20:00:00

I would expect this to fail any time but once - as it means at 15:00:00 and not at 15:00:01-20:00:00 - that’s completely wrong …whereas after I don’t expect to trigger at 15:00:00 but a x-second after the specified time …

1 Like
6

For me it is that the documentation following the releases and PRs is a bit confusing and lacking.
For example

and discussion here

This changes from/to filters on automation triggers to only consider actual state changes, not attribute updates. The change only makes a difference if just one of from/to is specified.

It is understandable that attribute changes are also affecting the trigger and PR solves it. But than all of a sudden…

Using state as an alias of to is deprecated because it is ambiguous.

Does that mean it’ll break all my triggers like below and i need to change all the “state:” to “to:”?
If yes - why not just write this in bold - “Users - see example rule below - and if you have something like that change to this immediatly after upgrade”
Same goes for “after”

- alias: 'Trigger alarm armed away'
  trigger:
    - platform: state
      entity_id: group.motion_sensors
      state: "on"
    - platform: state
      entity_id: binary_sensor.door_window_sensor_158d000112a960
      state: "on"
2 Likes
7

As explained in the (now published) release notes, after will still work, it’ll just generate a warning at this point.

They don’t explain it in the release notes, but checking the commit it looks like the same is the case of state in triggers.

8

Well, making the change from ‘after’ to ‘at’ breaks things… so I think this definitely needs some better documentation.

2017-06-04 13:11:16 ERROR (MainThread) [homeassistant.config] Invalid config for [automation]: extra keys not allowed @ data[‘condition’][1][‘at’]. Got None
not a valid value for dictionary value @ data[‘condition’][1][‘condition’]. Got None
required key not provided @ data[‘condition’][1][‘entity_id’]. Got None. (See /home/homeassistant/.homeassistant/configuration.yaml, line 72). Please check the docs at https://home-assistant.io/components/automation/

9

Maybe ‘at’ it’s just for trigger, and not for conditions

11

It makes sense to change “After” to “At” because I was using a time trigger for a few notifications and if I wanted something to happen at a specific time, I was doing “After: 12:00:00” so it makes more sense to say “At: 12:00:00” in my opinion.

In terms of the state: breaking change, it also makes sense to say when “platform:state […something changes…] to: xyz” I thought this would help from automations being ran when Home Assistant starts as it implies that the trigger will only trigger if the state changes to the value. But alas, that did not work for me, but perhaps when they finally deprecate the “state” key, it might.

12

As @danichispa said, and as the release notes say, it’s only for triggers, not templates:

The after keyword for time triggers (not conditions) has been deprecated in favor of the at keyword.