Z-Wave Lock in Program

[smithlevenson]

Hey,

I have a Schlage Camelot lock that has worked fine for a few months. However when I created a simple program that tries to lock it, the lock fails and I can't get it to respond again. It just stays with a little exclamation point by it until I reset the ISY. I am running firmware 4.4.6 and z-wave firmware 4.55.

 

The program is KPL Button On Then lock. I have seen like 6 or 7 different errors from "ignored unsupported unsolicited z wave message",   "Cannot find UID" and a couple others.

 

It really just stays a little messed up until I un-enroll, factory reset the z-wave, and re-enroll.  Then it works fine, a little slow, but fine. Any ideas?

[stusviews]

You need a repeater (even if its been working for years). RF interference is nearly impossible to detect and it is impossible to filter. The repeater with the best reputation is the Aeon Gen 5 Siren.

[smithlevenson]

Geezz. Another $50 bones to make those $150 locks work with a $300 controller. Sucks to be me. Is that the only solution.

[stusviews]

A Nexia controller plus a monthly subscription would work. So will adding more line powered Z-Wave devices. Don't fault the ISY, UDI did not create the Z-Wave protocol.

[smithlevenson]

Not faulting anyone, but I have 20 year old christmas light remotes that can change a switch at 20 feet.

 

I guess I just don't get why it has worked fine on mobilinc for months and an ISY program just crashes the whole thing.

[stusviews]

Exclude the lock, twice is best, then include it. What's the result?

[smithlevenson]

Exclude the lock, twice is best, then include it. What's the result?

 

Everything is fine as long as I don't run a program that uses the locks. If I do, the locks quit responding.

 

I had to factory reset everything and then add the locks and restart the ISY to get everything back online correctly. If I leave it alone at that point it has no issues and is pretty snappy in response to commands sent from Admin Console or Mobilinc.

[Michel Kohanim]

Hi smithlevenson,

 

Is this door lock the only Z-Wave device you have? If not, please run Z-Wave | Tools | Heal Network till such time that there are no errors. What I am suspecting is that the door lock cannot hear the beam that makes it wake up.

 

If that does not help, please right mouse click on it | Z-Wave | Show Z-Wave Info .. | All. Need to figure out whether or not there are any paths to ISY (neighbor).

 

With kind regards,

Michel

[smithlevenson]

Hi smithlevenson,

 

Is this door lock the only Z-Wave device you have? If not, please run Z-Wave | Tools | Heal Network till such time that there are no errors. What I am suspecting is that the door lock cannot hear the beam that makes it wake up.

 

If that does not help, please right mouse click on it | Z-Wave | Show Z-Wave Info .. | All. Need to figure out whether or not there are any paths to ISY (neighbor).

 

With kind regards,

Michel

 

OK. I have two Schlage z-wave locks both about the same distance from the ISY.

One seems to receive the signal fine from Mobilinc and Admin Console.

I have finally have that one responding to the ISY program.

 

The other one still kicks out the "Ingnored unsupported unsolicited Z-Wave message" error. I am guessing it just can't reach that lock. I will try the range extender and see if it helps.  Heal network doesn't do anything to help the other lock. I have the log saved and can share it if you think it would still help.

[vjk]

I have a Yale lock that started to exhibit delays a couple of month ago(i.e. instead of the usual 1 sec wake up time it took 2-3 seconds).  It worked fine otherwise.  I used it with a different controller (vrc0p), not with ISY though. No amount of "healing" helped to cure the problem.  Finally, when I traced actual zwave packets,  I discovered that the lock was trying to talk to a non-existing controller, timed out after a second or two and then talked successfully to the legitimate controller.  The non-existing controller had been removed from the network for those same couple of months,  but the lock retained the association with the old controller. As soon as I removed the lock association manually, it started to work fine.

 

I do not know if your lock can have simultaneous associations to multiple zwave controllers, some locks cannot, some can (Yale can be associated to up to 4 controllers).  When you reset your lock, all associations should have been erased from its memory, so you may have "fixed" the problem.

 

Whether or not you need a repeater, you can find out only if you know signal strength at various points in your network.  However, the poor excuse for protocol that zwave is does not provide this metric.  I had to build my a diy  sniffer (to get a partial handle on my network) that provides me with RSSI.

