That's the assumption and motivation:
> I wanted to create an architecture that minimized future work on both the admin app and the controller network layer. That way, the business could lean on its in-house development experience to make changes after the project.
From your perspective as a UI developer, you would need to update all clients (in the building) if something on the server changes, e.g. if a new button or game state is added. HATEOAS is a good architectural choice if you want to minimise the likelihood of having to change the client implementation.
I use HATEOAS as much as possible in my daily work. It is a good way to think about state, state transitions and what capabilities a client must have. That's the actual part of the author's motivation. It provides the "in-house development" with paradigms how to make changes.
It sounds like there is one client and multiple servers, so I assumed that it would be easier to change the single client versus multiple servers. I guess it also depends on what the in-house developers are experienced with.
But I'm not so sure that it really minimises future work. Like if they decided they want a button that toggles both the sound and lights in a room, that's trivially implemented on the client. Or if they want to reposition a button from the top of a stack to the bottom. My assumption rests on the idea that changing the client is easier though.
"it would be easier to change the single client versus multiple servers" + "trivially implemented on the client" It would be! That said, adding a new feature requires implementing that feature on the server, so requiring an additional change on the client is actually more work.
For example, one of the rooms in the house just installed house lighting to help with resetting rooms between guest groups. One one of the controllers has this.
Once I implemented the hardware logic, I updated the server's state response to include a new button that pointed to a new house lights endpoint. That button immediately showed up in the admin app. Super fun DevEx, and this is what I meant by minimize future work - minimal work to expose new room functionality.
"My assumption rests on the idea that changing the client is easier though" Think about the number of changes required to implement the feature end-to-end. You're right that updating N controller C++ templates for a button is wild, but that's not the entirety of the work. Those controllers already needed to be updated to handle what that button does. Adding the button itself is minimal work (copy-paste, really) in comparison to the feature work.