Your entity ids should not have capital letters in them.
1 Like
Thank you for that tip. This did solve it for me.
I had 1 scene file which I changed ONLY the uppercase letter to lowercase as below.
FROM
name: All OFF
entities:
group.Livingroom:
state: off
group.Kitchen:
state: off
TO:
name: All OFF
entities:
group.livingroom:
state: off
group.kitchen:
state: off
After this 0.101.2 installed and upgraded successfully.
Thank you, it worked for me too!
I had to change my input_select part too, from option: to state:
After that the upgrade went fine.
Hi, what is this?
IS the below input_select wrong?
marantz_video_select:
name: 'Source:'
options:
- Firestick
- Chromecast
- Games
- Internet Radio
- TUNER
initial: Firestick
icon: mdi:speaker-wireless
No, it’s fine.
I use input_select in a scene, I had to change there like this:
scene:
- name: Livingroom normal
entities:
light.Teglafal:
state: on
#transition: 3
rgb_color: [255, 227, 213]
brightness: 255
input_select.light_scene:
state: Minimal
still puzzled by the now called ‘improved scene support’, which truly feels like the opposite. Why are all these nice features deprecated now? Transition, profile, brightness_pct… No reason or outlook for the better is presented unfortunately.
checking https://github.com/home-assistant/home-assistant/pull/27182 mentions workarounds, but they are not to be found. Especially the transition, which is deeply missed.
Sure we can write scripts, by the ease of scenes was to not having to write scripts…
3 Likes
Light scene support will temporarily support the turn_on service attributes with the release of 0.101.3 but will print deprecation warnings. This should make the transition smoother. These attributes will be removed in the future.
If you were using a scene as you would have used a script, you should use a script. The ease of scenes is that you take any current existing state and can reproduce it at a later point. This will be made even easier with the new scene editor.
How is using kelvin: (a much more easy to understand unit than mireds) using a scene “as I would a script”?
2 Likes
I feel the same way, how is this not a breaking change, my scenes are now… broken.
1 Like
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