I too noticed that any scenes using a light’s brightness_pct no longer function.
what could possibly be the reason for deprecating brightness_pct, profile, and transition? Everybody understands these parameters and they are listed as supported by light entities still.
These parameters have been working beautifully in scenes like forever. It really is too bad some of these features would be taken away from scenes, which doesn’t feel like an improvement at all, as it now is advertised.
Secondly, its a bit of a guess which parameters are supported, and which will be taken out. Could it please be documented a bit more precise?
Or, and that would be best, would it be possible to revert the decision to deprecate?
Scenes takes as input entities as they are represented in the state machine. This has always been part of the docs:
You can see all attributes available for a particular entity under
developer-tools -> state.
The reason they were removed is because we did not realize this was supported/used to begin with.
Your screenshot is from the services page. Scenes input is based on what you see in the states dev tool.
Thanks Balloob, please let me ask: other than taking them out because you didn’t realize they were supported, couldn’t you (keep) support(ing) them officially and add them to the dev-state options?
Many users have grown accustomed to using these parameters, and it is used to great satisfaction… would be a major throwback if this is final tbh.
1 Like
answering myself here for reference and maybe other users:
It appears my long lived token was wiped during upgrade, and one of my rest sensors needs that to read the config:
- platform: rest
name: Hassio Rpi4 config
resource: !secret resource_hassio_rpi4_config
value_template: >
{{ value_json.version }}
json_attributes:
- components
- unit_system
- config_dir
- version
headers:
Content-Type: application/json
Authorization: !secret api_bearer_token
User-Agent: Home Assistant REST sensor
this would cause the system to try and try again during startup, causing immediate ipban of my home IP address.
Adding the token by re-creating it solved the issue immediately.
Still, it’s strange that with my trusted network settings, the error would cause the IP address to be banned, would this qualify as a bug?
The state dev tool is not an interface to control Home Assistant. Dev-state shows you how Home Assistant stores the data of the entities. And it’s that exact format that scenes expect as input. If you want all those extra things, why not use scripts? It seems weird to want to turn scenes into scripts if you can just call services in a script and achieve the same.
sure, more than 1 way to reach the same result. And as said, of course we can write scripts. Its just that a scene like:
- name: Early night
entities:
light.bedside_table:
state: on
transition: 4
brightness_pct: 10
rgb_color: [255,94,42]
has been doing its job perfectly for forever now, deprecating support for this feels so unnecessary. Im sure many of your users would appreciate it if support for this would remain, and made official. We’ve never known it wasn’t…
at least please consider keeping the transition?
look at it this way: it’s not a request for adding new features. It’s a request to keep things as they were, and support that officially.
2 Likes
ok thanks. Don’t think I fully grasp that yet, especially for my use case (don’t use cameras with an authentication), but I got the rest sensor to work again.
major points of interest now for the dev team after upgrading to 101.2:
- long lived token got wiped (is this per design after an update?)
- even with 192.168.1.1 as trusted network, frequent requests (which are not authenticated because of the mentioned wipe) during startup cause the address to be banned. That at least to me is unexpected.
thanks for chiming in!
Well you can always go back to version 0.50 and avoid all the other ‘unnecessary’ changes since then…
It’s just the nature of this - so many things have been changed and depreciated - this is just one more and it’s a one-time fix… Sure I get the grief about this. I was a beta tester but rarely use scenes - it wasnt till the weekend when a scene didn’t work. To make that worse, the docs were never updated so even though I DID note the change in the release notes, when I checked the docs there was no change and I didn’t worry about it. At the end of the day, I migrated my scenes to scripts and then I made the scene call the script - then it won’t screw up Google Assistant calling a scene - it’s a one-time change and it took an hour of screwing around.
I don’t see why this is such a big deal… arguing something as unnecessary because it’s always worked a certain way isn’t productive… just move on and adapt.
haha, sure.
but as you state yourself: you rarely use scenes. So changing might have been an hour of screwing around. And I can understand you don’t see why this is a big deal for you.
Of course we will adapt. If needed.
As a user who has more than a few scenes myself, the screwing around will take some more time I am afraid, changing many, many automations and other scripts calling the scenes…changing buttons using the scenes, well, I think you get the point from an other perspective than yours.
So please allow me to ask what Ive asked. seems fair enough.
2 Likes
It seems weird to want to turn scenes into scripts if you can just call services in a script and achieve the same.
Scenes were great due to the ease of specifying states rather than having to specify services. Now, with the reduction in ‘states’ we can specify that advantage is minimal to non existent. Why have scenes at all?
1 Like
With the scene editor it looks like you will be able to save the current state of device(s) to a scene and restore that later if you want to… Seems like a useful feature.
This release didn’t wipe authentication tokens. This is the first report I hear. We also didn’t change any code related to tokens. I think that you were able to bypass the validation of the token because of your trusted network setting, which did stop working.
It seems to be a very long winded way of doing things. If you have to set up entities in particular states to save them then you know what state you want them in. Why not just write that down rather than fiddling about with switches and what-not?
Each to their own I guess.
Scenes work by reproducing a given state. A transition is not part of a state. A light is on, it’s not a transition of 5. Transition is part of how a state should be achieved when the scene is activated. Hence, transition should be something that could be added as a parameter when activating the scene.
I don’t see why this is such a big deal… arguing something as unnecessary because it’s always worked a certain way isn’t productive… just move on and adapt.
Changes will always please some people and disappoint others.
There are other options here. The great thing about open source software such as HA is that someone can Fork the repo and make scenes work exactly the way they want. Custom components are also a great way of customising existing HA components if you don’t like the way they work.
Ok, thanks for explaining, I do get the logic… its just sometimes you like what you have, even though it might be against better knowledge. Let’s bite the bullet 
Let me please ask the community here how then to rewrite a scene call into a script with given simple example below. Where to put the transition in the script?:
current script:
lighting_slapen:
alias: Lighting Slapen
sequence:
- service: input_select.select_option
data:
entity_id: input_select.activity_lighting
option: Slapen
- service: scene.turn_on
entity_id: scene.slapen
and scene_slapen:
- name: Slapen
entities:
light.bedside_table:
state: off
transition: 20 #<---- where do I enter this, now transition is no longer supported in scenes?
group.kantoor_lights: off
Since I cant find that option in the scene.turn_on service,
can I simply change to:
- service: scene.turn_on
entity_id: scene.slapen
transition: 20
?
It did. Before the update my rest api sensor worked just fine, bearer token in the list and of course in my secrets file.
Since I got these ipbans, had to look what would be trying to authenticate on my 192.168.1.1, and deleting this rest sensor solved it. Then checked why that would be, I noticed the bearer token was gone from the list of long-lived acces tokens.
creating a new one immediately solved the issue.
I must also note that I wasn’t able to bypass the validation before, because when creating this sensor in the first place some HA versions ago, I wasn’t able to do so without a bearer token. It has always been needed for this particular rest sensor. Which seems to be according design, and is a good thing!
Not sure what you’re saying here I am afraid. Is my trusted network setting incorrect? Thought it be following the guidelines in the documentation:
auth_providers:
- type: homeassistant
- type: trusted_networks
trusted_networks:
- 127.0.0.1
- 192.168.1.0/24
Scene:
- name: Lounge Normal
entities:
script.loungenormal: on
Script
'loungenormal':
alias: Lounge Normal
sequence:
- data:
entity_id: light.lounge
transition: 2
brightness: 191 #brightness_pct: 75
color_temp: 322 #kelvin: 3100
service: light.turn_on