[APP][Pro] ID Lock App (v2.0.0)

ID Lock (Z-wave)

This app adds support for ID Lock Z-wave devices made by ID Lock AS working on the Z-wave protocol.

Links:

Supported devices

ID Lock 101 (incl. Z-Wave module board 01A)

ID Lock 150 (incl. Z-Wave module board 01A)

image
Supported features:

  • Door lock / unlocked
  • Door open / closed (contact alarm)
  • Heat alarm
  • Tamper alarm
  • Battery (alarm)

Triggers:

  • Someone unlocked the door (ID Lock 150 only)
  • Door lock / unlocked
  • Generic “an alarm triggered” trigger cards from devices, with additional logic AND condition isolating device

Supported Languages:

  • English

Feedback:

Any requests please post them in the ID Lock topic on the Athom Forum or contact me on Slack

If possible, please report issues at the issues section on Github otherwise in the above mentioned topic.

Contributions

If you appreciate this app, contribute to future development by making a paypal contribution

2 Likes

Changelog:

v 1.2.2

  • Fix issue where ID lock app is crashing due to missing triggerSettings object

v 1.2.1

  • Add possibility to report different unlocking triggers (Homey / Code / Tag / Button (from inside)); credits to Mats Paulsen
  • Converted settings page to use languages definition (locale) files (english locale); credits to Mats Paulsen
  • Update meshdriver to version 1.2.32

v 1.2.0

  • Add support for registering user codes and recognizing who unlocked the door (for ID Lock 150) (credits to Mats Paulsen)
  • Minor (cosmetical) modifications to make the app Homey SW v2.0.0 compatible
  • Update meshdriver to version 1.2.28

v 1.1.0

  • Add support for ID Lock 150
  • Update meshdriver to version 1.2.22

v 1.0.1

  • Remove (and overrule) default getOnOnline triggers to try to resolve battery draining issue

v 1.0.0

  • App store release for ID lock 101 (including Z-Wave module board 01A)
2 Likes

Frequently Asked Questions:

Hi Ted and thanks a ton for making this app, even though you don’t have access to the lock itself.

I have the IDlock 150 with the z-wave module and want to report the following.

  1. With the latest stable version, editing the the ManifacturerID to include 883, everything seems to work. Battery reports, locked state, door state etc works, as does locking/unlocking from homey. Did never test any flows.
  2. The development app, where you’ve added support for IdLock 150, does NOT work as it should. Reporting of locked state, door state, battary, heat alarm shows noting, and I’m not able to lock/unlock the door from homey.
    However, changing settings under “device specific” from homey DOES work!

This is the debug log

✓ Validating app…
✓ Homey App validated successfully against level debug
✓ Packing Homey App…
✓ Installing Homey App on Homey (http://10.13.37.132:80)…
✓ Homey App no.idlock successfully installed
✓ Running no.idlock, press CTRL+C to quit
─────────────── Logging stdout & stderr ───────────────
2018-08-27 20:27:09 [log] [IDLock] MyApp is running…
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] ZwaveDevice has been inited
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] ------------------------------------------
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] Node: 2cb7dfb7-796e-4799-ba4a-f2c13f6379d0
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - Battery: false
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - DeviceClassGeneric: GENERIC_TYPE_ENTRY_CONTROL
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - CommandClass: COMMAND_CLASS_ZWAVEPLUS_INFO
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Version: 1
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Commands:
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — ZWAVEPLUS_INFO_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — ZWAVEPLUS_INFO_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - CommandClass: COMMAND_CLASS_MANUFACTURER_SPECIFIC
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Version: 1
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Commands:
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — MANUFACTURER_SPECIFIC_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — MANUFACTURER_SPECIFIC_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - CommandClass: COMMAND_CLASS_SECURITY
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Version: 1
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Commands:
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — NETWORK_KEY_SET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — NETWORK_KEY_VERIFY
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_COMMANDS_SUPPORTED_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_COMMANDS_SUPPORTED_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_MESSAGE_ENCAPSULATION
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_MESSAGE_ENCAPSULATION_NONCE_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_NONCE_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_NONCE_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_SCHEME_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_SCHEME_INHERIT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — SECURITY_SCHEME_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - CommandClass: COMMAND_CLASS_DEVICE_RESET_LOCALLY
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Version: 1
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Commands:
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — DEVICE_RESET_LOCALLY_NOTIFICATION
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - CommandClass: COMMAND_CLASS_POWERLEVEL
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Version: 1
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Commands:
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — POWERLEVEL_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — POWERLEVEL_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — POWERLEVEL_SET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — POWERLEVEL_TEST_NODE_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — POWERLEVEL_TEST_NODE_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — POWERLEVEL_TEST_NODE_SET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - CommandClass: COMMAND_CLASS_CONFIGURATION
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Version: 1
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Commands:
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — CONFIGURATION_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — CONFIGURATION_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — CONFIGURATION_SET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] - CommandClass: COMMAND_CLASS_BASIC
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Version: 1
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] – Commands:
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — BASIC_GET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — BASIC_REPORT
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] — BASIC_SET
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0] ------------------------------------------
2018-08-27 20:32:29 [log] [ManagerDrivers] [IDlock150] [0]
2018-08-27 20:32:29 [err] [ManagerDrivers] [IDlock150] [0] Invalid commandClass: DOOR_LOCK
2018-08-27 20:32:29 [err] [ManagerDrivers] [IDlock150] [0] Invalid commandClass: DOOR_LOCK
2018-08-27 20:32:29 [err] [ManagerDrivers] [IDlock150] [0] Invalid commandClass: BATTERY
2018-08-27 20:32:29 [err] [ManagerDrivers] [IDlock150] [0] Invalid commandClass: BATTERY
2018-08-27 20:36:14 [log] [ManagerDrivers] [IDlock150] [0] configurationSet() → Doorlock_mode: 0, 1, 1
2018-08-27 20:36:15 [log] [ManagerDrivers] [IDlock150] [0] configurationSet() → successfully set 1, size: 1 to 0 (parsed: 0 / 0x00)
2018-08-27 20:36:29 [log] [ManagerDrivers] [IDlock150] [0] configurationSet() → Doorlock_mode: 1, 1, 1
2018-08-27 20:36:31 [log] [ManagerDrivers] [IDlock150] [0] configurationSet() → successfully set 1, size: 1 to 1 (parsed: 1 / 0x01)

