Current state of custom device handlers vs built-in ones?

I’m unclear. Should I be using built-in device handlers now under the new app to the max extent possible?

For instance, I have two ceiling motion sensors with a custom handler per this thread and it continues to work fine (and executes in the cloud). But should I be switching to say the built-in SmartSense Motion Sensor?

Thanks!

You will get very different answers to this abd it will all amount to, choice is good, do what works best for you.

For me, I use built in default whenever possible. Why? Local execution mostly. You cannot currently have local execution on a custom DTH.

That said, sometimes you need access to a feature only provided by a custom DTH (for instance RBoys lock handler allowing me to modify the on-lock alarm settings on my Schlage locks…

Your mileage may vary…

5 Likes

I think the easiest way to look at it would be compare functionality v/s speed.

  • Most custom device handlers add more functionality, ability to configure settings and access advanced features at the expense of speed because it runs in the cloud. Sometimes they also offer patches/fixes for firmware detects in devices (this happens more often than you’d think).
  • Local device handlers offer basic functionality but they run faster because they are local.

A good test would be to list what functionality the custom device handler provides v/s the loss of that custom functionality in favor of a faster response.

As classic example: For a motion sensor which triggers your lighting automation, response time/speed is important (and you’re willing to forego the ability to configure the sensitivity of the sensor), local execution would be ideal. On the other hand, for a lock or thermostat, it may be more important to access those advanced features/settings and having it respond 1-2 seconds later is acceptable.

4 Likes

Thank you for that great explanation!

1 Like