Disclaimer. I have no in-depth knowledge of the Zigbee pairing process and am hoping to chat with a developer who can confirm if this is possible.
Putting aside for a moment what functionality Hubitat delivers at present. Is it even technically possible to remotely pair a Zigbee sensor without physically being near the hub/receiver? i.e. back at the office, can I put the sensor in pair mode and sniff the key and then somehow update the hub remotely to use the key for this new sensor?
Assumption there that Zigbee pairing involves some kind of private key exchange allowing the hub to authenticate and decrypt Zigbee messages.
Backstory,
We are sending out a trial of a simple Hubitat/Zigbee based system to be installed by customers in their homes. We pair the zigbee sensors to the hub before mailing them out. We have VPN access to each hub and the hub is black box to a customer.
We are considering what's involved for a customer in the rare case when a Zigbee sensor fails. We cannot physically go to the customers home. The ideal would be to send out a pre-paired sensor in the mail and the customer replaces the sensor. At the moment it's a support call with the customer instructing them on how to put the sensor into pair mode whilst we VPN to their hub and put the hub in pair mode. Not great.
A plan B is to pair a couple of extra sensors we keep in reserve at the office for each hub before sending them out to a customer. Also not great.
We've modified the sensors to use AA batteries rather than CR2032s for extended life. We communicate the battery levels to the customer. We feel changing a couple of AA batteries every few years is fairly easy for a customer. No access to the hub is required, no customer support call required, etc.
We are currently using the Sonoff sensors which can be a little fiddly to pair and would prefer to save the customer the hassle.
i also have the same/similar query.
thinking out loud:
we send out the device to the user, and also send an email with replacement instructions. the pairing step contains a URL for the user to click during the process. this URL is a "Cloud End Point" trigger.
The trigger runs an (already-provisioned) RM5 rule, which puts the hub into pairing mode.
Question for @bravenel and team:
is there an RM5 action (or method) to instigate pairing mode using a cloud trigger?
OR, if I wrote an app, assuming I can subscribe the app to a Cloud End Point event, is there a built-in method to invoke Pairing mode?
Thanks for this. I was not aware of SmartStart. It sounds like there are other challenges there as the device doesn't get created and become available to our various groovy apps until it's powered up and fully included. SmartStart sensors would certainly be easier for the customer in that they would just have to pull a plastic battery tab to power up the sensor and it automatically includes.
The second part after a new sensor is sent out to a customer and included involves an admin naming the new device and configuring our various groovy apps to subscribe to events for that new sensor. Unless I can figure out a way to automate that last step I'm still up for a call to the customer to coordinate that.
Hmmm, I've already developed a driver app app that streams our hub logs to a central cloud db. I wonder if there is anything in the logs that would tell me a new device has been added... We could write an alert server side to ping an admin an email or SMS when the new device has been added to the hub, then our admin can VPN into the hub and manually update the config of the groovy apps without bothering a customer...
Any plan to put the Z-Wave tools into the hub web portal? That would allow me to manually enter the DSK for a SmartStart Z-Wave sensor via the portal rather than using the mobile app.
No, there aren't plans to do that. This subject you guys are discussing is more complex than meets the eye. Remote provisioning of Z-Wave or Zigbee devices is unlikely to work in the real world, as things just don't go that smoothly all of the time. So dealing with exceptions becomes the hurdle, and sending out devices to customers with an expectation that they will just get connected is not the way to plan this out.
