Eight Years Into UDMI, Google's Biggest Lesson Is That the Installer Experience Decides Whether a Device Standard Scales
Eight years ago, Google handed Trevor Pering a portfolio of hundreds of buildings and asked him to connect them to the cloud. He came out of computer science and web systems, so the assignment looked routine. "Connecting up lots and lots of things to the cloud, that's pretty easy, we do it all the time," he said at NexusCon 2025. "Why would this be hard?"
It was hard. The answer Pering and his team landed on was UDMI, the Universal Device Management Interface, and their model for it was HTML. They built it as a specification of a boundary rather than a piece of software. "It's not really an API, it's not a library," he said. The design puts a large number of cloud applications above, a large number of device types below, and one choke point between them that standardizes monitoring, control, and security. Pering and his team wanted building applications to stop carrying device-specific logic, the way a mobile game developer does not write separate code for every phone on the market.
Google never implemented the devices itself. The team published the spec, wrote a tool that tests whether a device conforms to it, and pushed the build work onto manufacturers. That part went roughly as planned. Manufacturers were "relatively easy," Pering said, and cloud application developers were easier still, since they already understand web systems.
The group they missed was the system installer. Pering describes them as "the people actually have to go into the building, configure the stuff, configure it, make it all work," and says the tools were "kind of too hard to use" for that job. He calls it the biggest lesson of the whole effort. Most recent UDMI work has gone into installer experience rather than manufacturer or cloud-side tooling.
Standards do not fail in the specification. They fail in the mechanical room, in the hands of whoever shows up with the laptop, and that person is rarely consulted while the spec is being written.
Register for the next Nexus Labs event.
Sign up for the newsletter to get 5 stories like this per week:
Eight years ago, Google handed Trevor Pering a portfolio of hundreds of buildings and asked him to connect them to the cloud. He came out of computer science and web systems, so the assignment looked routine. "Connecting up lots and lots of things to the cloud, that's pretty easy, we do it all the time," he said at NexusCon 2025. "Why would this be hard?"
It was hard. The answer Pering and his team landed on was UDMI, the Universal Device Management Interface, and their model for it was HTML. They built it as a specification of a boundary rather than a piece of software. "It's not really an API, it's not a library," he said. The design puts a large number of cloud applications above, a large number of device types below, and one choke point between them that standardizes monitoring, control, and security. Pering and his team wanted building applications to stop carrying device-specific logic, the way a mobile game developer does not write separate code for every phone on the market.
Google never implemented the devices itself. The team published the spec, wrote a tool that tests whether a device conforms to it, and pushed the build work onto manufacturers. That part went roughly as planned. Manufacturers were "relatively easy," Pering said, and cloud application developers were easier still, since they already understand web systems.
The group they missed was the system installer. Pering describes them as "the people actually have to go into the building, configure the stuff, configure it, make it all work," and says the tools were "kind of too hard to use" for that job. He calls it the biggest lesson of the whole effort. Most recent UDMI work has gone into installer experience rather than manufacturer or cloud-side tooling.
Standards do not fail in the specification. They fail in the mechanical room, in the hands of whoever shows up with the laptop, and that person is rarely consulted while the spec is being written.
Register for the next Nexus Labs event.
Sign up for the newsletter to get 5 stories like this per week:


.webp)

This is a great piece!
I agree.