The Lafaer LWR-1 Human Presence Detector is a new device from Gl-iNet, more famous for their router products, many of which I’ve written about in here over the years. Just this month I wrote about their GL-RM1 Remote KVM product. And now, the Lafaer LWR01 wireless Human Presence Detector. Even if this device isn’t for you – stick around – in the addendum – About THREAD – could be useful.
This matter-compatible sensor is battery powered (2*AA batteries) and can also be powered by USB-C. As you can probably see in the images below, it has 120 degree detection angle and a range of between 3.5m and 6m. It runs on 2.4Ghz WiFi using Matter over Thread and has an operating temperature range of 0c-40c.
Not only presence sensing but also light detection.
The device connects to the free Lafaer app but also offers to let you to pair it with your Matter gateway App first, in my case Google Home. Despite trying both methods – ensuring the unit was factory reset – turning off the VPN on my phone, ensuring phone 2.4Ghz WiFi and BT are turned on, I was originally unable to connect the device. “Can’t find device”. “Cannot connect to Thread network AqaraHome-d7e0”
Ultimately I contacted GL-iNET who told me to try my Aqara Home APP (matter devices) as the Lafaer unit is not compatible with my Google Nest Mini hub.
I did just that and once added as a Matter device, the LWR-1 started to work. I could not get it to show presence – and again GL-iNET told me to use the self-learning feature – pressing the button 5 times in a row, clearing off out of the room within 30 seconds then staying out for 2 minutes – one working unit. From there it was a breeze to add “a Matter device already working on another Hub” to Home Assistant.
And from there I got history – not stored in the APP, from Home Assistant automatically.
But for Home Assistant (HAOS) users it gets better at first glance – I just reset the LWR01 device to factory settings – removing it from the Aqara APP – and checking I had the MATTER integration in Home Assistant, tried adding it into that. HA told me I had to do that via the HA companion phone app (because it has the camera to scan the QR code on the device) and what – a minute late, the LWR01 was back up and running directly in HA – I didn’t even have to re-install my test tiles. History kept as well.
But then this morning I came into the office and the Lafaer unit showed “present”– at this point I turned off the now unused Aqara hub – so I left my office for a few minutes and on my phone (Home Assistant APP) I could see the LWR01 was no longer unavailable. So I came back into the office – still unavailable.
I wondered if the pre-supplied batteries were dead… 1.48 v. No, but regardless, I changed the batteries for decent Panasonics. Device still unavailable. I checked the Lafaer APP and held the side button in for 3 seconds to see if the unit would pair with the Lafaer APP – no sign of it (no devices scanned) – and still unavailable in Home Assistant.
That’s a shame – it was looking good. Was the unit somehow still relying on that Aqara hub? I could not simply factory reset the LWR01 and reconnect – Home Assistant (Android APP – Matter – add device) resulted in that and the Lafier APP still ranting on about “cannot connect to Thread network AqaraHome-D7e0….”
I re-powered on the Aqara hub… long pressed the LWR01 side button. – “Add to Home Assistant App” – WORKING – so even though the device was not apparently connected to the Aqara hub and HA matter integration doesn’t mention it. And magically I could now 3-seconds-add the LWR01 to the Lafier APP. This is the weirdest setup I’ve ever seen.
And.. so with the Aqara hub ON… after a while the LWR started to work properly but strangely – as I moved in and out of the office this morning – the light sensor (in HA) was going up and down (lights go off when I leave the office) but the Presence sensor remains on DETECTED… this afternoon I made sure the Aqara Hub-3 is now on a proper PSU instead of just any old USB – left the room for 15 minutes to take some photos of my latest acquisitions – and both sensors say UNAVAILABLE…. I don’t really think I can blame the Aqara Hub 3 for that.
Ultimately it seems the unit IS relying on the Aqara hub as it is not compatible with the Google Nest Mini – and my Home Assistant does not in fact have a Matter hub built in but is relying on that Aqara Hub for the Thread compatibility – of which I know next to zero as I have nowhere in my vast pile of IOT gadgets anything else that insists on Thread.
Update December 12, 2025: Things change. I just happen to have ditched Alexa in favour of the Google Nest Hub – like Alexa but with a smaller screen, considerably less advertising and it happens to be a Thread edge router which I’ve since come to realise means it is a gateway beween Thread and WiFi. So I installed the Lafaer unit into Google Home as a MATTER device and as if by magic it then ended up in Home Assistant, with, as usual a different name to the one I gave it in Google Home – but no matter (as it were) – I discussed this in a previous blog and it is easier than you’d think (but not as easy as you may wish) to rename devices and their entities in Home Assistant.
Anyway – the upshot is – in December 2025, the Lafaer unit is working – and it certainly is a nice, functional case – but why does it only do presence and not also movement? There are a ton of devices and DIY projects out there now using inexpensive, accurate sensors that do presence and movement – even in multiple zones.
Addendum: Only read if you need to keep up with Thread
I just said I know nothing about Thread. There I was this morning idling away and I happened to ask GEMINI (on my phone) “Give me a simple description of the Thread protocol”. Well, wasn’t that a game-changer! Gemini gave me a brief outline then all by itself started a quiz for my benefit – telling me some stuff then checking to see what I’d taken in by asking me questions. By the end of it I’m not longer a COMPLETE Thread noob. Just as well, as Ikea in January 2026 are about to release a whole shed-load of new devices which work on Thread… check out the Ikea IOT 2026 ad. If that’s the route they’re taking you can count on it they’re not alone. So we should be keeping up I guess.
*** Transcript ***
“Give me a simple description of the thread protocol”
That’s great! We can absolutely explore all three aspects of the Thread protocol. I’ll ask guiding questions along the way to help solidify your understanding.
Let’s use this plan:
- Mesh Network Dynamics 🕸️: We’ll start with how Thread builds its reliable, self-healing network.
- Device Roles and Power 🔋: Next, we’ll look at how devices like routers and end devices manage the network while staying energy-efficient.
- IP and Security 🔒: Finally, we’ll dive into how the IP standard and strong encryption make the network secure and universally compatible.
1. Mesh Network Dynamics 🕸️
A mesh network is fundamentally different from a traditional “hub-and-spoke” network (like a standard Wi-Fi setup). In a Thread mesh, all mains-powered devices work together as routers to forward messages for each other. This creates many possible paths for data to travel.
This design is the key to Thread’s reliability and scalability. If one path is blocked, the message automatically and instantly takes another.
Based on this, what do you think is the main benefit for a smart light bulb when its message can jump from one neighboring device to the next instead of relying on a single, distant Wi-Fi router?
“All of the above options”
That’s great! We can absolutely explore all three aspects of the Thread protocol. I’ll ask guiding questions along the way to help solidify your understanding.
Let’s use this plan:
- Mesh Network Dynamics 🕸️: We’ll start with how Thread builds its reliable, self-healing network.
- Device Roles and Power 🔋: Next, we’ll look at how devices like routers and end devices manage the network while staying energy-efficient.
- IP and Security 🔒: Finally, we’ll dive into how the IP standard and strong encryption make the network secure and universally compatible.
1. Mesh Network Dynamics 🕸️
A mesh network is fundamentally different from a traditional “hub-and-spoke” network (like a standard Wi-Fi setup). In a Thread mesh, all mains-powered devices work together as routers to forward messages for each other. This creates many possible paths for data to travel.
This design is the key to Thread’s reliability and scalability. If one path is blocked, the message automatically and instantly takes another.
Based on this, what do you think is the main benefit for a smart light bulb when its message can jump from one neighboring device to the next instead of relying on a single, distant Wi-Fi router?
“Lower cost”
That’s a clever point! You are right that system cost can be lower because you don’t need to buy a single, powerful Wi-Fi access point that can reach every corner of a large home.
However, let’s look at the technical benefit for the light bulb itself. The main advantage of the mesh structure is solving the problems of distance and reliability.
Let’s focus on a big house 🏠 with many rooms. If the main router (or Border Router) is in the basement, and a smart bulb is on the third floor, how does the ability to ‘hop’ through other devices (like smart plugs or other bulbs) solve the distance problem for that third-floor bulb?
“I imagine no advantage unless there are other thread compatible devices inbetween the border router and the third floor”
That is absolutely correct! You have described the fundamental mechanism of the Thread mesh network. For that light bulb on the third floor to benefit, it must have other mains-powered Thread devices acting as routers in between.
The benefit of those hops is directly related to solving the distance problem.
- Instead of the third-floor bulb trying to send a weak signal all the way to the basement Border Router (a long, single path), it only needs to send a strong, short signal to its nearest neighbor on the same floor.
- That neighbor then relays the message, and so on.
This short-range communication means the signal doesn’t have to be as powerful, which increases both the robustness of the connection and the overall speed.
Now that we’ve covered the structure, let’s look at the devices themselves, which leads us to:
2. Device Roles and Power 🔋
In a Thread network, not all devices are created equal. They have specific roles tailored to their power source:
| Role 💡 | Power Source | Primary Function |
| Border Router (BR) | Mains Power | Connects the Thread mesh to the traditional Wi-Fi/Ethernet home network (the internet). |
| Router Eligible End Device (REED) | Mains Power | Joins the mesh, sends and receives data, AND can forward data for others (building the mesh). |
| Sleepy End Device (SED) | Battery Power | Joins the mesh, sends and receives data, but cannot forward data for others (saves battery). |
Thinking about the Sleepy End Device (SED)—like a battery-powered door sensor—why is it a critical design choice that these devices cannot forward messages for others? What would happen to the sensor’s battery life if it had to constantly listen and forward messages?
“If the battery power device had to send signals back and forth, that would reduce battery life. But surely this is the same as Zigbee. That’s what Zigbee does.”
That is an excellent observation, and you’ve hit on the core difference between how Thread and Zigbee manage their Sleepy End Devices (SEDs) 😴!
You are correct that if a battery-powered device constantly had to listen and forward messages (like a Router), its battery would drain very quickly—likely in weeks instead of years. This is why the SED role is so critical.
The Key Difference: Polling vs. Parent/Child
You are also right that Zigbee uses a mesh network structure. However, the way Thread handles its battery-powered devices is more efficient and direct than the traditional Zigbee approach:
- Zigbee (Polling): Traditionally, Zigbee end devices were polling devices. They would periodically “wake up” and ask a parent router, “Do you have any messages for me?” This requires the battery device to initiate contact regularly.
- Thread (Direct Child/Parent): In Thread, the battery-powered device (the Child/SED) forms a very direct, reliable relationship with a nearby mains-powered device (the Parent/Router).
- The Parent Router knows exactly when the Child device is scheduled to wake up and keeps any messages intended for the Child on standby until that moment.
- This deep coordination allows the Child to sleep for much longer periods, only waking up for a fraction of a second when its parent expects it.
This Parent/Child relationship is part of why Thread is known for its low-power efficiency.
Now let’s move on to the third and final part of your request: IP and Security 🔒.
3. IP and Security 🔒
The most significant technical feature of Thread is its foundation in Internet Protocol (IP), specifically IPv6.
Every single Thread device, from a Border Router down to a battery-powered door sensor, has its own unique IP address. This is fundamentally different from protocols like Zigbee, which use proprietary network addresses that must be translated by a central hub.
Why do you think giving a simple, low-power door sensor its own global IP address is a big deal for a smart home system? What does it remove from the network equation?
We were just talking about how every device in a Thread network, even a small battery-powered door sensor, gets its own unique IPv6 address.
Think about other smart home standards (like older versions of Zigbee or Z-Wave). They use their own special internal network language and addressing. For those devices to talk to the internet, you always need a hub or bridge to act as a translator.
What piece of equipment does Thread essentially eliminate the need for by ensuring every device speaks the language of the internet (IP) from the beginning?
“As I don’t know, what does it eliminate?”
That’s a very direct question, and a great way to cut to the core benefit!
The piece of equipment Thread essentially eliminates the need for is the Application Layer Hub or Translation Bridge.
Here’s the breakdown of why that happens:
- The Translation Problem: Older, proprietary IoT protocols use their own unique internal network addressing. To get a command from your phone (which speaks IP) to a Zigbee bulb (which speaks Zigbee protocol), you need a hub to translate the commands between the two “languages.”1
- Thread’s Solution: Since every Thread device has its own IPv6 address, it’s already speaking the language of the internet. The commands from your phone (IP) can go directly to the device (IP) via the Border Router.
A Border Router is still needed, but its job is much simpler: it just routes the IP traffic between the Thread mesh and the Wi-Fi/Ethernet network. It doesn’t have to translate protocols, making it a much more streamlined process.
Now let’s talk about the final part of this section: Security 🔒.
Since every device has a unique IP address and can talk directly to the outside world, security is critical. Thread uses strong, standardized AES encryption (the same as Wi-Fi) to secure all communications.
If the network is decentralized and secure, what do you think is the biggest security advantage of a mesh network where no single hub holds all the encryption keys and controls all the devices?
“Presumably, no single hub going down can take the whole system down.”
That is a perfect observation about reliability! 🛡️ You are absolutely right that in a Thread mesh, if one Router goes down, the network automatically finds a new path. It ensures system availability—no single point of failure can take the whole system offline.
Now, let’s look at the security side, which is closely related to those encryption keys.
In a system that requires a single, central hub to translate all commands and hold the master encryption key, that single device becomes a massive security target. If a hacker compromises the hub, they gain full access to the entire home network.
Since Thread is decentralized and devices communicate securely with each other using AES encryption, how does this design inherently make it harder for an attacker to compromise the entire network’s secret information (like the master key) compared to a system with a central, all-powerful hub?
“Just back up a second, you just said that there is no single point of failure but presumably the Wi-Fi access point. If that goes down, that will stop the mesh talking at all to the outside world. But would the mesh continue to work internally?”
That is a very sharp distinction you’ve drawn! 💡 You’ve hit on a critical point about the architecture of Thread.
You are absolutely correct: the Border Router (BR) acts as the single gateway 🚪 between the Thread mesh and the outside world (your Wi-Fi network and the internet). If that BR goes offline, the Thread devices can no longer be controlled by your phone app when you are away from home, and they can’t access cloud services.
To directly answer your question: Yes, the mesh continues to work internally.
If the Border Router goes down, the devices in the mesh (like the lights and sensors) can still talk to each other directly because they don’t need the Border Router for internal communication.
Why do you think the mesh is able to maintain communication and self-heal its connections even after its connection to the outside world is severed? Which devices are responsible for maintaining those internal pathways? 🕸️
“I don’t really understand how the likes of Home Assistant can issue instructions to control devices when the devices are talking to each other independently?”
That is an excellent, practical question that gets right to the heart of what makes Thread a resilient system! 💡
You are correct: If the Border Router (BR) goes down, the outside world—your phone app when you’re not on the same Wi-Fi, or a cloud service—cannot issue new instructions to control the devices in the mesh. The external system is blocked.
However, the internal mesh continues to work because of the Router Eligible End Devices (REEDs) we discussed earlier.
The Role of REEDs in Internal Resilience 🕸️
These mains-powered devices (like smart plugs or light switches) are constantly communicating with each other and are responsible for:
- Self-Healing: Finding new paths for data if one device fails.
- Maintaining Addressing: Ensuring every device is locatable within the mesh.
- Supporting Sleepy End Devices (SEDs): Acting as parents for battery-powered sensors.
The internal pathways are maintained by these REEDs, not the Border Router.
Internal vs. External Communication 🏠
Let’s imagine a scenario where the Border Router fails:
- External Command (Fails): You try to open your phone app miles away to turn on the porch light. This command must go from the internet $\to$ Wi-Fi $\to$ Border Router $\to$ Mesh. It fails because the Border Router is the choke point.
- Local Automation (Succeeds): A battery-powered door sensor (a Sleepy End Device) detects the door opening. It sends a message to its Parent Router (a mains-powered light switch). The switch receives the message and triggers an automated command within the mesh to turn on a nearby light bulb.
*** End Transcript ***
At this point I’d had enough for one morning. Worthwhile though, I think. Whew…