Homebridge-hue: Danalock support

Created on 11 Jan 2021  ·  16Comments  ·  Source: ebaauw/homebridge-hue

Hi

Is there any chance Danalock will be supported soon? or it's possible to change it from a bulb to a lock?

I'm trying to move away from Jeedom to this, as this plugin is blazing fast compared to Jeedom, but in Jeedom I can define the type for every lights, switches, etc.

So as I know that the Danalock shows up as a light in Jeedom, I just redefine it as a lock, before exposing it to homebridge.

Skærmbillede 2021-01-11 kl  13 56 56

enhancement

Most helpful comment

I've known that smart locks are pretty cool for some time. I just have no experience with Zigbee smart locks.

I installed a Nuki Smart Lock on the door of my apartment and an Opener for the front door of the building. Of course, I created by own Homebridge plugin for these. Now can I can tell Siri from my Apple Watch to buzz me in: übercool!

All 16 comments

Is the Danalock supported by deCONZ yet? If so, please list the resource.

Is the Danalock supported by deCONZ yet? If so, please list the resource.

Yes it was merged the 14. July 2020

https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3030/files

You mean the resource from deconz gui?

Here's from postman

Skærmbillede 2021-01-11 kl  19 12 08

Not sure I can support this. HomeKit needs current lock state vs target lock state for locks. Also, I understand from the deCONZ issue, the battery isn't exposed. I would better be exposed as /sensors resource (it doesn't support Zigbee groups anyways), with current lock state in state and target lock state in config, similar to thermostats.

I won't be able to test it, as I don't have the Danalock myself (or any other Zigbee lock). After long considerations, I decided to go for Nuki instead, because of their Opener. Bluetooth sucks, of course, but they have a bridge that provides a local HTTP API, taking care of the Bluetooth connections to the Smart Lock and to the Opener. Of course, I've created a Homebridge plugin for that API, which works better than I'd hoped for. I can now tell Siri to "buzz" me in: übercool.

Not sure I can support this. HomeKit needs current lock state vs target lock state for locks. Also, I understand from the deCONZ issue, the battery isn't exposed. I would better be exposed as /sensors resource (it doesn't support Zigbee groups anyways), with current lock state in state and target lock state in config, similar to thermostats.

I won't be able to test it, as I don't have the Danalock myself (or any other Zigbee lock). After long considerations, I decided to go for Nuki instead, because of their Opener. Bluetooth sucks, of course, but they have a bridge that provides a local HTTP API, taking care of the Bluetooth connections to the Smart Lock and to the Opener. Of course, I've created a Homebridge plugin for that API, which works better than I'd hoped for. I can now tell Siri to "buzz" me in: übercool.

After Danalock contracted with the Norwegian Department of Defence, they went into total darkness and only rarely makes updates to the locks :-/ Therefore I don't want to waste yet another €100,- just for a bridge for the lock, though that bridge has Homekit :-)

Anyway, With the Danalock, you have to define yourself how far it has to turn, to be either locked or unlocked, so unless it's able to turn so far, it won't change state. Same with my setup now. Though deConz treat it as a bulb, if I turn that bulb on and off, it will momentarily change state, but shortly after change to the current state, so if it's unlocked (bulb off) and I lock the door (bulb on), and the lock somehow is jammed, it will stay bulb off. That also goes for the other way around.

Not sure I can support this. HomeKit needs current lock state vs target lock state for locks. Also, I understand from the deCONZ issue, the battery isn't exposed. I would better be exposed as /sensors resource (it doesn't support Zigbee groups anyways), with current lock state in state and target lock state in config, similar to thermostats.
I won't be able to test it, as I don't have the Danalock myself (or any other Zigbee lock). After long considerations, I decided to go for Nuki instead, because of their Opener. Bluetooth sucks, of course, but they have a bridge that provides a local HTTP API, taking care of the Bluetooth connections to the Smart Lock and to the Opener. Of course, I've created a Homebridge plugin for that API, which works better than I'd hoped for. I can now tell Siri to "buzz" me in: übercool.

After Danalock contracted with the Norwegian Department of Defence, they went into total darkness and only rarely makes updates to the locks :-/ Therefore I don't want to waste yet another €100,- just for a bridge for the lock, though that bridge has Homekit :-)

Anyway, With the Danalock, you have to define yourself how far it has to turn, to be either locked or unlocked, so unless it's able to turn so far, it won't change state. Same with my setup now. Though deConz treat it as a bulb, if I turn that bulb on and off, it will momentarily change state, but shortly after change to the current state, so if it's unlocked (bulb off) and I lock the door (bulb on), and the lock somehow is jammed, it will stay bulb off. That also goes for the other way around.

Is it the same if you set the lock to use end to end unlock? Does it show in Home App as lock or bulb?

Not sure I can support this. HomeKit needs current lock state vs target lock state for locks. Also, I understand from the deCONZ issue, the battery isn't exposed. I would better be exposed as /sensors resource (it doesn't support Zigbee groups anyways), with current lock state in state and target lock state in config, similar to thermostats.
I won't be able to test it, as I don't have the Danalock myself (or any other Zigbee lock). After long considerations, I decided to go for Nuki instead, because of their Opener. Bluetooth sucks, of course, but they have a bridge that provides a local HTTP API, taking care of the Bluetooth connections to the Smart Lock and to the Opener. Of course, I've created a Homebridge plugin for that API, which works better than I'd hoped for. I can now tell Siri to "buzz" me in: übercool.

