Closed Lheriss closed 2 years ago
I'm not sure if fob is the right type. Just guessing, for security reasons a fob should only be allowed to execute the fob actions defined for single, double, and triple press. I think "app" could be the better choice.
Since we can only figure this out by trial and error, I've built two binaries. The first authenticates as an app, the second as a fob. After flashing you'll see "5.15-app" or "5.15-fob" as version.
Let me know if one of the two works, I'd make it a permanent configurable feature.
Hi, Fantastic! I could try your binaries this week-end. You were right: the nuki_hub_app is working fine (the fob doesn't). It's even better than I thought, as I didn't expect to get the lock state with the keyfob configuration. But it is present with the app configuration! And I can confirm that the official bridge is still working perfectly. For the record : after pairing, you see a new user (NukiHub) on the official Nuki app. Great work, thanks!
It's now configurable as both bridge in app, check the newly released version 6.0.
Hi, Thanks for the great job! I have a particular request I suppose... I would like to continue using the official bridge, but be able to open the door from an esp32 (and better : to be able to use gpio, too). Problem is, the lock doesn't recognize two hubs. Once paired with nuki_hub, it isn't paired with the official bridge anymore. I know that it should be possible to advertise as a keyfob when pairing rather than as a hub (taken from another library) :
That means, of course, no more information returned directly from the lock to the esp. But then, it's still possible to open the door, and to keep the official bridge...
I wonder if it would be possible to implement such an option... Thanks! Laurent