@kkossev, who has a ton of experience w/drivers & Tuya and mmWave/micro-wave related Zigbee devices has always said that changing drivers won't keep a device connected nor cause it to disconnect (excepting maybe poorly written drivers that cause problems specific to themselves). So I would not depend on a driver change to resolve the Linptech connectivity issues that some of us experience and some don't (even when using the sam drivers). ![]()
All 3 of mine have a regular PIR device in the same room, exclusively for Turn On. Then they both have to be Off to start the timer for actual off.
Same setup here ... All are paired with Iris or Centralite PIR motion sensors. ![]()
I will have to agree with the author, however, after quite some time of trial and error here is what worked for me.
TreatLife wifi presence sensor, 24G mmwave. This one I have mixed reactions. I bought 2, and for nearly a year they sat dormant because I could not get them to work reliabily. Finally a few months ago I picked them up again and found one simply died. The other I struggled with and it just wasn't going to integrate with Hubitat (at least I couldn't find a way forward with it). However, after much monkeying with AI tools, I was able to write a driver in Google Home for it. Now it works reliably and I couldn't be happier with it. I am sad it doesn't integrate with Hubitat, and for that reason (and the driver writing frustration), I won't be buying anymore TreatLife sensors and when this one fails I'll look for a better solution.
Philips Hue Smart Motion Sensor PLUS Thirdreality Zigbee Vibration Sensor. This combination approach of a PIR and vibration sensor works almost 100% flawlessly. I found that the PIR itself was not reliable. For some reason around 80% battery the sensor would start taking naps and not detect motion activity. The vibration sensor also isn't exactly 100% reliable, but by combining them they are close to flawless. Do I wish it was a mmwave and a one sensor approach? Absolutely, especially if I am standing still at the toilet for more than 1 minute the lights will go out. A mmwave would solve that.
I also have the new Thirdreality mmwave sensor just sitting on the shelf because I haven't found a driver for that yet and it'll have to wait until after tax season to get my attention again.
Maybe this is helpful.
Or, just change the Hubitat lighting automation timeout period from 1 minute to 5 minutes.
Those extra 4 minutes of electricity are literally pennies a year in electricity cost.
Just for fun, I just did the math, assuming a 20W LED lighting load, and 5 trips to the bathroom per day, at $0.13/kWh - it works out to about $0.31 per year in added electricity cost. Using a $50 sensor to help save that extra $0.31/year, will eventually break even after approximately 160 years! ![]()
In rooms where I only use PIR motion sensors for lighting automations, I pretty much always use a 10-15 minute timeout to prevent 'sitting in the dark' ;).
In rooms where I use the Aqara FP2 or Aqara FP300 mmWave sensors, I reduce that timeout to about 5 minutes.
Both approaches have kept the complaints from the family to a bare minimum.
Regarding longer time-outs...having been trained from my very early years by my father to always turn off any light not in use, I just can't stand a light that's on very long after the room is empty, regardless of the economics.
One of my favorite parts of automation is automatically turn off the lights that my wife used to continually leave on all over the house. ![]()
Oh, and forgot to note, she will tell me immediately when a light doesn't turn off automatically as quickly as she expected. It was OK for her to leave the lights she wasn't using on for hours, but if one of "those automations" is a little slow in turning off a light, it's a big deal.
![]()
Yes that was my understanding as well. So I will probably just prove AI wrong yet again, I have no idea where it picked up that little tidbit, as that is nothing I have seen mentioned in the community.
If nothing else, seems like a good driver for ES1s either way, though I was happy with the Linptech 24Ghz Presence sensor ES1 driver that I have been using.
Since we don't know exactly why they lock up, anything is worth a shot. Google says they disconnect only when in a weak Zigbee mesh, but I don't think that is the case.
Yeah, that's bogus...I've got a bazillion (that is so a real number!) mains powered Zigbee repeaters evenly sprinkled through the house and the Linptech still used to drop off after a while, and regardless of driver.
This is exactly my current "solution" for the problem.
Now I am using a regular PIR for turning on light(s) as fast as possible plus mmWave for keeping light(s) on with reasonably short timeout (1min). The biggest problem is - which mmWave is the most reliable. I.e. which one will not physically brake after few months (MS600), will not frequently disconnect from the network (MS605), will not periodically freeze (Linptech), will not create bunch of ghosts (FP2). So far SwitchBot BT is a winner but testing timeframe is still very short to come to a solid conclusion.
I said this in the early days of mmW, and it's still true as of right now... I find it telling that no well-respected / big player (Hue, Aeotec, Lutron, etc) has done anything with mmW. Well, yet anyway.
I don't know if that's good or bad, it's just interesting to me that it's true.
I do yield that Inovelli has jumped in, and they're who I trust most in this realm so far. Perhaps other bigger manu's are watching to see how it fares for them ![]()
Hue went with MotionAware and utilizing Zigbee signal interference to check for presence rather than mmW. I found that combining them with a regular Hue Motion Sensor and Hue's Sensor Groups to work extremely well for my needs. It's not quite as accurate as true mmW, but it gets fairly close.
If you only have one thread boarder router, then it's basically just like Zigbee. In this scenario, looks to add Thread plugs and other repeaters. IKEA (https://www.ikea.com/us/en/p/grillplats-plug-smart-70624740/) has some dirt cheap plugs that work really well based on user feedback in Reddit. It's also possible to add your own thread boarder routers and add it to Home Assistant (How to build a Thread 1.4 OpenThread border router | Matter Alpha).
BIG Thanks for the links.
Does this IKEA plug a Thread Repeater (it seems to be a case)?
I may try to add few.
I saw that development board but was lazy to search for ready to go sw.
Apparently the ready to go project exist and I am planning to try it.
Not sure if it would work in your situation, but I have been using the Inovelli Blue mmwave dimmer switch in my bathroom and it is very quick. You can set it up that motion activates the switch directly so the commands never have to go through your hub. This removes a key source of latency. The only problem with this setup is that it prevents any type of rules beyond the presence detection such as time of day controls. You do still have the option to have it be fully controlled by the hub if you want.
My switch is on the same wall as the door and immediately detects when I enter. It also has no issues detecting presence through the glass shower doors.
I have 7 Linptech, 2 in some rooms and use the PIR's like this as well. Always had the occasional lock up. I have a rule that changed the sensitivity every time the central heat and air comes on and that never stopped them from freezing up. Three months ago I put all them on the micro usb switches and cycle them once a week. None have locked up since doin the power cycle (yet)
My post from Oct 25. Still going without an interruption.
"I have four Limptech mmwave sensors. Every few weeks one or two would go on a walkabout. Since they are line powered my solution is a couple of inexpensive small smart Kasa WiFi wall warts that power cycle twice a week at 4 am. Not a single failure in the last couple of years."
Installed Sept, 2023. Tuya Zigbee mmWave sensor driver. @kkossev
I've been doing this for 2 1/2 yrs with inexpensive $9 Kasa WiFi plugs. Local after setup. Power cycle for 60 seconds twice a week at 4am. Set and forget, pretty painless. Have never dropped off since.
My Limptech sensors do the same, but I have narrowed it down (at least in my case) to power flickers. Long enough power flickers bork some of my electronics, turn on my tv, etc. The Limptech also seems to be sensitive to this and stops reporting. When it is working, the health check is pretty reliable, reporting online every 30 minutes. So instead of a weekly reset, I simply have a conditional rule that triggers every 5 minutes to see if the sensor has reported online within the last 40 minutes.
This way, the sensors are only down for a maximum of 45 minutes instead of waiting for the next weekly reset.
I was not doing these periodic resets but people who do this reseting sensors weekly. Since sensor is stable for 2-3 weeks the downtime is basically zero.
Niche to those with the prerequisites, but these Linptech BLE mmW+IR sensors have been very reliable. I have two of them.