No, as a Smart Lock 3.0 Pro connected to a Bridge (as it has no internal Bridge API!) is the same to the Bridge as a Smart Lock 3.0 (the deviceType separation to SL 1.0/2.0 is also only needed for unique ID reasons on the Bridge).
Also small correctio to above:
To get the deviceTypes best use /list (as this is taking the data from the devices itself and not from cache as /info, but note that this drains battery so should only be just to retrieve data initially if not updated in /info yet).
No, as a Smart Lock 3.0 Pro connected to a Bridge (as it has no internal Bridge API!) is the same to the Bridge as a Smart Lock 3.0
Makes sense, thanks.
the deviceType separation to SL 1.0/2.0 is also only needed for unique ID reasons on the Bridge
Not sure I understand this correctly. Are you implying that a SmartLock 3.0 or 3.0 Pro might have the same nukiId as a SmartLock 1.0 or 2.0? Or does the bridge guarantee a unique nukiId, using the deviceType to generate this?
To get the deviceTypes best use /list (as this is taking the data from the devices itself and not from cache as /info, but note that this drains battery so should only be just to retrieve data initially if not updated in /info yet.
Huh? I thought /list returns the cached state from the bridge. I my experience it returns immediately, and wouldn’t even have the time to query the devices over BLE. I thought only /lockState forces querying the device, but that needs the deviceType as parameter, so using that to find out the deviceType would result in a catch-22 scenario.
There should never be the same id for 2 devices, but we introduced the deviceType option with the Opener to make sure that not the Bridge has to check which deviceType a called ID has but that it’s in the call (while at the same time have a good fallback for =0 for prior devices, i.e. Smart Lock 1.0/2.0).
So this is mainly done to be safe in the future whatever new devices and changes to ID handling might come.
My bad again! - Sorry seems I should not quickly answer things today 
You are correct about caching.
In testing at my setup I just saw that it seems to be mor reliable to get the correct deviceType in /list than /info
Clear, thanks.
Sorry seems I should not quickly answer things today
It’s almost weekend, I hope you’ll be able to catch your breath.
Hi,
Smart lock 3.0 pro will work with opner without the bridge?
Regards.
No you still need the bridge for that
Hi, vote to request this feature here:
Voted and answered there.
Hey guys,
I found ab Bug in the Bridge API with the Smartlock 3.0. Die Endpoint /info respons with a incorrect JSON String.
/list
[{“deviceType”: 4, “nukiId”: 738149620, “name”: “Wohnungstuer”, “firmwareVersion”: “3.0.40”, “lastKnownState”: {“mode”: 2, “state”: 3, “stateName”: “unlocked”, “batteryCritical”: false, “batteryCharging”: false, “batteryChargeState”: 100, “timestamp”: “2021-12-05T10:21:18+00:00”}}]
versus
/info
{“bridgeType”: 1, “ids”: {“hardwareId”: XXXXXX, “serverId”: XXXXXX}, “versions”: {“firmwareVersion”: “2.10.4”, “wifiFirmwareVersion”: “2.2.0”}, “uptime”: 224345, “currentTime”: “2021-12-05T10:24:44+00:00”, “wlanConnected”: true, “serverConnected”: true, “scanResults”: [{“deviceType”: 0, “nukiId”: 738149620, “name”: “Nuki_XBXX44XX”, “rssi”: -44, “paired”: false}]}
name and deviceType are incorrect in the /info response string
Best regards
Leon
@MatthiasK Hello, I need to know if there is a way to understand which IP address is assigned to the new smartlock 3.0 pro. Thx
Open the Nuki App and go to Smart Lock Settings > Manage Smart Lock > Built-in WI-FI > tap 7x on “Network” headline.
Hey Stephan,
How does it look like? Do you have looked at it?
Sorry for the late reply:
This was fixed with the last Bridge FW update 2 days ago (see Nuki Bridge Firmware Release notes (public releases))
You should already have received the update.
Hadn’t seen that yet, thanks.
What does “Enhanced the HTTP API to get rid of the device type, which streamlines the handling of Smart Locks” mean? Can I leave out the deviceType parameter to /list or /lockAction endpoints? The HTTP API documentation doesn’t seem to be updated to reflect this?
Yes, in fact you can just leave it out. Only for the rare case that you really should have to devices with same IDs and different deviceTypes (which should nearly impossible)
Just added the release notes and am currently updating the documentation (which will be live later today - at least the HTML version for now).
Thanks, Stephan.
Is the new firmware version indeed 2.12.0 or is that a typo? My bridge reports 2.11.0, which is missing from the release notes, and it won’t update to/doesn’t find 2.12.0.
Thanks for the note, it is indeed 2.11.0! 
Hi Stephan, I use the Bridge API to control SL 3.0 in my Fibaro Homecenter. All action commands are working, despite of action code 3 = unlatch. Any idea?
Thanks in advance Christian
Can you execute “Unlatch” (Tür öffnen) inside the Nuki App without problems?
Does it work when you execute the command from the command line (or curl) and not Fibaro?
What does the /log output of the bridge API return after executing the command?