All the above to explain the initial question further: what is the customers need that device interoperability will address?
I’ll share one perspective around one of the ‘needs’ that come to mind. It relates to the increased number of larger systems as well as PULSE devices being rolled out that either require or gain value by ‘sharing data’ with other devices in the same ecosystem. Whether those are from the same or different manufacturers is somewhat irrelevant to this concern - if you have a pump (with electronics), a separate control system for that pump, and some other solar array ultimately powering the pump, there is some communication between at lease the pump and the control system. Or, imagine a fridge and an SHS in a home, where the SHS communicates ‘something’ about control (both PAYG and non-PAYG) to the fridge. This is a different story from the situation where the market consists only of a bunch of ‘standalone’ devices, where nothing interacts with other devices outside of their own plastic/metal enclosure.
There is the definite possibility of just building ad-hoc, proprietary messaging protocols for these devices that do not interoperable with other devices (even from the same manufacturer). This has a cost in terms of R+D to build something that every industry player now has to build on their own, when really, ‘communicating data between the devices’ by itself probably isn’t a market-differentiating feature. What if there was some way to use a standard reference design that was tested, works for a number of different use cases, and isn’t restricted to those use cases (anyone is free to expand/build upon it without breaking compatibility, to some extent?)
In that case, some industry standards to ‘drop in’ connectivity for the devices saves R+D effort, and increases the possibility of reuse between different product lines (and even potentially manufacturers, given other considerations) in the future. Thats true at the connector level (the ongoing GOGLA discussion I think you referenced), link/transport layer (OpenPaygo Link, for example), and application/presentation data level (Nexus Channel Core, for example).
But the outcome there is specifically reduced R+D, faster time to market, and a platform designed for extensible future feature development (not going to be thrown out and replaced in the next iteration next year, incurring more R+D effort…). The standards probably only get used if they solve the problem, that is, actually save time and effort to let manufacturers get something better to market, faster, without needing to reinvent the wheel every time.
Theres definitely other areas or ways to approach the question (PAYG interoperability between devices, so an end user doesn’t need to enter 5 different keycodes into 5 different devices), or ‘I want to buy a fridge from manufacturer X because it has the features I want, but I like the TV from manufacturer Y, and I want them to work together in some way’, but those are downstream impacts of making it easier for manufacturers to innovate without constraining their development or forcing everyone to invent their own ‘solution’ for the same problem (connecting off-grid devices, similar in some ways to the case you mention around USB - the market doesn’t benefit from having every party go invent their own proprietary interconnection cable and data transfer mechanism between devices - why not standardize it, but in a way that manufacturers can build whatever application they want on top of it?)
(I talk a bit more about this in context in an E4A webinar here, if you want to hear more from that perspective).