Have anyone heard from Nimly if it ever will be possible to remotely control the “away mode” i.e. not be able to open from the inside?
I’m currently using firmware build date 20230210 and it has worked without problem for a couple of months now. The only thing is that the battery is reported as 200% which I’m pretty sure is incorrect.
Not a major issue and not enough for me to want to update (not sure how I would to that either).
Or would I gain anything more by updating?
What did you pair it as in Phoscon, a Switch?
My lock with build date 20240201 works just fine, and the new module seems to be draining the battery far less compared to an old module I had. The only issue I am expiriencing with both modules is that the lock becomes unresponsive to messages sent from home assistant after it has not been used for some time (~1h). I get the following error in the z2m log:
Publish 'set' 'state' to 'xxx' failed: 'Error: Command 0xf4ce367783dd8e20/11 closuresDoorLock.unlockDoor({"pincodevalue":""}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received (55))'
Once I interact with the lock, everything is fine again.
I had problems with the first zigbee module to so I got a new one from Nimly. Seems to be having the same problem with the second one to.
Thought I would give it a shot with Z2M but the lock never shows up. I know that when I first got it installed it worked but then I added it to the blocklist since I wanted to try the Nimly hub… I’ve cleared out the blocklist now tough but it refuses to connect again.
Recently bought a nimly touch pro with a module
How do i pair it to my HA? (Zigbee2mqtt)
Removing batteries id not working.
I assume im not able to have connected to the nimly gw and ha at the same time?
I’ve got a nimly Connect Module too, it’s for a nimly Touch Pro lock (not sure if that matters, the module seems to be the same for any model?). That’s my 3rd module, as previous two had certain defects (first one was loosing connection and second one was draining the batteries), so nimly graciously sent (keeps sending) me replacements.
The current one that I got has firmware build date 20240625 and version 4.7.79.
I haven’t used any of these modules with Home Assistant before, because until now I’ve been using them with a Homely hub (norwegian home security company). But now I decided to try it out with Home Assistant, because I wasn’t entirely satisfied with the functionality exposed in Homely application.
The pairing with Zigbee2MQTT went fine, the device got interviewed and marked as supported, and I got the device in Home Assistant, but nothing seems to actually work. As you’ll see on the screenshot below, all the sensors report None, and the commands that I try to send to it (such as lock/unlock) seem to fail, because there is no reaction on the lock itself, and the logs have errors like:
zh:ezsp:ezsp: Frame changeSourceRouteHandler parsing error: RangeError: Attempt to access memory outside buffer bounds at new NodeError (node:internal/errors:405:5) at boundsError (node:internal/buffer:86:11) at Buffer.readUInt16LE (node:internal/buffer:245:5) at Buffer.readUIntLE (node:internal/buffer:182:17) at Function.deserialize (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/types/basic.ts:19:67) at new EZSPFrameData (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:180:54) at /app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:154:23 at Array.every (<anonymous>) at Function.createFrame (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:148:15) at Ezsp.onFrameReceived (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:439:35)
zh:ezsp:ezsp: Unparsed frame 0xc4. Skipped
z2m: Publish 'set' 'state' to 'nimly Touch Pro' failed: 'Error: ZCL command IEEE-ADDRESS-HERE/11 closuresDoorLock.lockDoor({"pincodevalue":""}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 57813 - 11 - 52 - 257 - 0 after 10000ms)'
Here’s a Home Assistant screenshot:
And also a Zigbee2MQTT screenshot, just in case (couldn’t embed it to the post because of the new user restrictions).
I am not even sure if I can trust this 100% value for the battery level.
My environment:
SONOFF Zigbee 3.0 USB Dongle Plus-E
EZSP v86.10.3.0 build 2971.39.0, commit 03269262024.7.3I am guessing that I probably got a way too new firmware for the nimly module, which is not yet supported by Zigbee2MQTT? Or maybe that is because my Zigbee coordinator firmware isn’t the latest? Or maybe I need to use ember driver instead of ezsp, so I need to re-flash my coordinator to a different firmware that supports it?
…well, I simply removed it from Zigbee2MQTT (had to use force option), re-inserted the batteries and added it to Zigbee2MQTT again. This time it “just worked”, everything is reported correctly to Home Assistant:
and I can successfully send commands to it as well. There were still the same errors in the logs at first, but now it all seems to be good.
I have managed to connect my Touch Pro with Home Assistant. Im using ZHA and SonofF E Dongle as Zigbee coordinator/gateway. FW 4.7.78
I am able to issue all of the zigbee commands (like door status, battery, latest user id etc), but only the icons in the image above are available. To sum it up, the nimly connect module and HA can communicate properly, but i can not see all of the icons in ZHA
Anyone facing the same issue.
I have the same issue, very few configuration options, quite disappointing. Using SkyConnect and ZHA.
I have also tried using Z2M instead but the lock never shows up when trying to pair it. All my other devices works just fine both with ZHA and Z2M.
But how do you get Last User ID and Battery Status?
Originally tried my Nimly Code with ZHA, but it only showed lock state. Changed to Z2M (new to HA, still testing and setting up my smart home) and all options and entities showed up. I can now toggle auto lock, see last user and battery level etc. Although, I’m not sure if the battery level is correct, as it’s still at 100% which seems unlikely after over a week of use?
Anyway, better integration with ZHA would be awesome for the Nimly locks, but at least it works well with Z2M in my experience so far. I had to try for a bit to get it to pair with Z2M - moving the coordinator closer to the lock with a USB extension cable helped (temporarily), and I also opened the unit and held down the button on the module to reset it.
I thought so too in the beginning with mine, but then it “finally” started loosing the charge, and it’s about one week per 1%. Here’s a chart of how it’s been in my case:
Sounds like you got it working!
I prefer Z2M anyways…
Are you using the gateway, or only the zigbee card in the lock?
I did indeed! The lock most connection one day, and after re-adding it, it has been very stable and the battery level is updating.
I’m using the module and a Sonoff Zigbee Plus-E Coordinator.
I like Z2M so far.
Thanks!
Cool, I’ll give Nimly a go.
Z2M is great because of the frequent updates, most zigbee stuff works!
Yeah, the ZHA support for Nimly is poor to say the least.
What is even more annoying, is that ZHA can apparently read out a whole bunch of interesting values from the lock, but for some reason, chose not to. See this picture from my setup, where I chose “Configure device” in the three dots menu next to reconfigure
What bothers me is why the ZHA developers chose to omit such an important value from the UI? I guess they can’t keep track of every device in the world, but reading out the battery status ought to be one of the most prioritized values in all battery operated devices, right?
I think the reason why ZHA is not showing battery percentage is because Nimly lock incorrectly presents itself as a Mains powered device. See Basic → power_source attribute.
My guess is that adding a simple quirk to zigpy/zha-device-handlers repository that changes it to a battery powered device should fix this issue.
Could you elaborate more on this? Is it like in “simple for me”, or “easy for anyone” ? 
As in it should be a quite easy contribution by someone familiar with zha quirks. Note that you can also add your own local quirk to achieve the same (see here Zigbee Guide: How-to add/setup local custom ZHA Device Handlers (also known as ”quirks”) in the ZHA integration).
I’m planning to do it at some point when having more time. I can post the instructions here if I’ll get around doing it.
I spent the entire evening yesterday, at first with high hopes and a “how hard can it be, actually?” -attitude. It turns out that it’s far from trivial. I am a hardware developer, and besides that, have been writing simple code for my own use for the last 40 years. But I must admit that I’m having trouble with the level of abstraction that modern coding techniques has brought us.
I have no issues grasping the concept of translating the output of one device (Zigbee) into a structure readable by another device (HA), but I just can’t wrap my head around the how. All these class calls everywhere, overloads and substitutions just got the better of me. 
If there was a step-by-step instruction, I’d stand a chance, but writing my own device handler in Python - a language I’m not familiar with - is more than I can do.
I will just have to patiently wait until someone skilled in the art, decides it’s worth his or her time to do it. Or, hope that one day, the ZHA developers make a user-friendly helper that allows to turn any arbitrary Zigbee cluster from any Zigbee device, into a HA device entity that is accessible from the UI as well as from automations and the rest of the HA environment.
I know that is a hell of a task to accomplish, but in the end it could relieve the ZHA devs from this endless flood of quirk requests from lesser users like me.
