Garmin CIQ Widget to Open / lock door

Product name

For which NUKI product do you want to submint a feature request?
Nuki Smart Lock 2.0

Summary

Quick summary what this request is about.
Implement a Garmin CIQ Widget that allows to lock and open the door with a Garmin Forerunner 645 Music Watch (and other CIQ compatible watches) using Bluetooth.
The Widget should work independent from a connected phone, i.e. Direct communication between Watch and lock via BT.

Features

Detailed description of desired Functionality

  • Ideally same functionality as the iOS Widget, but minimum requirement is to open and lock the door
  • Secure Communication between Garmin Device and Lock

Reason

Why is this feature needed?
When I am out for a run I usually do not take my mobile phone with me, but still have to take the key with me to be able to open the door when I return. It would be cool, if I could also leave the key home and Open the door with my running watch.

Examples

How would you like to use this feature?
List all usecases you can think of!

  • open door with Garmin watch when I return from a run so I can leave key and mobile phone at home.
  • Open door with Garmin watch anytime it would be faster to use the watch than grabbing the phone. (I am not using geofencing).

I moved this to the feature request section for you (seemed you’ve been prohibited from the system to create it there due to being a too recently created user).

Also see

for possible support for your request.

5 Likes

Any progress on this one? I would also be willing to support this request from a financial perspective. In case it’s of any help: Garmin also supports NFC (as it already features mobile payment) so that might be easier to implement in an app?!

3 Likes

Maybe this can serve as a starting point?

Garmin Watch talks to a Raspberry Pi using BLE. When you watch the Video think of the LED being a Nuki Locking and Opening…

2 Likes

Hi,

I am a developer and I’d like to get my hands dirty on this.
See my reply in the other thread for details:

If anybody wants to sponsor me a development and testing environment, give me a shout.

Thanks,
Jörg

1 Like

Can we expect this feature request to be „planend“ soon?

2 Likes

Bump. Does anyone know if there was any progress on this?

No visible progress from a User perspective. The App is still beta and it still requires a connection to a smartphone with Nuki App running. Maybe the Nuki team can provide an update?

It looked like @Joerg had intended to do some work on it - I wondered if anyone knew how far he’d gotten.

It’s not beta anymore and was just updated to support the lastest models from Garmin. But you still need a Smartphone in BLE reach of the watch.

We do not comment about our roadmap here in the forum. When there is something new, we will post it here or on our blog.

According to the App description in the Connect IQ App Store it is Beta. It it is not Beta any longer, then please update the Description. Anyways, in my experience it does not work reliably, so I stopped (actually never really started) using it. Will have another look only, if it supports a direct connection between watch and lock. There is no value add for me using the App as it is.

1 Like

I understand where you’re coming from, but it’s useful for any prospective developers to have a hint. There’s no point in me dedicating several days to hacking on it if someone else is already working on it.

I’m mostly interested if anyone has looked at it properly and deemed it technically impossible (not low enough access to the Bluetooth API), difficult (need to port encryption libraries to Monkey C), or other.

I’ve had a look at the CIQ docs, and the Bluetooth spec for Nuki, and it seems possible, but I’m sure other people must have gotten a bit further than that.

I’d buy a unit to play with myself, but I’m sort of waiting for the Pro to be back in stock.

@TomS btw, perhaps you could experiment with Connect IQ Store | Free Watch Faces and Apps | Garmin - if your watch can see/pair with the lock, then that’s a least a clue that it might be possible.

Some additional use-cases for me are:

  • I’ve lost phones/keys before - I’m unlikely to lose a watch as it’s literally attached to me
  • My watch has much better battery life than my phone - no fear of running out of power and then being unable to operate the lock
  • Phone is a lot more fragile than a watch, I’ve broken a few phones when out and about (maybe less of an issue now waterproof phones are more common)
  • I do run out the house and forget my phone sometimes - watch would allow me to safely auto-lock
1 Like

BLE connectivity is there. Lock is found in Scan and when I try to connect, the Text Info turns green. So fundamental connectivity requirements seem to be fulfilled.

What i can tell you is that we (Nuki) did not go as far as creating a fully working prototype. Main issue on the way was time and not technical deficiencies.

Steps to create such a prototype are to make sure that you can scan, connect and subscribe to the necessary characteristics (see BLE API). After that you’d need to port the encryption libraries to monkey C (https://tweetnacl.cr.yp.to/) and start sending messages. A starting point for this might be GitHub - I-Connect/NukiBleEsp32.

Great, thanks - it’s helpful to know that at least noone has investigated and deemed it not possible.

I guess I’ll pick up a 3.0 Pro when they become available and have a go.

2 Likes

I’ve had a harder look at this now (after buckling and buying a 2.0 and ble dongle - sigh).

I believe that this is currently not possible, as long writes are not supported - Toybox.BluetoothLowEnergy.Characteristic

You are correct. Without modifications on the Smart Lock side it won’t work, because the Garmin SDK neither supports write long (= concatenation of shorter packages) nor longer MTU sizes (= one long package).

Either modifications on the Smart Lock side, or on Garmin’s side (to support long reads/writes in Connect IQ apps). I can’t see Garmin implementing that any time soon, though.

From the Smart Lock side, I suspect it would be difficult to have a suitable level of security in a mere 20 bytes - although I suppose you could just send several 20 bytes messages and concat.