Hmmm…couple of things don’t make sense here.
The default Zigbee lock handler in the lua libraries is responsible for generating the event. For the codeName, it first assigns a default value “code (codeId used to unlock the lock)” and then tries to do a lookup in the lockCodes array. If it finds a non-empty value for the codeId in the array, it assigns the name it found in the array. Otherwise, you get the default value
if (source == 0) then
local code_id = zb_rx.body.zcl_body.user_id.value
local code_name = "Code "..code_id
local lock_codes = device:get_field("lockCodes")
if (lock_codes ~= nil and
lock_codes[code_id] ~= nil) then
code_name = lock_codes[code_id]
end
event.data = {method = METHOD[0], codeId = code_id .. "", codeName = code_name}
This would imply that the default handler finds a completely empty array or an empty value in the array for the codeId that unlocked the lock. Since we know that the lockCodes array is populated, there is some disconnect between the driver and the default handler. @Mariano_Colmenarejo might be able to do some digging to figure out what is happening here.
The more confusing thing for me is that the codeId is in the event data so, in theory, SLGA should be able to find the associated name that it has already pulled out of the lockCodes capability from the driver. This is going to take getting ST support involved since they are responsible for the SLGA. I looked back in the history of this topic, but didn’t see it, so refresh my memory that you do see the names when you go to the Lock Codes drop down in SLGA. Also, do you see a “Last unlocked (date)” under their names?
If the codeName in the unlock event were populated properly, you could use Sharptools to generate a notification that included it. Since the codeName is not being properly set, a notification that says “Code 1 unlocked the door” is pretty useless.