ok. what about me ?
what should I do ?
ok. what about me ?
Contact firstname.lastname@example.org. That really is your best option, especially with locks.
I had already done that 2 days ago. I didn't receive any response.
Did you get an automated response acknowledging your email?
Edit: also, after unpairing from ST, did you factory reset the lock before trying to pair with HE?
yes I received an automated response.
Actually I had a spare lock waiting for install. I am trying with that one. It was not unpaired from ST and I remember I had factory reset it. At least , its app shows it's not installed anywhere.
But if you say that the reset step is important, I can try reset again.
@mike.maxwell has mentioned factory resetting z-wave devices in several threads.
I can’t say for sure whether that’s the crucial step for your device, initially you said you excluded your device from ST and are trying to pair with HE but now that is not the case? Or have you tried with two locks?
I am sure support will reply as soon as they’re able to, since the auto-response indicates you generated a ticket in their system.
ok I will try resetting and then pairing.
initially I said I had excluded device from ST and that's correct.
This is a spare lock excluded from my ST hub. And it was factory reset before (that's what I remember)
Hello, I did a a few times . the 4th time it worked and switching under the Device menu.
Battery Status, locked/unlocked condition everything is fine as long it is next to the Hubatit box. Move it away to the door ....DEAD again no connection. How handle that issue . (only 6 metes away clear veiw.).
Once you move it to it's final location, do a z-wave repair. Do you have a z-wave repeater in range of the lock?
I made a factory reset and now the lock is added to the HE hub.
But I am in the same situation with user @nest ; HE hub can only control the lock when it is in a very close range. If I take it to my door, it can not be controlled.
I did a z-wave repair at its final location. But that didn't solve the issue.
There is only 1 wall between the hub and the lock and the total distance is only 5-6 meters.
My ST hub can control it with same distance and same wall in between.
Of course there is a difference that on my ST environment I have adapter powered z-wave devices (repeaters) and they are not migrated to my HE environment yet. (1 siren, 1 motion sensor and 1 thermostat)
But ST hub can control the lock even when other zwave devices are turned off.
The distance is really close and I am surprised to see that HE hub can't control the lock from that distance. Most probably, when I migrate all my zwave devices, HE will be able to control all of them but what if I did not have any zwave repeaters ?
Also, additional question :
now I use the Danalock Lock as "generic zwave lock"
on my ST hub I had a specific driver (device handler).
Is it "ok" to go on with the generic driver ? am I missing anything ?
The generic zwave lock supports lock codes, I don't know if this lock supports user codes or not, if it does, then stick with that driver. If it doesn't, no harm though apps like LCM and anything else expecting code usage won't work. You can try the August driver (which doesn't have the lock code capability), however it was written specifically for the August and may not report physical actions correctly.
Hello, thanks for the answer, I do not have a repeater between this is to close to use a repeater 6 meter...
After the Repair no change . = no connection same issue like [ilkeraktuna]
_Hello, I am the new one here and several asked for the help with user login because I made a mistake and sign-in via social network. _
My experiences with Danalock V3 (DA) are about 6 months and with Z-Wave protocol two weeks. Also writing of device drivers via Hubitat are very weak. So correct me, if I am writing any non-sense.
At first I made a big mistake when I include DA in Z-wave hubitat and I remove it without exclusion etc. Reseting of DA is on separate post not belonging here. But at the and I was successful.
After many try & error I found article Z-Wave devices that should be changed from secure to non-secure. DA is pairing like non-secure. I have checked inside device code that parameter zwaveSecurePairingCode has value "false". Every communication must be in secure mode. I have asked @bobbyD to add to secure via e-mail and waiting for answer.
Meanwhile I have bought Fibaro Smoke Detector with Z-wave and I am lost in documentation and examples in and for Hubitat but it belongs to another thread.
I really understand that Hubitat is child and I like its concept.
As you say, the Fibaro Smoke detector may not be related, but I have one and I am using it with this information here:
Locks are certainly at the complicated end of the ZWave device spectrum. They are part of a class of device known as a Barrier device.. They are built to keep the outside on the outside and the inside safe on the inside. Garage Door Openers are in the same Barrier Class.
Barrier Class devices MUST Join Securely. Must. If they don't Join securely, they are required to NOT Work.
On the Device Info page for the device, scroll down and look here:
Notice the "zwaveSecurePairingComplete: true " line. Required.
Hubitat has an option for limiting Secure Joins. Truthfully you really only want your barrier devices to run securely. There's overhead to a secure communications which translates to 'slower.' Noticeably slower, noticeably higher load on the Hub.
On to Joining... (join is the ZWave word, pair is the Zigbee word for the same thing... great huh? )
There's two components of the ZWave specification that is almost specifically for Locks (barrier devices)
- Whisper Join
Whisper was created to reduce the possibility that someone sitting out on the street could capture your Lock's security codes. They decided that dropping the transmit power way down was the method. This forces the distance between the lock and the hub DURING JOIN to be inches, not feet. It is an OPTIONAL component. Not every lock does this, especially newer ones.
Beaming is a mechanism to work WITH the battery of your locks. Most AC powered devices support Beaming, but if you have a concern, look up your device at the ZWave Alliance. All manufacturers MUST submit a Conformance Report and they are available to all of us. Beaming is always spelled out, yes or no. Beaming is also Optional.
Here's an example of a GE/Jasco wall socket/outlet. Beaming is supported.
A Beaming capable repeating device will assist the Hub by being the device that waits for the battery driven lock to wake up and hand off the hub's message.
Check your Lock at the ZWave Alliance, you probably see it supports beaming and therefore you will want to extend your lock's battery life by having a beamer within 8-10 ft. Like any repeater, it can be further away than the lock,
Those are the Keys to the Lock kingdom. I must suggest that the Locks be towards the end of your migration path. You want a good mesh and devices that have identified themselves to the Hub for beaming to get a simplified Join.
Most times my Danalock works fine but once in a while my auto lock rule downer work. I think I pinpointed it to when we open the lock, open and close the door quickly. I have made another rule that triggers in the first rule and activate a second lock if the door is closed and the lock is unlocked. In my first rule I have a delay of 10 sec when the door closes before the lock command are sent to the lock.
My guess is that the Danalock somehow isn’t communicating quick enough when it’s unlocked and get a lock command.
Is this anything anybody know something about?
You have the same issue as me. I had Danalock Z-Wave connected via Hubitat first, now I am using Fibaro system. But it does not matter. There is a lack in communication directly in device. Sometimes Danalock is not reachable and the system must ask him to wake up. The state of lock / unlock is not reporting reliably. I was complaining to Danalock DE company that there are issues in their software, however later I have discovered that you can do with software everything but if you are not receiving right response from device you have no chance. I made workaround, and have a watch dog for controlling and checking status that but to be honest I would not recommended it for critical or sensitive using, Sometimes it happens that it is announced "locked" but the reality is different.
So far Ive only seen the issue when unlock, open the door and then close the door quickly. I might try a longer delay time than 10 seconds and see if that helps. My extra lock rule seem to have helped and its not triggered that many times so far.
If I see more issues I might contact Danalock. The few times Ive been in contact with them, it hasn't been a great experience though.
Danalock is saying - it is locked and it is not. The basic issue. Danalock is not bad device however not perfect. The same with Hubitat. They closed the door to community or somebody who wants simple help them so I focused on Home Assistant.
Main issue I hade with the Danalock was that I mounted my Strips Guard wrong (really bad instructions). After contacting them and remounted my door sensor my Danalock works much better but far from 100%.
Ive made my RM like this and it works very well so far.
Most of the times I get no notifications since the lock locks at once but Ive seen both 2 and 3 times before the Danalock actuually locks.
But so far the lock has actaually locked my door even if it has been after a couple of tries.