Hi everybody!
I am looking for a signal repeater for Schlage LiNK but I could not see any online shop selling Schlage LiNK lamp module.
May you guys suggest anythings are used as signal repeater please? Thank you.
As of now I beleve the lamp module is the only thing that will repeat the siginal for the locks because of the encryption used to secure the signal.
To Reiserx: Do you know where Schlage LiNK lamp module is sold separately? Thank you.
It is not on the site yet, but we have ccess to it.
Thank you,
I just bought mine at the local Lowe’s home improvement store. Or here: http://www.lowes.com/lowes/lkn?action=productDetail&productId=380-352-RP200R&lpage=none
If I might add a correction.
It is not the encryption that is being repeted. The issue is with wakeing up a device like the schlage lock as it is trying to save battery power. This is called the " beam". Only the last Zwave device in the route to the lock needs to support the “beam”.
currently the Schalge branded plug in module can do the beam as well as the Trane thermostat. New production of the ACT products will or may have the beam. Check with them as they publish the version number in their documents. Act makes the module for Schlage. It is my understanding it needs to have a firmware 3.0 and later.
good luck
This answers SO many questions! If this information is in the Schlage lock Wiki, I missed it. I’ve been wondering why my lock wasn’t getting commands, with a functioning Z-wave wall switch 12" away, yet when I disassemble everything to troubleshoot and bring it inside, it works flawlessly! So, I guess I’ll be picking up a Schlage lamp module, too…
I wish the HSM100 sensors supported receiving a “beam”, i hate waking them up manually 
beam is a battery savings protocol. Not really a wake-up
if you want to know more about it look here
http://www.zen-sys.com/modules/iaCM-DocMan/?docId=12&mode=DE
create user name
Here is some of the text
5 ZENSOR NET BASICS
In a classic Z-Wave network, the receiving node must be always listening. In order to support
communication to battery-operated receiving nodes, a fundamentally different philosophy must be
applied.
A Zensor Net is a network of battery-operated nodes that are able to operate for months or even years
on the same battery, yet they are still able to communicate internally or via some master node.
5.1 The Zensor Net node
Certain applications (e.g. networked smoke alarms) have a hard requirement for robust, autonomous
operation. During network configuration, it may be acceptable to have some centralistic approach, but
operation must be 100% mesh oriented. Any subset of nodes breaking down must not cause the
remaining nodes to loose contact to each other. For this purpose, Zensor Net nodes are able to forward
broadcasted frames under certain conditions. This is covered in section 6.3.
In order to achieve a long battery life, Zensor Net nodes must be sleeping most of the time; only waking
up for very short periods listening for traffic before they go back to sleep.
The challenge in a Zensor Net is to get in contact with a node that only listens for a very short time now
and then.
5.2 The Beam
The solution for reaching sleeping nodes is to introduce a “Beam”; a long preamble saying: “I have
something for you, please hold the line”. The real frame then follows just after the beam.
Receiver wakes up just
after start of beam
Destination
Source
Figure 5. Reception timing when sending beams
In average, a listening node will detect the beam halfway through the beam.
There are multiple purposes of the beam:
-
It makes sure that a battery node detects that data is ready for it when the node actually wakes
up.
By making the beam (slightly longer than) the length of the wake-up interval, the node will always
wake up somewhere inside the beam. -
The wake-up time is completely asynchronous and the precision of the wake-up timer is so
limited that after 1 minute, the wake-up time may have drifted almost one second away from the
nominal wake-up time.
Thus, a management system trying to read sensors will have no knowledge of the next expected
wake-up time of a node that is read out at a rate lower than once per minute – which is the case
for most battery sensor systems. -
Without the beam, one could send out a high number of copies of the same frame from the
application layer until an acknowledgement is received.
This strategy has two problems:
First, the listening node would have to be awake for a longer duration to detect the frame.
Second, there would be small pauses between the frames forcing the listening node to be awake
for an even longer duration and even worse, there would be a risk that other nodes could send a
frame in just that critical period where the listening node was awake and listening.
In Z-Wave v5.0, there is support for wake-up intervals of 250msec and 1000msec.
As mentioned above, one of the purposes of the beam is to block the air, ensuring that no other nodes
disturb this attempt to reach a Zensor node.
Blocking the air inevitably affects latency, command response times and ultimately end-user experience.
Everybody having tried satellite telephony or bad graphical user interfaces knows that a half second
delay from action to response is confusing and highly unsatisfactory. It is a known fact inside the telecom
industry that the limit is somewhere around 300ms.
The 250msec wake-up interval stays below the 300msec limit. Actually, it is the absolute worst case
delay cased by the beam that is 250msec. In average, it is 125msec, which hardly will be noticed at all by
normal users turning a lamp on or off. Applications benefiting from the 250msec wake-up interval are
battery-operated nodes such as wireless doorbell systems and wireless motion alarms, where low
latency is critical.
The 1000msec wake-up interval is well beyond the 300msec limit and is not intended for use in Z-Wave
environments during normal operation. The only application addressed by the 1000msec interval is a
system of networked smoke alarms with a requirement for very long battery lifetime and moderate
response times. The philosophy is that an emergency situation like a fire in the building is an extreme
situation where longer response times are not an issue. The important part is that all alarms get started.
Zensor Net functionality is implemented as a backwards compatible extension to the classic Z-Wave
protocol. Power information (battery / AC) and beam speed are taken into account when creating routes
so that battery-operated nodes are not used as repeaters (existing Z-Wave feature) and so that a
battery-operated node sending a frame takes into account the mode of the receiving node, as well as any
repeaters used to reach the destination.
Just bought one on Amazon-I sure hope this fixes my lock issues 
Lot of mention of smoke detectors in that. I sure hope that someone is coming out with one soon that is hard wired power, battery backup, and most importantly zwave.
I heard the issue is insurance and laibility for the reason not implemented yet.
Until there is a bullet proof controller nobody in their right mind left of insanity would sell a Zwave Smoke detector.
My only issue with that, is there’s no reason to not make it work standalone just like the cheap ones you can get. Just aggravating, I would really like to be able to get one one of these days.
Here is my current situation the the Schlage lock:
It appears to work fine at times, but at other times there are polling and command failures. I am assuming that the lock is sleeping and I only have the Wayne Dalton T-stat that does not have the “beam.”
I just purchased the lamp module and will be installing it this weekend.
Will this fix the issue and wake-up the sleeping Schlage for my commands?