search

IoTone / ProjectMagNET

Project Mag*NET is an IoT data sync and control app + distributed server for iot data
https://iotone.github.io/projectmagnet.github.io/
Apache License 2.0
0 stars 1 forks source link

Implement Device Profile system #23

Open truedat101 opened 5 months ago

truedat101 commented 5 months ago

Concept here is to provide descriptors for a device or sets of devices that provide :

This is the tricky part is that some manufacturers leave all of this undocumented. So some devices would need to be reverse engineered if the specs aren't documented or characteristic descriptors aren't helpful.

How would this look? Maybe JSON? Maybe YAML (better?). In any case, it would be added to the settings of the app and the app or server would pull in the profile. Then when we scan, if we find a matching device, it would know how to handle it. Somewhat like WURFL from back in the day.

Reference old project ideas from IoToneKit:

https://github.com/IoTone/IoToneSpec_UniversalDeviceMetadata/blob/master/IOTONE_SPEC_1.md and https://github.com/IoTone/IoToneSpec_UniversalServiceMetadata/blob/master/IOTONE_SPEC_2.md

The question is, is there enough here above in these ideas to describe capabilities to generate. a UI. The HomeKit concept had it right as far as constraining you to a set of things that you can do with a light, or shades, or a switch.

truedat101 commented 4 months ago

So making a note here that the idea of generating a UI from some metadata is very old, something we innovated on JTT/JavaAuto. My goal with IoToneKit originally was to make this painless to implement for a device manufacture. Nothing to scheme up. Just map your native implementation into a framework, and provide some XML or JSON to compile.

truedat101 commented 4 months ago

Ideally what I am after is a place to specify some JSON files that are hosted securely on https, and have some means of verification of the authenticity of the signature of the provider of this file. Then you'd slurp in this descriptor files once. This gets you device and service profiles. These might start out as some default things provided that will work with generic things minimally. But for my own projects for wearables, I want to be able to spec out schemas for the the devices:

Then I don't need to write a custom app for every new device, nor really work too hard to make a design that works with common component. Sensors need dashboards, configuration maybe, calibration maybe, possibly an on/off, and battery level. Buttons have state. Lights have color, state, and usually some other things like identify. When it comes down to it, there are really only a few dozon types of services needed to cover the basic use cases.