Do we want to do this without any time of deprecation is does change the entity id from lock.*_permanent_cable_lock to switch.*_permanent_cable_lock.

Don't get me wrong, I'm not opposed to the idea, but do we want to break this? -- That being said, v0.8 is littered with behavioral changes, so now is maybe the time to do it? What do you think?

Well, #204 is listed both as a bug and as a part of the 0.8-milestone, so seemed like a good idea to just get it out of the way.

I have my charger in a locked garage, so I locked my cable once and haven't touched it since. Maybe other people use it more often, but it doesn't strike me as something you heavily integrate into a custom automation. And as you say, we have already removed a device and other significant changes for 0.8, so might as well keep going in my opinion.

That being said, I should probably add a point on it in the readme and the changelog.

I agree and support the PR.

You don't need it in HA if you set it once. Then the app or portal website is just as good. I know of one use case where this it automated in HA: The cable is unlocked when the user is present, but unlocked when away. We did get the request to this project to add it. I don't remember who it was thou.

script/lint didn't seem to catch those line endings, but vscode has been autofixing those too, so fixed those for en, nl and sv (pl was apparently fine).

Maybe I'm too late, but I use the charger several times a week, as it's not in the garage and therefore accessible to anyone.
I find it helpful that when the car isn't connected to the charger, the charging cable can be locked to the charger so that intruders can't steal it.
I use HA to lock and unlock the cable.

@c0mplex1 you're not too late - its not out the door yet. If you only use the HA GUI to lock/unlock, you'll get the same functionality. It's the underlying name that changes since we changed from "lock" type to "switch" type. Functionally they are the same.