Article
News
3
min read
Brad Bonavida

Eight Years Into UDMI, Google's Biggest Lesson Is That the Installer Experience Decides Whether a Device Standard Scales

August 3, 2026

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.

Watch the full recording.

Register for the next Nexus Labs event.

Sign up for the newsletter to get 5 stories like this per week:

Sign Up for Access or Log In to Continue Viewing

Sign Up for Access or Log In to Continue Viewing

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.

Watch the full recording.

Register for the next Nexus Labs event.

Sign up for the newsletter to get 5 stories like this per week:

⭐️ Pro Article

Sign Up for Access or Log In to View

⭐️ Pro Article

Sign Up for Access or Log In to View

Are you interested in joining us at NexusCon 2026? Register now so you don’t miss out!

Join Today

Are you a Nexus Pro member yet? Join now to get access to our community of 600+ members.

Join Today

Have you taken our Smart Building Strategist Course yet? Sign up to get access to our courses platform.

Enroll Now
Conversation
Comments (-)
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Guest
6 hours ago
Delete

This is a great piece!

REPLYCANCEL
or register to comment as a member
POST REPLY
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Guest
6 hours ago
Delete

I agree.

REPLYCANCEL
or register to comment as a member
POST REPLY
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Get the renowned Nexus Newsletter

Access the Nexus Community

Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.

Go to Nexus Connect

Upgrade to Nexus Pro

Join Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.

Sign Up