Welcome to the community! One of the phrases you'll hear in the Neo community is "whiteboard friendly". The idea, and this relates to the "what questions will you ask of this graph", is relationships and the entities that enjoy those relationships are just real things - whether it's people in a social network, machines in a technology network, or just an intense conversation around philosophy/religion/politics, anyone with knowledge about the domain can begin to model on that "whiteboard".
BUT, make sure your model is of the entities and relationships - the "what" in the architecture and not the "how". What Euler discovered in his famous bridge problem, was how powerful graph principles are. But if you just create a spreadsheet in a graph, you'll loose the advantages. If you just put a workflow in a graph, again, you'll probably not uncover the weakness in an established "how".
So, while "device model" is a good attribute, a great architecture will be in designing the relationships in this network such that you can ask your graph questions that offer insights beyond attribution benefits. You might want to study how Neo has addressed physical network clients. There are some good whitepapers.
Just to offer you a hint at the power a graph can offer, in the model @koji shared, just looking at the shortest path between Dev 1 and Execute Config (there are two paths with one being shorter than the other - is that "good", "of interest" - and what about the dead ends in this graph?) begins to show how a graph looks at problem spaces differently. And once you get data into a moving, transactional system, how that data will support centrality (important entities/nodes) and other graph questions whose answers are trivial to calculate in a graph while often impossible or silly complex in a sql model - all this will begin to show you how a graph managing any network, will reap rewards. Maybe, because your "network" is so "physical", you might use metaphors of non-physical networks to expand your creativity. Make sense?
Advice on how to proceed? ...just begin to create an initial graph - remembering you're modeling what's real. The nodes and relationships are NOT abstractions, they are actual entities and relationships. You can adjust as you mature your model.
Oh, and don't forget that a "path" is a form of uniqueness. E.g., in @koji ...Dev 1 -> Set Param. There are 2 paths but are they distinct. Yes in the action, but is that right? Not saying one way or the other, rather showing how one can create a perfectly good model as this is, and yet begin to consider changes without that effort being some monumental task. One can even bring in non-tech folks to think things through.