Nope, no progress really. I had to remove the z-wave module since I had to change batteries every second day.
I’ll check the usercode issues to see if that gives me any hints, thanks!
Did some googling and found that it exists beta versions of z-wave modules that could have battery problems.
Haven’t found a way of checking what version I have in my module or where to send it to get it upgraded.
Wrote a mail to idlock but haven’t gotten any response yet.
btw Having major problems fitting the batteries, when I push in the last one the first one pops out.
Really annoying!!
Anyone else with that problem?
No change in the behavior for my lock. Still changing batteries every second/third day.
And still have major problems to insert them.
Changed parameter in “HABmin->Device Configuration” for the lock to “Polling period: 12 Hours”.
Haven’t seen any noticeable change though
I have written two emails do idlock asking questions but no response at all .
I’ve also written to “trygghetsexperten” from which I bought the lock to see if I could get another or return the lock.
Let’s see what they say
I’ve not followed this thread at all, but it might be worth grabbing a debug log, and loading it into the log viewer to see how often the binding is communicating with the device - just in case there’s something strange going on.
There should be very little communication, so if you’re seeing regular communication, then please send me the log (open a ticket on my website rather than posting logs with security here).
@TordYevl I took at look at the log you sent, and it looks ok. I guess it is from a restart as I see the binding request all the codes which does take quite a bit of time. This lock seems to have 190 of them and this takes a minute or so to complete. After this, there’s only a few door status reports, so I don’t think the binding isn’t doing anything to impact the battery. These reports seem to be initiated by the door itself, so I guess someone opened it…
The initialisation, and the downloading of the codes, will drain the battery a little, but unless you’re restarting many times per day, I doubt it will be an issue. I had a similar discussion elsewhere with someone who has a lock with 255 codes and he said it doesn’t seem to impact battery life on his lock.
So, I guess let’s see what the supplier says, but I would say the binding probably isn’t doing anything bad that would impact battery life (at least from what I see in this one log).
I was told by idlock that this lock uses 8 AA batterys a week (which corresponds with my observation). This document (sorry I’d only got the norwegian version) should indicate that openhab then polls the lock every 30 sec … The question then is : How can I change the polling intervals for the lock in openhab (im using 2.1 snapshot) ?
Clicking in PaperUI Configuration-Things-Idlock, and the the round blue icon with a pencil) throws me a ERROR: 500 - Internal Server Error …
Im habmin I cannot seem to locate any usable settings for this … Any eyeopening pointers would be welcome.
Polling period is normally a property on the device configuration of the thing in OH2. I am also not seeing this on my IDlock, but I think there are issues in the identification and discovery of the lock properties in OH2 Z-wave binding atm. I am running the latest snapshot of the Z-wave binding: OH2 Z-Wave refactoring and testing... and SECURITY.
If I understand correctly from the other thread, the device is being detected, so I would expect this to be available as an option. Do you have the Device Configuration selection in HABmin?
So according to ID Lock, their estimate would be around 3 months battery lifetime with a 30 minutes polling frequency…
That’s a bit short. Is it possible to customize that rate per device?
Really - I’m very surprised at that. My own analyses of battery life tends to indicate that polling in the tens of minutes or longer range should make limited difference to life since a poll response is a few milliseconds long.
However, if it’s the case then I would suggest to increase the polling frequency to whatever number you prefer.
for this Lock (when it is seurely included), there is no Configuration options in my habmin.
If I try to configure via paperUI, it flashes a 500 Internal Server Error on bottom right screen.
logs here. <- Disregard the openhab.log, the “grit” is in openhab.log.2 at timestamp 19:43
The missing config option and 500 Inernal Server Error is still teh same with Build #998 and latest Z-wave binding downloaded today at approx 17:30 CET.
After using 280 batteries for the last year i had to delete IDlock from openhab if i wanted the mother to my children to continue living here
What i noticed when i did this was that alot of decives “lost connections” for some hour. My therory is that the IDlock is activated as a router and is handeling alot of traffic and therfor is drained from battery after 10 days.
@chris, can that be the reason? That the driver for this is wrong?
As a side note, the only thing i could do with IDLock was open/close. Battery and alarm did not work ever.
My experience of IDlock 101s battery usage is not consistent…
Sometimes the batteries last for a couple of weeks sometimes a couple of months, without any clue of what the difference is.
Has anyone tried the new z-wave module modified to accept IDlock 150?
A bit late reply here, but I have actually given up on the zwave door-lock case. Kudos to IDLock to try something like this, but for me it seems that a battery driven door lock over zwave is not the way to go. If anyone have had better luck than me, I would be happy to read all about it
Wow, that is something. It’s a pity there is no EU-zwave module released for the Yale Doorman which is the best selling smart lock on the scandinavian market. They only offer cloud based integrations through proprietary wireless protocols. They think it’s more secure… (run the debate!) Well… I’ve bought a couple of them and started reverse engineering the internal protocols. A last desperate attempt
.
.