[smithlevenson]

Riddle me this. If I add some other Z-wave devices will it enhance the coverage?

[stusviews]

If the device is also a repeater, then yes, that will help. Most wired devices are repeaters. No battery powered device is.

[smithlevenson]

Thanks

[vjk]

Riddle me this. If I add some other Z-wave devices will it enhance the coverage?

Unknown, in general case.  From what I observed, if the device/controller does not get an acknowledgement packet within a dozen or so ms, they try relaying a packet through a node that was included in a routing table as a possible retransmission point(an alternative route). Normally, a controller/device try a direct route if possible.  The routing tables are built/rebuilt apparently during the inclusion/"healing" process. 

 

E.g. I have a controller trying to talk to a thermostat.  Normally, they talk directly although the signal is a bit weak due to the distance/obstacles.  On the days, when humidity goes up, the signal becomes weaker and the thermostat tries an alternative two hops route through  an outside switch and another thermostat which is a bit brain dead because as signal strength indicates it would be sufficient to relay just through another thermo without going through the outside switch.  But, as I mentioned  earlier the whole zwave design/implementation is a bit brain dead.

 

So, the upshot is that the fact that you add another device does not necessarily mean that it would improve communication. It may or may not depending on the routing tables that were built during inclusion/"healing" and how smartly the current zwave routing protocol behaves (not much).

[KeviNH]

The whole Z-Wave repeater thing is a real headache.   For door locks there's the additional issue that not all repeaters are secure repeaters, and many devices (e.g. Aeotec multisensor 6) need to be specially joined to participate in secure mode.

 

I had to use an external antenna on the ISY and build a 'chain' of secure repeaters to get the most distant door lock to reliably respond to commands.

 

Whether or not you need a repeater, you can find out only if you know signal strength at various points in your network.  However, the poor excuse for protocol that zwave is does not provide this metric.  I had to build my a diy  sniffer (to get a partial handle on my network) that provides me with RSSI.

Your ideas are intriguing to me. I wish to subscribe to your newsletter.

 

Do you have a link for info on the DIY sniffer for Z-Wave?

[vjk]

Do you have a link for info on the DIY sniffer for Z-Wave?

 

1. Initially, I was motivated by my thermos missing setpoint commands from the controller. Then, as I wrote earlier, one lock added some additional aggravation.

 

The first attempt was to use an RTL SDR USB stick ($20) to intercept zwave packets. It was only a partially successful attempt because  with the RTL I needed to do quite a bit DSP processing since the radio itself was not good enough.  Even so I was losing about 50% of packets which was not terribly useful. There are some published information on the internet if you google for rtl sdr zwave, however, none of them worked for me perhaps because they used a fancier more expensive ($200) SDR such as HackRF.

 

I have some experience with using TI CC1110 chips and decided to try them. When I started writing a simple piece of firmware (gettting a packet and sending what's captured through a serial port to a PC), I found this : https://www.insinuator.net/2015/01/riding-the-z-wave-part-1 which was exactly the same as I was doing hardware-wise. Their firmware did not work for me though because it was written for  European frequency of 868Mhz rather than the US  908.42 Mhz and could not read older 9600 baud zwave gadgets, only 40K ones. So, I finished writing mine which was pretty simple. 

 

So, for hardware I used http://www.ti.com/tool/cc1110dk-mini-868 which buys you two radios and a firmware programmer at $75.  I use one radio for 40K devices and the other for the few remaining 9.6K units.  A radio is attached to a USB port via a 3v3 TTL cable.  I might have used a CC1111 mini kit which is one USB stick that does not require a connecting cable, but at $75 it buys you only one radio and I needed two.

 

2. A lock repeater device does not appear to require secure protocol feature, but rather "beaming" ability.  It means that it should be able to repeat special "beaming" packets to wake up a battery device.  The beaming packed is merely hex "55"+dev id to wake up repeated for about a second about a hundred or so times. According to my traces, for one of my locks a thermostat is a repeating device that retransmits  "beaming" packets to the lock.  The thermostat itself is not a secure device.  In fact,  all the devices in my network except locks communicate in clear text, thus easily spoofable,  which by itself is a major protocol design flaw.