I would like to push back a little on the IoT haters here. I assist in the management of a number of short-term rental homes. The short-term rental industry is enabled in large part because of IoT. For example, we use Wi-Fi enabled digital door locks to provide custom door codes for guests and cleaners. These codes can be managed and monitored remotely.
More specifically, in one trial we implemented the (keyless) Google Nest x Yale Lock [1] - great when it was working, but locksmiths were called on more than one occasion when it was not. Then we had the epiphany to implement the (keyed) Yale Assure Lock Touchscreen with Wi-Fi and Bluetooth [2], which solved that problem giving us the fail normal desired outcome. It was only in talking with Yale tech support that we realized these are virtually the same locks (one keyed / one not), and despite a near absence of technical supporting information, they both worked just as well on Google Home.
I cannot emphasize the fail normal requirement enough with IoT devices, as discussed elsewhere here. We similarly provision a large number of other IoT devices to improve guest experience including Nest thermostats, Nest Protect smoke and CO alarms, Chromecast Google TV, and (outside) Google Nest security cameras/floodlights. Most guests now require these features at a minimum.
I apologize that this reads somewhat as a Google advertisement, and that is one of my problems with IoT and IMHO one of the main reasons for its lack of wider adoption - product lines are proprietary and there are no well-implemented standards for cross-vendor compatibility. For example, Amazon eero wifi nodes cannot be substituted with Google Nest Wifi nodes - they use incompatible proprietary mesh networking technology.
You can implement the features you want for your rental home without the downsides we hate by merely doing end-to-end encrypted communication--and likely even peer-to-peer direct communication (and, if not, using a neutral third party to coordinate rather than the manufacturer)--from your computer to the device in question and requiring manual approval of firmware updates, which should not involve any kind of vendor signature requirement.
The default assumption that the company selling the product should have complete control over the software running on the device at all times, that they should have complete control over usage and access of the device, and that they even should have complete visibility to all of the data collected by the device, is so ridiculous as to be downright egregious: it requires someone who has almost nothing but contempt for users--even if they want to claim they somehow are helping them "for their own good"--to even contemplate such an architecture.
Would I be correct in concluding then that your suggested "end-to-end encrypted communication--and likely even peer-to-peer direct communication ... to the device in question" is simply not possible without individual case-based custom engineering?
> The default assumption ... to even contemplate such an architecture.
At the risk of being further down-voted, I couldn't agree with you more about this last paragraph. Alas my systems integration skills are not up to speed with implementing "end-to-end encrypted communication--and likely even peer-to-peer direct communication ... to the device in question", but I am thrilled to know that can be done. Are you able to cite any such systems/products where that is possible?
More specifically, in one trial we implemented the (keyless) Google Nest x Yale Lock [1] - great when it was working, but locksmiths were called on more than one occasion when it was not. Then we had the epiphany to implement the (keyed) Yale Assure Lock Touchscreen with Wi-Fi and Bluetooth [2], which solved that problem giving us the fail normal desired outcome. It was only in talking with Yale tech support that we realized these are virtually the same locks (one keyed / one not), and despite a near absence of technical supporting information, they both worked just as well on Google Home.
I cannot emphasize the fail normal requirement enough with IoT devices, as discussed elsewhere here. We similarly provision a large number of other IoT devices to improve guest experience including Nest thermostats, Nest Protect smoke and CO alarms, Chromecast Google TV, and (outside) Google Nest security cameras/floodlights. Most guests now require these features at a minimum.
I apologize that this reads somewhat as a Google advertisement, and that is one of my problems with IoT and IMHO one of the main reasons for its lack of wider adoption - product lines are proprietary and there are no well-implemented standards for cross-vendor compatibility. For example, Amazon eero wifi nodes cannot be substituted with Google Nest Wifi nodes - they use incompatible proprietary mesh networking technology.
[1] https://store.google.com/product/nest_x_yale_lock
[2] https://shopyalehome.com/products/yale-assure-lock-touchscre...