Summary
The zwave-lock Edge Driver does not respond to DATE_GET (Z-Wave Time CC v2, COMMAND_CLASS_TIME).
When a lock sends DATE_GET, the hub acknowledges it at the Z-Wave MAC layer (TRANSMIT_COMPLETE_OK) but never sends DATE_REPORT.
Root cause:
init.lua registers only a Time.GET handler, with no Time.DATE_GET entry:
zwave_handlers = {
[cc.TIME] = {
[Time.GET] = time_get_handler -- used by DanaLock
}
},
Proposed fix
Add a date_get_handler alongside the existing time_get_handler:
local function date_get_handler(driver, device, cmd)
local time = os.date("*t")
device:send_to_component(
Time:DateReport({
year = time.year + 1900,
month = time.month,
day = time.day
}),
device:endpoint_to_component(cmd.src_channel)
)
end
zwave_handlers = {
[cc.TIME] = {
[Time.GET] = time_get_handler,
[Time.DATE_GET] = date_get_handler, -- add this
}
}
Impact
- Schedule Entry Lock CC (week-day / year-day slots) non-functional without date
- Affects any Z-Wave device performing a full Time CC v2 sync (not only DanaLock)
- Note: SmartThings documentation lists DATE_GET/DATE_REPORT as supported, but the implementation is incomplete
Evidence
Tested on: Aeotec GP-AEOHUBBV3EU (SmartThings hub)
TIME sync send TIME_GET
TIME sync TIME_REPORT 07:31:26 rtc_failure=0 // hub responds correctly
TIME sync send DATE_GET
TIME sync DATE_GET tx status=0 // hub ACKed frame (MAC layer OK)
TIME sync timeout step=2 // no DATE_REPORT after 30 s
TIME sync DATE_GET unsupported // device gives up after 3 retries
Summary
The zwave-lock Edge Driver does not respond to DATE_GET (Z-Wave Time CC v2, COMMAND_CLASS_TIME).
When a lock sends DATE_GET, the hub acknowledges it at the Z-Wave MAC layer (TRANSMIT_COMPLETE_OK) but never sends DATE_REPORT.
Root cause:
init.lua registers only a Time.GET handler, with no Time.DATE_GET entry:
Proposed fix
Add a date_get_handler alongside the existing time_get_handler:
Impact
Evidence
Tested on: Aeotec GP-AEOHUBBV3EU (SmartThings hub)