Support for new Smart Lock 3.0 / 3.0 Pro

[Stephan (Stephan Lendl)]

@ebaauw

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?

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.

@ebaauw

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.

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