Exact functionality of /lock & /unlock

Hi everbody, I’m new to nuki and this forum. I’m using a nuki Smartlock 2.0 together with the bridge in my Homeautomation environment. I did the integration (with python) using the Nuki Bridge API document V1.11. Everything works fine but there’s still some questions:
The Lock calibrated in my setup to 720 degrees but I’ve changed the lock state in the Nuki Android App to 360 degrees together with a night-mode setup 22:00-06:00; 720 degrees.
I’m sending lock and unlock commands via bridge with the following url’s:
‘lock’: $Nuki_url/lock?nukiId=$nuk_id_maindoor&deviceType=0&token=$NukiBridge_token
‘unlock’: $Nuki_url/unlock?nukiId=$nuk_id_maindoor&deviceType=0&token=$NukiBridge_token
But I’m not able to turn the lock to 720 degrees by sending two lock actions. Why not?
What do I do wrong or how does it work?
Help is really appreciated. Best W

The /lock and /unlock commands will always trigger the default setting on your device.

So if you want to enforce 720° in any case best use

/lockAction?action=2

Thx Stephan for fast reply. Just to be clear (because I tried also lockAction in the past):

  1. Pressing the button at the SmartLock, using the Fob, the Android App and the /lock command will always trigger a lock action with the default settings.
    whereas
  2. Sending an action=2 lockAction will turn the lock to the maximum angle.
    If this is the case, my last question will be:
    How many /lockAction?action=2 commands to I have to send to look a Smartlock with default settings 360 degrees (and calibrated endposition of 720 degrees) completely? One or two?
    Best W

@Womi My bad, I mixed something up with our Web API (which has a paramater for “force full lock”).
In fact with the Bridge API you have to send the command twice to lock to 720° as you correctly assumed.
Also there is no difference if you use /lock or /lockAction&action=2 for this behaviour.

Here my observations:

  1. First /lock or /lockAction&action=2 moves the lock to 360°. Second /lock or /lockAction&action=2 moves the lock to 720°.
  2. /unlock or /lockAction&action=1 move ALWAYS to 0°, i.e. unlocks completely.
    So this is the expected behaviour.
    Whta’s a bit strange are the different lock states while the motor is moving:
  3. Night mode: 360° → 720°: I see two transitions: locked->locking & locking->locked (which makes a lot of sense.
  4. Subsequent /lock command to a Smartlock which is at 360°: NO lock state change! Is locked and stays locked. Why?
    This is not a critical issue but a somehow unconsistent behaviour. I think it would be much better and easier to interpret if you would introduce lock states related to the real position of the motor, e.g. lock_360, or lock_720, etc. I could check then easily in which state the lock really is.