After Danalock contracted with the Norwegian Department of Defence, they went into total darkness and only rarely makes updates to the locks :-/ Therefore I don't want to waste yet another €100,- just for a bridge for the lock, though that bridge has Homekit :-)
Anyway, With the Danalock, you have to define yourself how far it has to turn, to be either locked or unlocked, so unless it's able to turn so far, it won't change state. Same with my setup now. Though deConz treat it as a bulb, if I turn that bulb on and off, it will momentarily change state, but shortly after change to the current state, so if it's unlocked (bulb off) and I lock the door (bulb on), and the lock somehow is jammed, it will stay bulb off. That also goes for the other way around.

Is it the same if you set the lock to use end to end unlock? Does it show in Home App as lock or bulb?

I haven't tried the end to end lock/unlock as my lock only takes about 1 round to lock/unlock, but I'm guessing it would be the same as it's measuring the distance.

As standard it shows up as a bulb, but homebridge in Jeedom got the ability to change the characteristics on every device before it's exposed to homebridge, so I'm able to manually change it to a lock

This is from deConz
Skærmbillede 2021-01-12 kl  17 19 11
Skærmbillede 2021-01-12 kl  17 19 29

This is before it's exposed to homebridge
Skærmbillede 2021-01-12 kl  17 20 48

And this is all the options I got:
Skærmbillede 2021-01-12 kl  17 23 17
Skærmbillede 2021-01-12 kl  17 23 26

I guess battery status does not work either?

I guess battery status does not work either?

That's correct but I'm only changing it to a lock because it looks wrong as an bulb (my kids kept turning it on and off) but also so I can use the automations in the home app

Not sure I can support this. HomeKit needs current lock state vs target lock state for locks. Also, I understand from the deCONZ issue, the battery isn't exposed. I would better be exposed as /sensors resource (it doesn't support Zigbee groups anyways), with current lock state in state and target lock state in config, similar to thermostats.

I won't be able to test it, as I don't have the Danalock myself (or any other Zigbee lock). After long considerations, I decided to go for Nuki instead, because of their Opener. Bluetooth sucks, of course, but they have a bridge that provides a local HTTP API, taking care of the Bluetooth connections to the Smart Lock and to the Opener. Of course, I've created a Homebridge plugin for that API, which works better than I'd hoped for. I can now tell Siri to "buzz" me in: übercool.

I can see the code has been updated to report current state on the lock

https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3751/files

That's actually making it worse: you set the lock, but it immediately reports back that it's still unlocked.

That's actually making it worse: you set the lock, but it immediately reports back that it's still unlocked.

Well it's working perfectly here. Guess I'll have to jump back to zigbee2mqtt

Guess I'll have to jump back to zigbee2mqtt

If that's an option: please do and don't bother me.

For those of you who do appreciate that I'm providing Homebridge Hue for free, in my own time:

v0.12.17 provides experimental support for /lights resources of type Door Lock. I don't have any Zigbee door lock, so I cannot test this in full. I did test the HomeKit interaction with a regular light, and that seems OK. Some remarks:

  • I understand from the deCONZ code that a state.on value of true means locked, and false means unlocked. This is counter-intuitive, as Home shows the Tile as on when unlocked;
  • I only set _LockCurrentState_ from Homebridge Hue; _LockTargetState_ is only set from HomeKit (except on startup, where it mirrors _LockCurrentState_;
  • On setting _LockTargetState_, Homebridge Hue sends the appropriate PUT to the light state, but doesn't update anything in HomeKit. The deCONZ API should change state.on when the lock has changed, causing Homebridge Hue to update _Lock Current State_. The _Opening..._ or _Closing..._ state in Home is maintained by Home itself, on the values of _Current Lock State_ and _Target Lock State_.
  • As mentioned above, no battery state, as the API doesn't expose this;
  • I see the resource exposes state.alert. Does that do anything? What values does it take? For now, I'm ignoring it.

That's really cool @ebaauw, happy to see you've seen the coolness of having automated locks. I have had danalock for a while, but unfortunately only the BT version. I'll buy a ZigBee version and test this code out for you!

I've known that smart locks are pretty cool for some time. I just have no experience with Zigbee smart locks.

I installed a Nuki Smart Lock on the door of my apartment and an Opener for the front door of the building. Of course, I created by own Homebridge plugin for these. Now can I can tell Siri from my Apple Watch to buzz me in: übercool!

This is awesome.
I’m in the market for locks and will buy Yale locks once deconz supports them. I see work is being done to do so.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3750

Was this page helpful?
0 / 5 - 0 ratings

Related issues

brandungskieker picture brandungskieker  ·  4Comments

jostrasser picture jostrasser  ·  3Comments

thumax picture thumax  ·  4Comments

gcappucc picture gcappucc  ·  11Comments

Stefan-83 picture Stefan-83  ·  4Comments