Sometimes I write automations that temporarily change the state of certain entities, only to restore them after the automation has completed. At the moment, you have to use variables to save the current values of the entities at the start of your automation, then have numerous steps at the end of the automation to restore them all.
If a building block existed that let you specify all the entities that should be restored at the end, then I could simplify this automation by removing all the steps within the red border. It would also alleviate the confusion I ran into where certain actions don’t allow templates/variables to be used.
Hmm… that looks like it could work and is fewer steps overall but I can’t find any documentation on it, so I can’t be sure how well it would work until the time comes. I’d need 2 additional steps at the end: one to trigger the scene and another to cleanup/delete it.
I do think a building block would be better still: clearer, more intuitive and fewer steps.
Thanks, Google failed me there even typing in “home assistant scene integration”, the first two results are for the UI and then the next two pages are other docs or reddit/community discussions.
We’re talking 3 steps total for using a scene: Create, Apply, Delete. A building block would just be one configurable block. It could potentially use some kind of ephemeral scene in the background. I’m not arguing that scenes aren’t useful for this, just that they aren’t obvious to everyone, and they’re not optimal compared to a potential new building block.
Well, true… BUT, one could also accomplish a single block approach with a script too. Not discouraging what you want, just saying that we do have ways to do it now. Granted, they aren’t as user friendly as a building block.
The first step to use it is to do exactly what you described: specify all the entities that should be restored at the end.
It’s 2 steps to create what’s known as a ‘snapshot’ scene. First step is to create it (capture the current entity states) and the second step is to activate it (restore the entity states).
scene.create scene.turn_on
For an example, refer to the documentation.
How would your proposed building block be more obvious? Please provide an example of how it would appear in the Automation Editor that would make its purpose and usage self-evident to a user who doesn’t read documentation.
What I suggested doesn’t exist. Something else exists that can do the job in more steps, but it’s not the most obvious or user-friendly approach. There’s also a potential for conflicts in the case of carelessly choosing the unique id for the scene, or copying/pasting and forgetting to change the id.
It’s 2 steps to create what’s known as a ‘snapshot’ scene. First step is to create it (capture the current entity states) and the second step is to activate it (restore the entity states).
And a third to clean up, though I’ll admit that’s not strictly necessary. However, I would consider it a “best practice” to not leave unwanted scenes hanging around until the next reload, so I stand by 3 steps.
How would your proposed building block be more obvious? Please provide an example of how it would appear in the Automation Editor that would make its purpose and usage self-evident to a user who doesn’t read documentation.
Is it really necessary that I explain this part? It seems like you’re just being contrarian for the sake of it, as if you don’t know that every single current building block has a descriptive name and a full description of what it does beneath it. Just like I know that Wait for a template will “wait for a template to be evaluated to true to perform a sequence of actions”, I would know that Snapshot and restore would “Save the current state of one or more entities and restore them after performing a sequence of actions”. Or whatever more descriptive term you prefer.
I don’t really want to get bogged down arguing about why I think this would be a decent little feature, so I won’t reply to any more “it already exists even though it doesn’t” comments. If you think that scenes are good enough for this, then that’s great, but I disagree and I’d prefer to keep my feature request even if it’s not likely to be accepted.
However, you should be aware of the fact that the vast majority of Feature Requests are never implemented. The ones that can already be achieved using existing methods, or duplicate existing functionality, are less likely to attract the attention of a volunteer software developer or be accepted by the development team.
I guess the same can be said when you continually discount the long-standing method to use the Scene integration, despite not having even been aware of it until a few hours ago.
That description is exactly what can be done with a scene so anyone submitting a PR (Pull Request in Home Assistant’s GitHub Core repository) to duplicate the functionality of a scene would get pushback from the development team.
Perhaps the middle ground is to make it easier (and/or more obvious ) to use a scene in the Automation Editor.
That’s fine. I just thought you should be aware of viable alternatives while you wait for the FR to be fulfilled.
I’m well aware of the limited resources of open source dev teams. That doesn’t mean people shouldn’t request features they think could be useful. It only takes one contributor to take a liking to an idea, even moreso if it’s relatively straightforward to implement. Some people are only happy talking down requests they’re not interested in, though, when it’s easier to just shrug your shoulders and move on.
I guess the same can be said when you continually discount the long-standing method to use the Scene integration, despite not having even been aware of it until a few hours ago.
Not really, I evaluated the proposed alternative and pointed out why I didn’t think it was quite as good as my suggestion. You were just covering ground already covered in other comments.
That description is exactly what can be done with a scene so anyone submitting a PR (Pull Request in Home Assistant’s GitHub Core repository) to duplicate the functionality of a scene would get pushback from the development team.
It’s great that you feel like you can speak on behalf of the development team, but you’re (perhaps intentionally) misinterpreting what I’m saying, and I don’t really want to go over it again.
I guess you learned today how to find integration docs.
Indeed. Normally, you’d expect Google to be fairly reliable when you type in near exact search terms for the page URL itself, but it let me down on this occasion. Incidentally, I set up a site search for it on a keyboard shortcut instead.
The project is supported by Nabu Casa’s 30+ paid employees and numerous volunteers. For example, in the past month, 186 authors have made contributions to the Core repository. Resources are plentiful but they’re selective about what they choose to implement.
I don’t profess to speak on behalf of the development team. I’m sharing my observations based on over 5 years of active involvement with this community forum.
There’s some assumptions you’re making here that aren’t particularly correct, but your entire comment is irrelevant to individual feature requests anyway. Like I already said, it only takes one of those people to take a liking to this (or any other feature you deem unnecessary), or for this feature to gain enough votes for someone to take an interest. That person doesn’t even need to be a current contributor, but could be someone who happens across this request in the future and has the time and the skills to implement it.
All this meta discussion is moot and off-topic. In future, if you have nothing of importance to add, it’s probably best that you keep request threads clean for actual relevant discussion that has not already been covered. You can quite easily express your dislike of a feature request by not voting for it.
It’s been like that for many years. However I’m not surprised you think otherwise because the majority of your comments indicate unfamiliarity with the product’s features and the project’s and community’s operations. That’s fine, this place is for learning about all that, but it’s clear you don’t want to hear them from me. That’s fine too. Good luck with your FR.
Of course, those things go without saying. But the way you entered the discussion was unhelpful and a little rude and I think we can both agree it’s gotten out of hand now since none of the comments are about the actual feature I requested anymore.
I’m also well experienced with the project and most of its features, having used it for several years now in quite an extensive setup, but can admit to not knowing everything. I doubt there are many people who do know every feature inside and out, so maybe you can go looking for them and see if they enjoy your condescension and contrarianism. All the best to you for that, it seems to be important to you!
My first post reiterated there’s an existing method and clarified it requires the use of just two service calls (one for making the snapshot and the other for restoring it). The third step you had stated isn’t necessary (snapshot scenes are temporary; overwritten if the same name is used or lost after a restart). Afterwards I asked for an example of the proposed feature’s appearance in the UI.
Nothing rude, as you’ve now claimed, but your reply suggests you took umbrage with having your proposal questioned or challenged in any manner:
Anyway, if you feel I was condescending, or arguing for arguments sake, I want to assure you that was never my intention.
Nothing rude, as you’ve now claimed, but your reply suggests you took umbrage with having your proposal questioned or challenged in any manner
Nope, I was fine with the first two and even agreed that scene.create did the job better (in terms of number of steps) than what I already had. I took umbrage with the contrarian manner of your comment, which I’ve already mentioned several times.
I guess you’re not an engineer then. If you were, you’d you would know leaving things lying around until the next restart (days? weeks? months?) is generally considered bad practice. Another thing we tend to dislike is superfluous side-effects, in this case the side-effect of creating a scene in order to fulfill the behaviour of an automation.
I suppose that’s one way to characterize the lack of unquestioning agreement with your proposal.
scene.delete is a fairly recent addition to the Scene integration. It had a long gestation period but was merged in, I think, 2023.12.0.
Since the introduction of the Scene integration (many years ago) auto-purging (by restart) was deemed to be sufficient to manage leftover snapshot scenes. Recycling the same scene name was/is a common practice to keep it even tidier.
My impression is that the development team didn’t consider it to have impinged on resources or performance (no more than the ten traces produced by default for every automation). For example, bdraco, an employee of Nabu Casa and a prolific contributor to Core, has spent a great deal of his time in the past four years optimizing performance. Leftover snapshot entities don’t appear to have ever been on his radar.
It’s naive of you to think performance and resource management are the only concerns in software engineering. There are plenty of examples of bad practices and poor ergonomics, unrelated to performance, littered across the internet and development guide books. In this case here, for example, there’s the potential footgun of not making the scene ID properly unique and having collisions with other scripts. Even experienced people can make mistakes when copying and pasting. If you have any experience with, for example, JavaScript 10-15 years ago and global variables, you’d understand what I mean. Nowadays, we have new features that makes relying on global variables obsolete. As a direct analogy, you could think of entities as global variables; the fact that they are namespaced only reduces risk rather than eliminating it completely.
Simply put, any engineer worth their salt would tell you that it’s much better to have as few side-effects as possible in your code, and that same principle should apply to automations and scripts in Home Assistant.
Having played around with scenes a bit more, after I ran into an issue with one of my automations last night regarding device availability, I can see that there is another potential issue with scene.create: it doesn’t error if one or more of the entities are unavailable. I’d hope that a building block would fail if it were unable to save or restore the state of any of the entities, which would allow a fallback behaviour to be implemented (ie notification). I’m having to implement these checks manually now, which is even more work and bloat in the automation.
Strawman argument; I never said they were the only concerns. My point was that, historically, the development team hasn’t considered the lack of scene deletion to be the egregious engineering mistake you have described it to be.
I can’t say for sure but I suspect it follows similar rules to how an entity, whose state is unavailable or unknown, is handled by the Group integration.
It’s been my experience that this extra effort is needed in most automations and scripts, if the goal is to make them fault tolerant.
