Curious about this entry in the .131 release notes...
New Devices
- Linptech Human Presence Sensor
Does this mean there should now be a native driver available for this device (I didn't see one), or does it mean something else?
6 Likes
I didn't even check, just ordered one! 
2 Likes
Yes...
2 Likes
Updated to .131
Under what name is it listed? because I can't find it.
1 Like
Sorry for the false alarm. There was an issue loading the driver. We are working on a follow-up update.
Update: the driver is now available in 2.3.8.132.
5 Likes
Nooooo....
Meh, there's no rush.
Order Confirmation
Arriving: Wednesday, March 27
1 Like
Out now in .132. Well, hopefully anyway, downloading now!
1 Like
A quick test says it's working. Much faster turn-off time than the community driver - not sure yet if that's good or bad, but happy to see how it plays out in upcoming days here - thanks!
ETA -- subsequent testing is not going great... it's consistently going inactive when it shouldn't be. Have tried unplugging for ~30", but behavior persists. Going back to community driver to verify performance difference.
ETA2 -- back to expected performance with community driver. I'll keep an eye out for others' experience with the new native driver; I'm curious if other folks have better luck with it.
ETA3 -- I am an idiot, and left the native driver's Motion Retrigger too low (10" is no bueno)... Now experimenting with that at a higher value, and performance much improved! Will continue monitoring...
3 Likes
I was hoping for an option to disable the blue LED, but no such luck.
(I'm already using black electrical tape over the LED, but I'd prefer a more elegant solution.)
That requires a firmware update - not sure if HE staff is in contact with the manu for that kind of thing.
My elegant solution is white electrical tape 
5 Likes
I agree, this new driver has some performance issues. I wonder if it's a distance problem. I have to get really close to the sensor for it to activate even when set to 20 feet.
Beyond that I get frustrated when the built in drivers don't take advantage of all the device capabilities. The device reports the current distance. It's not going to be very useful in very many scenarios. But it's there and there's not going to be any time when it's going to be easier to add than when the driver is first developed. The same for presence/existence time. The light indicator just needs to be added to the driver, it can be ignored if the device firmware has not been updated.
1 Like
That's where the power of this community comes in. For all the capabilities and more, there is often a custom driver to suit your needs.
4 Likes
I'm sorry, but I completely disagree. In creating the driver from scratch you've done almost all the work, the marginal effort for a couple features is close to zero. Why not do the rest? Especially for the sensor you noted as best of the year. As you know, community drivers can be a double edged sword. First, there has to be someone to do the work, and second the work has to be high enough quality. In fact, if I were prioritizing your work effort I'd go through the existing drivers and look for opportunities to build them out. There are several that could use a little TLC.
Are you disagreeing with the fact that community has the power to build drivers that include additional capabilities, or that you can often find a custom driver to suit your needs? I didn't argue against your earlier point that the built-in drivers don't always cover all capabilities. That is true.
If you'd like to propose an enhancement to a built-in driver, we have a dedicated category for that: Feature Requests - Hubitat. I suggest creating a post for future consideration, for any drivers you'd like to see further development.
No, I think community integrations are great. I rely on them extensively. Having said that, time moves on. Hubitat is not the same as it was in 2018. The company has more resources. The products controllable by Hubitat have proliferated in both number and capabilities. Look at the development of something seemingly simple as Windows Explorer. As far back as at least Windows 3.1 3rd party devs came up with lots of good ideas in either plug-ins or alternative apps. And then Microsoft went on to add those same features directly to its core product. Making the core more capable added value for customers in both $ and lower complexity. I think there would be value for Hubitat to follow a similar path of extending built-in drivers to take advantage of a fuller set of device features.
My point on this specific driver is the marginal cost of being feature complete at time of release would have been minimal. There are already 2 community drivers for the sensor that have 2 of the 3 features not part of the built-in driver. Hubitat sees some value to having a built-in driver; why would it be less capable than existing drivers? (I do appreciate Hubitat's standard lux reporting algorithms that community drivers don't seem to replicate.)
Overall I think Hubitat does a good job of managing the core vs. 3rd party developer relationship. It's a balancing act. An example of a company that does a not very good job is Control4. They over-rely on 3rd party non-AV driver developers. And almost all of the drivers are paid products. (The IFTTT driver is $90 MSRP, an app similar to Room Lighting is $60, etc.) One result, IMO, is that C4 have let their system stagnate on features.
Odd, I would prioritize adding new devices.
1 Like
There are many factors considered when adding a built-in driver. I can think of a few that may surpass the development effort:
- capabilities must be documented by the manufacturer.
- capabilities must be part of the protocol the device uses.
- capabilities must meet internal reliability requirements.
4 Likes
I’m guessing this is the zigbee sensor. Is the WiFi version of this sensor also supported in Hubitat? I think I’d prefer that version if it’s supported.
This is about the zigbee version, yes. The wifi version is not supported.
