Device file syntax and structure

I've been thinking about Tim's comments about writing the device file in Python code, and I have two broad philosophical comments regarding why doing it in our own language might be better.

First, we're going to be interpreting into python anyway.

Second, and I think this is a clincher - why don't we create a way to annotate translate an API for an IoT device, in python, to work with our pyot syntax. This is very similar to Tim's idea, but it is not the same, because we'd still have a device file written in pyot, whose responsibility it is to expose a "virtual" interface, manage devices that fall under its purview, expose a "virtual" state to the pyot ecosystem - that can be customised and therefore more lightweight, and delegate requests efficiently (and maybe even based on priority). I think this is beneficial for a couple of reasons.

Unifying standards. These annotations can help build in aliasing. It can let the interpreter know that PhillipsHue's API uses an powerUp instead of startUp method, or isPoweredOn as a variable rather than isOn. We'd provide a way for manufacturers to do this, of course, but also programmers who want to import an API which doesn't support pyot. This would help significantly with some of the problems Indigo mentioned. We don't have control over whether manufacturers agree on standards, but we can provide a way to unify irrationally different APIs in our language, which may impose requirements, like the powerOn function must be called powerOn and nothing else, and everything else has to be translated into that naming convention. Similarly, if one API requires colour in rgb and another requires colour in hex, we can translate, under the hood, between the two. This would allow you to interface with the IoT devices in a uniform way, limited only by differing functionality, not different standards.
Virtual State. I think this is a really interesting idea, but basically I wonder if there are benefits to exposing a virtual state to the ecosystem. Ria's file has this really interesting state keyword. I note that this state need not be a one-to-one mapping onto the actual physical state of the device exposed by the API. I can see this leading to simplicity and efficiency in management of device state.
Simplifying Complexity. I think APIs are heavily tied to devices. I wonder if adding a layer of abstraction would simplify this greatly. Thinking about it, not only are different APIs different for the sake of being different, but a lot of APIs can be simplified and reconciled if you only care about a certain set of methods (and I think most people only care about a handful), because the "bulk" of the API is the same, and the majority of the differences lie in auxiliary features - this is especially true for devices with different APIs but produced by the same manufacturer, like Indigo's article suggested. Technically, if you're only using a certain set of methods, then two different devices with different APIs can share a "controller", written in the pyot language, which can then be decoupled if necessary in future. This is a lot harder to do when interacting directly with the python code. This abstraction leads to interesting possibilities - if multiple devices with overlapping but different APIs are reconciled under a single pyot device file/controller, could that controller be more efficient at handling complex requests, like when you need any IoT device with a specific feature, rather than needing a specific IoT device with that feature.
Onboarding hell. The blogpost Indigo sent us focused a lot on how onboarding is a pain in the ass - any way having a device file could simplify that?

michaelleejl / pyot

Device file syntax and structure #2