"System.Device.Model - attributes for device bindings" progression

[logicaloud]

The approach of adding attributes to devices for plug-and-play scenarios sounds like a good idea. It has not progressed much recently and many devices don't seem to use the attributes that are already defined.

Are there any plans for this to be pushed further?

Or has this been moved to a different package elsewhere?

Or are there any insights that indicate that such an approach is not flexible enough?

[krwq]

Hello @logicaloud - yes but it's unofficial, I'm driving that project on the side but progress is rather slow because I don't actively work on that (I usually spend a bit of time on that once every couple of weeks). Current goals are following:

• create representation of those devices which can be generated using attributes (model)
  • there is some progress but it's not happening publicly (there is no particular reason for not being public other than the fact that we don't want to commit to specific design just yet and we don't want people to start depending on it yet while we haven't proven design for ourselves - it's in early alpha stage)
  • our first goal was to create end to end prototype which can generate couple of things using these attributes:
    • DTDL2 file (for Azure PnP)
    • entire console app which reads data and sends it somehwere (input is full class name you'd want the code to be generated for and references for finding that class if needed) - app can be used as a template for further development but if device has parameterless ctor it will work out of the box, otherwise you need to modify one file to create your main class instance - currently it automatically collects data periodically and sends it to Azure Iot Hub but code is designed such that it can be changed relatively easily
    • entire library for reading this data using Rx - input is DTDL2 file
  • now we're prototyping library which can read the attributes and give you the model of those devices - we're playing around with various designs to see what makes most sense
• while designing model we did some clean up of attributes and we plan investigation if it's possible to reuse i.e. ComponentModel.Annotations instead of our own attributes

basically the largest problems we stumbled upon is that device components (i.e. SenseHat contains: thermometers, accelerometer etc.) are independent from their connection and we need a good way to represent that. We're currently trying to create abstraction which will allow us to reuse that in both our project (so we need to change our prototype generator to use that library) and we're working with folks who designed https://github.com/pi-top/pi-top-4-.NET-SDK because they have similar problem - we're trying to create something which will work for both of our projects.

Some other problems we found:

• how frequently should data be send
• generating app is not ideal approach - changing model would require regeneration which will be problematic - library would be much better but designing it is much harder than prototype

cc: @colombod

[krwq]

ref: #2074 - note that we've slightly shifted from "this needs to be Azure PnP" toward "we prefer more generic solution" - prorotype is still using Azure PnP though

[logicaloud]

Hi @krwq, Thank you for the detailed response.

It is still a while before I can do more research into this topic and I would be very much in favor of a device model that is generic and independent from Azure PnP (which does not preclude targeting it separately, I presume).

In my simple mind, I had envisioned that .NET itself becomes the definition language for this project and all devices can be loaded dynamically and explored using .NET reflection (by applications developed outside of this project). Defined attributes would guide an application to the relevant types and methods, which may be device factories, properties, telemetry, commands, and so forth, and the application could then expose a generic user interface for device configuration and operation, transfer specific data to a cloud IoT provider, or convert device information into a different format (like DTDL). Having a .NET assembly for a device module dropped into a folder for a generic application should be enough to make the device usable. More specialized applications could restrict themselves to deal with some specific device category only, of course.

What you are describing seems to already aim a bit higher and includes developing applications consuming the device model attributes, i.e., applications that generate device representations, solve how device connections should be handled, or how often data should be sent, correct?

The scope that I had envisioned for the project would simply specify attributes and their meanings, sufficient to define the behavior for a large number of devices, including the problem cases you have mentions. If the goal is to create applications, then maybe these applications can be separated out? From my point of view, the project can stand on its own by just specifying the "right attributes", because all kinds of applications can be based on that separately. At the same time I see that development of an application is needed to proof that attribute specifications are sufficient (that can serve as an example).

I may be misunderstanding something. Any thoughts?

[krwq]

Our first goal is to provide versatile library (model). The goal of the model is to:

• query what specific device (.NET type) is capable of - what telemetries it can produce etc - in a fairly generic way
• given object instance it should be able to also get that telemetry (this gets us into "how they're connected" part)

How the devices are connected is not our first goal but we should have at least some sort of initial design for that before we can say that our design of model will play nicely with that. I.e. some device may allow connecting other devices to them (i.e. GPIO expander or FT4222; there are also some devices which produce telemetry AND allow connecting other things) - on its own it may not produce telemetry but stuff connected to it can do it. At the query time we're not aware that anything is connected but we'd still like to understand how to represent that tree structure and how we could add such capability in the future.

Attributes goal is to make it easier to create such model (i.e. rather than doing it by hand you simply tell which type you'd like the model generated for). Some applications require model to be created at runtime and that's our design will revolve around model (this is similar approach to what serializers are doing). We added them early so that we could start experimenting with that since their shape is unlikely going to change greatly and we can start using them for docs as well (unfortunately we lacked time to do that).

Prototype/code-gen is only to prove the design is useful and can be used for i.e. code-gen and if something useful is created from that - even better.

I'd be really interested in hearing more how you'd envision working with attributes/model (i.e. write prototype code of how you'd interact with it). I'm curious of how that would be similar/different to our prototype 😄

[logicaloud]

Thanks again for sharing your thoughts. Happy to share prototypes but it may be a few months before I can have a good look. My envisioned approach would be simple: Pick some devices and see if the defined interfaces and attributes are sufficient (and convenient / efficient) to construct a working device dynamically by using reflection. If not then revise interfaces and attributes. Turning the code that uses reflection into a library would be secondary step.

[krwq]

Sure, there is no rush, I'm unlikely going to have time to play with this any time soon... Here is some brain dump and notes of various scenarios to think about...

Some interesting devices to look at when prototyping:

• SenseHAT (combo of multiple devices but all setup is known up front) - this is my favorite and one of the simplest example to show hierarchy
• any kind of extender or anything allowing you to add sensors
• anything requiring some sort of setup (i.e. DC motor)

other interesting devices:

• devices which take some time to produce telemetry and something you would usually manually trigger (i.e. scale) - initial thoughts on that is that device does not automatically collect telemetry but it is complimented by "produce_telemetry_now" command or similar; other example: buttons, joysticks where telemetry shape/time is really different depending on application - actually - part of SenseHat as well
• popular devices which are not good for non-real time OS (1-wire thermometers)
• displays - they don't produce telemetry and input is not straightforward

other interesting scenarios:

• some applications do not need all telemetry and just need a filtered down version of it (i.e. you're interested when temeperature/water level/... is below threshold rather than what's the current level)
• statistical information - moving averages etc. - data with lots of noise like accelerometer
• on the usage side - you might need data from both device which is directly connected to your board and remote data from things like temperature in different building

for the last one - we've had fairly good luck with Rx - so far we haven't seen any problems with that approach and code is clean and really easy to add stats/filtering/essentially whatever. Also plays really well with anything telemetry related including combining, transforming etc. The downside of Rx is that writing Rx code requires knowing the library (reading is simple though) - with ChatGPT now on the table perhaps is no longer that big of deal anymore.

[logicaloud]

Great info, thank you. I'll leave it to you to decide whether this issue should be closed in the meantime.

[logicaloud]

Edit: Having dug a bit deeper, I think some of my previous thoughts are just not feasible (i.e. device probing/discovery) or already realized in some other form. It is probably best to carry on when I have something more tangible.