Följer
Some new changes & bugfixes:
2.3.0
Big Zigbee update — the Zigbee lock now matches the Z-Wave one. New on Zigbee: the lock’s own firmware version on the Overview and Update pages, a ‘door forced open’ alarm (capability, Flow and notification), settings for sound volume, auto-relock, hinge direction, RFID tags and master-PIN unlock, plus setting the service PIN (code and validity) and the master PIN. Also fixes a case where the tamper / heat alarm could occasionally stay stuck on.
2.2.1
Z-Wave locks now correctly show the lock’s own firmware version (the keypad / lock controller, separate from the Z-Wave module) alongside the module version. It was previously read from the wrong field and never appeared.
2.2.0
New Update page: see your lock’s firmware version at a glance, find out whether the Z-Wave module is up to date, get tips for a smooth update, and jump straight to ID Lock’s official app for updating the lock itself. This release also fixes the ‘Verbose Z-Wave logging’ toggle on the Diagnostics page and adds more detailed firmware logging to make troubleshooting easier.
2.1.2
The ‘Verbose Z-Wave logging’ troubleshooting option now lives on the lock’s Diagnostics page in the app, where it’s easy to find — flip it on, reproduce the issue, then download a report from the same screen.
2.1.1
Adds a ‘Verbose Z-Wave logging’ option under the lock’s Diagnostics settings — turn it on to capture detailed lock reports when troubleshooting who locked or unlocked the door, then leave it off for quiet, normal operation.
2.1.0
Knowing who unlocked the door is now front and centre. When a PIN code or RFID tag is used you get a timeline notification naming the user and method — on by default; adjust it any time in the app’s Notifications settings. The app is also more reliable at reporting the unlock method even when the lock leaves out the user. Existing locks pick it up automatically.
The firmware update of the zwave module is still not confirmed, so use it at your own risk.
If you however still want to try it, activate the Z-Wave logging before and send med a diagnostic report if there is any issues.
Tried firmware upgrade, but it fails. I tried enabled Z-wave logging with transmit_complete_failed every time.
Debug report:
23dfee6c-d85c-47e0-bec8-32a302e7d403
Tried once more with z-wave logging turned on both in developer portal and in your app. Update now gives timeout.
c5e88524-69e8-4e86-975a-0a344439da0b
Thanks for the logs — they point to the cause, and it’s not the firmware file itself. On your 202, the firmware update, the version read, and the config settings are all “secure” Z-Wave commands, and your logs show every one of those timing out (while the lock’s own status messages come through fine). So the secure connection to the lock isn’t working, which is why the update can’t even start.
The fix is to re-pair the lock with security and a good signal:
- Export your codes/users in the app first.
- Put the lock close to Homey (or add a mains-powered Z-Wave device nearby as a repeater) with fresh batteries.
- Remove the lock from Homey, then add it again, letting it pair securely.
After re-pairing, check the lock’s settings — the firmware versions and config options should populate. If your module is genuinely older than 1.6 it’ll then offer the update (try it with the lock near Homey); if it’s already 1.6 it’ll correctly say you’re up to date.
Could you also tell me the lock model and roughly how far it is from your Homey? That helps confirm it’s a signal/secure-pairing issue.
Also make sure you’re on the latest app version — it adds a “Refresh from lock” action that reads and records the module’s current firmware version (so Homey stops offering updates you don’t actually need), and it increases the firmware-update timeouts and retries to give the large, encrypted transfer more time to finish on a weak or slow connection. Just note that “Refresh from lock” only works once the secure connection is back, so do it after re-pairing.
I will give it a try to re-add it, but when I recently re-added it with the purpose of moving it into your app I did move my Homey 2023 to within one meter from the ID Lock to try to get it to use S2, but it still went for S0 for some reason. Have anyone here been able to add an ID Lock with S2?
Does ID Lock z-wave module v1.6 support S2?
It was my understanding that it did not support this.
Your correct, z-wave module does not support S2 only S1(0)
Hi!
I tried this app on one of my locks. When trying to set a code/user from the app, everything looks good. But the code does not actually work on the lock
Paret fint, og påstår PINs er synkronisert, men ingen av dem virker på døren. Når jeg lagrer en ny kode piper låsen feilkode-tonen, ikke den gode tonen.
Samme her. Prøver å legge til koder. Synkroniseringen sier OK, men koden virker ikke.
Nå fikk jeg positivt pip fra låsen, men koden jeg synkroniserer fungerer likevel ikke.
Same, did you figure anything out?
Ser ut som den tror det er duplikat koder, og derfor ikke adder. Men det er ikke duplikat i hverken navn eller pin, prøvde helt ubrukte data.
Den som er logget som success er faktisk heller ikke suksess, koden virker ikke.
{
“appVersion”: “2.5.0”,
“generatedAt”: 1783764484181,
“device”: {
"name": "IDLock",
"model": "ID Lock 150/202",
"protocol": "zwave",
"firmware": "1.6",
"available": true,
"lastSeenAt": 1783764430225
},
“state”: {
"locked": true,
"doorOpen": false,
"battery": 65
},
“health”: [
{
"key": "connection",
"status": "green",
"label": "Tilkobling",
"detail": "Tilkoblet"
},
{
"key": "battery",
"status": "green",
"label": "Batteri",
"detail": "65 %"
},
{
"key": "sync",
"status": "green",
"label": "Synkronisering",
"detail": "Oppdatert"
}
],
“sync”: {
"running": false,
"queued": 0,
"lastSyncAt": 1783764428564,
"history": \[
{
"operation": {
"id": "mrg7a8ry-85ophv",
"type": "set_code",
"slot": 9,
"label": "Sett kode for Tore3 (plass 9)"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764428550
},
{
"operation": {
"id": "mrg79cse-5njnd8",
"type": "set_code",
"slot": 9,
"label": "Sett kode for Tore3 (plass 9)"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764387095
},
{
"operation": {
"id": "mrg790jy-3sh3py",
"type": "clear_code",
"slot": 9,
"label": "Slett plass 9"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764371240
},
{
"operation": {
"id": "mrg77al3-0hc29u",
"type": "set_code",
"slot": 9,
"label": "Sett kode for Tore2 (plass 9)"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764290954
},
{
"operation": {
"id": "mrg76ovl-6xfzou",
"type": "set_code",
"slot": 1,
"label": "Sett kode for Tore (plass 1)"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764262784
},
{
"operation": {
"id": "mrg76cry-ln0chl",
"type": "clear_code",
"slot": 1,
"label": "Slett plass 1"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764247136
},
{
"operation": {
"id": "mrg75rtn-y3yift",
"type": "set_service",
"label": "Endre service-PIN"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764219971
},
{
"operation": {
"id": "mrg758pc-lx37ij",
"type": "set_service",
"label": "Endre service-PIN"
},
"status": "success",
"attempts": 1,
"updatedAt": 1783764195143
}
\]
},
“logs”: [
"\[INFO\] (zwave) VERSION_REPORT {\\"Z-Wave Library Type (Raw)\\":\\"<buffer>\\",\\"Z-Wave Library Type\\":3,\\"Z-Wave Protocol Version (Raw)\\":\\"<buffer>\\",\\"Z-Wave Protocol Version\\":4,\\"Z-Wave Protocol Sub Version (Raw)\\":\\"<buffer>\\",\\"Z-Wave Protocol Sub Version\\":5,\\"Firmware 0 Version (Raw)\\":\\"<buffer>\\",\\"Firmware 0 Version\\":1,\\"Firmware 0 Sub Version (Raw)\\":\\"<buffer>\\",\\"Firmware 0 Sub Version\\":6,\\"Hardware Version (Raw)\\":\\"<buffer>\\",\\"Hardware Version\\":1,\\"Number of firmware targets (Raw)\\":\\"<buffer>\\",\\"Number of firmware targets\\":1,\\"vg (Raw)\\":\\"<buffer>\\",\\"vg\\":\[{\\"Firmware Version (Raw)\\":\\"<buffer>\\",\\"Firmware Version\\":0,\\"Firmware Sub Version (Raw)\\":\\"<buffer>\\",\\"Firmware Sub Version\\":0}\],\\"Variant Group\\":\[{\\"Firmware Version (Raw)\\":\\"<buffer>\\",\\"Firmware Version\\":0,\\"Firmware Sub Version (Raw)\\":\\"<buffer>\\",\\"Firmware Sub Version\\":0}\]}",
"\[INFO\] (zwave) lock event {\\"kind\\":\\"lock\\",\\"method\\":\\"manual\\",\\"user\\":\\"Manuell\\"}",
"\[INFO\] (zwave) lock event {\\"kind\\":\\"unlock\\",\\"method\\":\\"pin\\",\\"user\\":\\"Ukjent (kode 2)\\"}",
"\[INFO\] (zwave) notification raised {\\"trigger\\":\\"unlock\\"}",
"\[INFO\] (zwave) lock event {\\"kind\\":\\"lock\\",\\"method\\":\\"manual\\",\\"user\\":\\"Manuell\\"}",
"\[INFO\] (zwave) NOTIFICATION_REPORT {\\"V1 Alarm Type (Raw)\\":\\"<buffer>\\",\\"V1 Alarm Type\\":0,\\"V1 Alarm Level (Raw)\\":\\"<buffer>\\",\\"V1 Alarm Level\\":0,\\"Notification Status (Raw)\\":\\"<buffer>\\",\\"Notification Status\\":\\"On\\",\\"Notification Type (Raw)\\":\\"<buffer>\\",\\"Notification Type\\":\\"Access Control\\",\\"Event (Raw)\\":\\"<buffer>\\",\\"Event\\":15,\\"Properties1 (Raw)\\":\\"<buffer>\\",\\"Properties1\\":{\\"Event Parameters Length\\":0,\\"Sequence\\":false},\\"Event (Parsed)\\":\\"New user code not added due to duplicate code\\",\\"Event (Parsed 2)\\":\\"New user code not added due to duplicate code\\"}",
"\[INFO\] (zwave) NOTIFICATION_REPORT {\\"V1 Alarm Type (Raw)\\":\\"<buffer>\\",\\"V1 Alarm Type\\":0,\\"V1 Alarm Level (Raw)\\":\\"<buffer>\\",\\"V1 Alarm Level\\":0,\\"Notification Status (Raw)\\":\\"<buffer>\\",\\"Notification Status\\":\\"On\\",\\"Notification Type (Raw)\\":\\"<buffer>\\",\\"Notification Type\\":\\"Access Control\\",\\"Event (Raw)\\":\\"<buffer>\\",\\"Event\\":15,\\"Properties1 (Raw)\\":\\"<buffer>\\",\\"Properties1\\":{\\"Event Parameters Length\\":0,\\"Sequence\\":false},\\"Event (Parsed)\\":\\"New user code not added due to duplicate code\\",\\"Event (Parsed 2)\\":\\"New user code not added due to duplicate code\\"}"
]
}
Homey doesn’t allow choosing the tile status indicator for lock-class devices — the lock state is fixed as the primary indicator, so I can’t put the contact sensor there. The door state is available as the “Door open” sensor on the device and in Flows.
Found it, thanks to your diagnostic. Your lock rejects a new PIN if an identical code is already stored — including codes programmed directly on the keypad (that’s also why unlocks show “Unknown (code 2)”: that code lives on the lock but the app doesn’t know it). The lock acknowledges the write and only reports the rejection afterwards, which v2.5.0 ignored — so the app wrongly showed “synced”. v2.5.1 (Test channel shortly) verifies every code write with the lock and tells you when and why one is rejected. After updating: re-save your codes — pick a PIN that isn’t already on the lock. Tip until then: to get names on keypad-programmed codes, add a user in the app at that slot number without a PIN.
Also, use the debug mode in the lock settings activated prior to testing.
If you get any issues, submit a debug report from the application menu.
Sadly doesnt work - if the code existed, it should be able to unlock the door. I also tried 123456 which 110% guaranteed has never been used.
You’re right — a true duplicate would open the door, so something else is wrong on your lock. My working theory is that the Z-Wave module inside the lock accepts and stores codes but doesn’t hand them over to the lock panel itself (they’re separate units that sync internally). That would explain both the “duplicate” errors on fresh codes (colliding with old leftover codes inside the module, which you can’t see) and codes that report success but don’t work at the door. Could you update to 2.6.0 on Test and: (1) on the Users page, run “Check codes on lock” and tell me how many codes it finds and at which slots — anything you can’t account for is a leftover; (2) tell me what “lock firmware” says on the Overview page (module 1.6 needs panel 1.4.9 or newer); (3) enable verbose logging under Diagnostics, add one test code, and send a new diagnostic report — it now records whether the lock confirmed storing exactly what we sent. Meanwhile: try a battery pull (out 30 s). If the scan shows leftover codes, delete those slots from the app — deletes are verified against the lock now. If it still misbehaves after that, the fix is likely re-seating the Z-Wave module per the ID Lock manual (Manual page in the app settings) — note that can require re-pairing the lock with Homey, so it’s the last resort.
