So I was just reading through the release notes of 0.104 to discover that the switches were removed and traced back the deprecation to a much earlier version (0.93) and replacement with a service call.
What motivated this change?
I have been using this component for ages (and at one point contributed to it) and really liked the switch feature. I am actually toggling it from other automation systems in my home. I found the visual aspect of the switch very convenient. By moving it to a service, I now have to create an automation and a switch calling these services and change code in my other integrated systems for no gain that I can see. Alternatively, I can just stop upgrading at 0.103.6 and stay there forever.
I am just curious as to why one would want to remove a perfectly working feature and replace it with something which will bring more complexity to the user. Instead shouldn’t the camera component integrate a switch? I am really annoyed that so people would put so much work to add more work for other people and I am not seeing any benefit from it.
The previously implemented switches are now redundant with the new camera services and attributes. Also, when the switches were first added, although merged, there was a comment afterwards that indicated they should probably have not been added, but rather the functionality should have been part of the camera platform. (See comment by balloob at the end of PR #12992.) Therefore, for these reasons, the switches are being deprecated.
If a user would still like to use switches in the frontend they can add template switches that perform the same functions as the original switches by having them use the new camera services and attributes.
If the switches were to be kept then new switches would have had to been added for all the new services as well. For both of these reasons they were deprecated.
0.93.0, which included deprecation warnings, was released in May 2019, and 0.104.0 was released in January. That gave the community eight months of fair warning. (WAY more time than for many other breaking changes.) And there was also a community topic created back in May 2019 as well:
So this should hardly have been a surprise. There was plenty of time for comment. As far as I can recall, this is the first time anyone has complained.
As suggested in the PR, you can create Template Switches that wrap the services and attributes and behave just like (and directly take the place of) the previous switches. This should be a relatively contained change to your config.
I don’t track versions of HA that closely as I generally don’t upgrade unless something is needed. As a result I leap through multiple versions. I have not upgraded beyond 0.103.6 yet and was just reading the release notes. Sorry if I did not comment sooner. I really wish I had.
I understand I can use a switch template and know that it is redundant now.
But my question was… why do it at all? What benefit do we get out of it and why do the work and generate work for the users? This is not the first component on HA which does this type of things. I just don’t understand what is the motivation of changing for the sake of changing? The switch worked perfectly well and could be used in automations and called through API. What benefit does using the service bring? From what I can see it is complicating the API calls and getting me to add more stuff in my configuration along with going back to make a bunch of changes on my other platforms? Did I miss something? If redundant, I would have deprecated the service… and instead pushed code to add the switches to the camera components
Because the amcrest integration was inconsistent in this regard with other integrations and, as I understand it (and especially per balloob’s comment that I referenced previously), with the design philosophy of Home Assistant. Control of the camera should be done via camera related services, and status of the camera should be in the camera entity’s state (including its attributes.) Layering a switch on top of that, purely for UI purposes, was not how it was supposed to be done in the first place. The change corrected that. The benefit is to have the integration be more correct by the time HA gets to release 1.0. This is no different than with all the zillions of other breaking changes.
It wasn’t “just for the sake of changing.” As I’ve stated there were valid reasons.
Because like most breaking changes, they’re worth the minimal extra effort. And unlike most other breaking changes, there was a lot of time provided for users to make the changes at their leisure.
It appears you have. There is no difference, for example, between calling the camera.enable_motion_detect service with the camera’s entity ID vs calling the switch.turn_on service with a related switch’s entity ID. How does that complicate the API? In fact, it simplifies it because when you want to change something with the camera you always use the camera’s entity ID with an appropriate service, as opposed to doing that for some things but using the related switch and its services for other things. Isn’t consistency better?
And, yes, as we’ve already established, if you want to have a switch in the UI you do have to add that. But, again, once you’ve done that you shouldn’t have to change anything else in your configuration (if you use the same switch entity IDs as before.)
So, It appears also that I had quietly already redone my configuration.yaml to accommodate this breaking change last year and really should have brought this up back then. I just forgot that I did it.
I understand now that you were driven by @baloob to make the amcrest rely on the camera component which is fine. I only wish it would have meant bringing in the good parts of the other components into the camera component as opposed to try to fit a better written component into a lesser common denominator one. It’s just a bad design philosophy.
Thank you for your responses! Appreciate your work and insights.