I would like to be able to limit the actions when enabling Bridge HTTP API.
I would like to integrate Nuki to some smart home system, but I do not trust that much to enable unlocking. And as Lock-and-go feature by double clicking the button is hard to use for some type of people I would like to initiate the locking by the smart home system.
So I want to limit the Bridge api to do locking but not unlocking.
No Smart Home system should trigger lock or unlock actions on its own.
So, there are no ways to restrict acces to the HTTP API atm, but I would not recommend to use a system which you do not trust anyway.
Normally you add the smart lock and then set up scenarios you need. So you can restrict the usage to only lock in those scenarios.
If your usecase is to lock for people who can’t use Lock & Go, maybe auto-lock is a possible simpler solution?
I think you look at it from the wrong side.
There already exists Home Assistant plugin, which is able to unlock and open the door. I have to provide a API key to that system. So it means that:
- API key is stored on third system, that has internet connection (for other information services)
- API key is transferred in plaintext over the network (even local network, but who know who is listening)
I hope I can trust your Android application and Fobs where the communication is end-to-end encrypted. But I do not trust the scenario I have described above.
So the result is, that I would like to allow just locking the door through the Bridge API, but NOT unlocking.
Auto-lock is not solution for me, as I do not want to lock when somebody is inside and only the smart home system knows that.
Ah, I think I see what you mean. That is not possible with any of our APIs atm, where all lock actions are just options for the same endpoint/command.
I would ask you to set up a feature-request for it, so we can se if others also support this idea.