Here are print screens
59

58

@Baron it looks like something went wrong during the inclusion of the doorlock based on de GitHub Development branch…

Some critical command classes are not shown in the command class overview; COMMAND_CLASS_DOOR_LOCK, COMMAND_CLASS_USER_CODE and COMMAND_CLASS_NOTIFICATION, which are essential in the drivers functioning… that these command classes are missing, will result in Invalid commandClass: DOOR_LOCK error message and that the change of state is not shown on the mobile card…

Can you try to remove, reset and re-include the doorlock based on the development branch?
Preferably with Homey at close distance of the door lock…

@TedTolboom you where totally right. Tried removing and re-adding the lock as a device a few times without success. But after removing it, and rebooting the lock (resetting batteries) it seemed to add fine again.
Maybe woring after rebooting the lock was just a coincidence, don’t know fore sure.

Working fine now. Do you need any type of debuglog? Have it up and running with the console right now anyway

Good to hear… I was about to release the ID lock 150 driver towards the app store…
will still do based on your latest feedback…

Can you post the debug log here as text file? Just for reference…

Yes, I would say you can release it. Here is the debug log, opened the door with both code, rfid and service code while logging. There should also be a few failed attempts with rfid as well as with code.

The log is 1000 rows long, so pasted it here
https://pastebin.com/QJnXh9Vy

BTW, It would be awesome if we could set the “service pin mode” in a flow.

That will allow us to activate service pin on by triggers. Our hose maid comes every other wednesday. And I want to be able to just activate the service mode on these days for example.

I have already tested setting the service pin code on the panel, and then letting it run out. Setting the service pin mode again via homey re-activates the last set code for the new period.

@TedTolboom, would it help you much if you where able to borrow an IDLock with a z-wave module? I have one spare set that wont be used for some time

@Baron an ID Lock 150?
Having a device available will extremely reduce the debugging time… for sure.

yes, IDLock 150. I Don’t have the spare z-wave-module in my hands yet, but should get it in the coming days.
Could not figure out how to send private messages here on the new forum. But send me your address to me and I’ll see what I can do :wink:

1 Like

Just send you a PM (check your avatar image on the top right)…

1 Like

Hi and thanks for the development of the IDLock app for Homey! Very appreciated.
I have a IDLock 101 (Man. ID 560) and are struggling with rapid battery drainage, think 4 days now since a fresh set of batteries was inserted and today the lock started giving low battery tones. Homey still reports 100%, but i think they are low as the lock is playing the tunes.

I see that there have been some problems with this before as the newest update has a fix that may fix the drainage. In my case, unfortunately it has not worked. Is there anything i can contribute with to help fix this … ?

Regards,
Reidar

Hi @Reidar_Oestrem,
You’re correct this is still an ongoing issue.

Unfortunately I have to draw the conclusion that I’m not able to solve it from app side…

@juw2 already provided an extensive logging showing that the IDLock is requesting a security handshake, but apparently gets an incorrect response from Homey… so the IDLock will keep requesting it depleting the batteries rapidly.

Security handshakes are handled outside control of the app / device driver; in Homey’s core (for security reasons)…
Hence my conclusion that I’m not able to solve it (myself).

Athom is currently (as I type) looking into the issue to see if they can find a solution for it. If I have more info, I’ll provide an update in this topic.

Hi TedTolboom and thanks for your extensive reply!
I will need to pull my Zwave module then to conserve the batteries in the mean time. I noticed that Homey reports the lock as Battery: No … so i thought that might be the issue like Homey polls more when it thinks its a non battery device.

I’ll follow your thread closely and thanks for you efforts.

Reidar

I just uploaded v1.1.0 to the app store; which includes support for the ID Lock 150: waiting for app store approval

For the people that installed and tested the Github version: you can simply install this update of the Github version.

I had a similar issue with my 101. Battery drain rapidly. solved this with taking out the Zwave module. Wait some minutes then put it back in. This was actually exactly same with Vera plus controller. Worth a shot.

Taking out the Z-wave module and putting it back in the lock will force a reinitialization…
Athom is looking into the security handshake, because this might also be the cause of the failing motion sensors…