opent2t / translators Goto Github PK
View Code? Open in Web Editor NEWRepository for Open Translators to Things.
Home Page: http://www.opentranslatorstothings.org
License: Other
Repository for Open Translators to Things.
Home Page: http://www.opentranslatorstothings.org
License: Other
We first need to make sure this issue is resolved in the bridge: tjaffri/msiot-samples#4
Once done, we can update all translators to js-promise versions
We first need to make sure this issue is resolved in the bridge: tjaffri/msiot-samples#4
Once done, we need to remove the explicit globals at the end of all translators, e.g. these:
// globals for JxCore host
global.initDevice = module.exports.initDevice;
global.getBeatsPerMinute = module.exports.getBeatsPerMinute;
global.getRRInterval = module.exports.getRRInterval;
global.getEnergyExpended = module.exports.getEnergyExpended;
global.getContactStatus = module.exports.getContactStatus;
global.disconnect = module.exports.disconnect;
The Wink Lamp translator still needs to add support for dimming and color.
This got buried in #50 but we need to clearly document somewhere the expected naming convention for translator packages.
I will add something to README.md
in this repo.
We should also need to make sure that whenever we resolve openT2T/generator-opent2t#4 we make sure it generates the correct name (it can auto-derive from the name of the schema the user selects)
After integrating with the new schema changes I can get the Wink device properties from the translator with getThermostatResURI but i'm unable to change the device properties using postThermostatResURI . The post succeeds but the device does not update.
REST API here: https://us.lightify-api.org/
We currently don't support doing different operations at the same time. Imagine turning on a bulb and setting brightness to 33%. In our current implementation these are two different operations (and could independently fail/succeed).
Some protocols (e.g. Wink, Nest, bluetooth) support sending multiple commands together in one atomic request. We need to support this mode.
We should also start thinking about disallowed state transitions (if needed) as part of this excercise. For example, a robotic arm might not be able to go right, then up (if that sequence of operations will lead to a bad state or collision). In some cases we might want to analyze the batch and fail to start it if we know upfront that state will not be allowed. We should at least spec/plan that design as part of this work.
As part of review for #53 @jasongin identified that the ava test automation file is not easy to read. It uses awaiter etc which will make it hard for others to use the test file as reference. See: https://github.com/openT2T/translators/pull/53/files#r75198452
@sanjaiganesh perhaps you could take a stab at this change as the original author of the test automation file?
I can help after tomorrow if you want.
Translators do not support getting the current device state without making multiple calls to the translator for each property. Should consider adding support to translators that allow getting the current state of the device in a single call
Replace console.log() in translators and perhaps other code to use debug and provide filters so we can turn the debug on off.
In situations where the hub can do a refresh of the access token it should do that, such as in the case of Wink.
An example:
function validateArgumentType(arg, argName, expectedType) {
if (typeof arg === 'undefined') {
throw new Error('Missing argument: ' + argName + '. ' +
'Expected type: ' + expectedType + '.');
} else if (typeof arg !== expectedType) {
throw new Error('Invalid argument: ' + argName + '. ' +
'Expected type: ' + expectedType + ', got: ' + (typeof arg));
}
}
We want to support "composable" schemas, specifically let's say that we have a basic BinarySwitch (on/off) schema. Most other schemas also need on/off functionality so rather than repeating the on/off schema in all those other schemas if we can reference the BinarySwitch schema from every other schema that needs this functionality.
As part of this we will also need to think about namespacing the methods in the translator. For example, imagine I have method/property X in both schema A and B. If B inherits from A then the translator implementation needs to differentiate between A:X and B:X.
This will help keep schemas more readable, and also lead to common implementation in the translators (similar to our wink-helper) be more logically mapped to the refactored schemas.
Let's use this issue to work on:
All the tests are common for the translators in a given schema e.g. look at discussion here: #56 (comment)
We should figure out a way to have a single set of tests for a schema that runs for all the translators in that schema, and flags any that are "different". We should also have a way to write extra depth tests beyond the schema tests for any particular translator we want.
Update translators for breaking changes in the new design, including:
Currently some translators return the device id unchanged other time the type of object is appended, and other times the hub id is appended. We need a consistent way of doing this.
@tjaffri Need to create an npm package for the Wink translator
Every translator has a node package name in its package.json, e.g.
{
"name": "opent2t-translator-wink-light-bulb",
"version": "1.0.0",
"description": "Wink Light Bulb",
"homepage": "http://opentranslatorstothings.org",
"dependencies": {},
"devDependencies": {
"async": "~1.5.2",
"optimist": "0.6.1",
"opent2t-onboarding-winkhub": "*"
},
"author": "",
"license": "MIT"
}
We need to come up with a convention for these names, somehow aligning with the reverse-URI naming convention of the translator folders... This needs to get done before we publish these to NPM, but since it is not a directory structure change we can separate this from #43
#44 and #45 scaffolded out the initial pattern for Thermostat schema, with a basic implementation for the Wink Thermostat Translator (in the dev branch, at the time of writing).
We now need to complete the implementation. Specifically:
For both above, we can start with the OCF style schemas (RAML and JSON) with corresponding OCF style translator implementation (get and post methods). However, to completely close this issue we need to (later) implement the AllJoyn style schema as well.
Finally, we should include automated tests as well. See the tests folder inside the existing Wink Thermostat translator for some examples. We should extend for new schema properties.
Note: All wink translators depend deeply on opent2t-translator-helper-wink, which is checked into the Helpers folder in this repo. We will move this code elsewhere soon, but for now you will need to use this helper (and add to it / fix it if needed) to resolve this issue.
Running the test automation recently introduced here the Wink translator is failing, and redirects to the wink home page.
We need to figure out why. Perhaps we need to move to the v2 API sooner than we thought?
Clients could be caching device ids. But Wink can re-purpose/change device ids.!!! could be the case with others too. We need to have device objects to have a unique id. And We need to have an error handling flow, where translator conveys this to the caller (not sure what error gets returned from wink in such cases) and caller will go back to onboarding to get latest devieid. (or whatever mechanism we chose)
http://docs.wink.apiary.io/#reference/a-restful-service
All objects in the Wink API can be identified by [object_type]_id; the value of the [object_type]should be used to discern which kind of object you are dealing with.
The identifier is a string and not globally unique, currently. That is there can be a 'light_bulb_id':'abc' and a 'thermostat_id':'abc'
It is possible for the API to re-assign identifiers to resources to rebalance keys; in this case, your resource will still exist but it (and all references to it) will be updated to the new identifier. Your application should be able to handle this case.
We currently have methods like turnOn and turnOff in schemas (e.g. the light schema). This is problematic because there also needs to be a getOnOffState method to support read of the current state.
A much cleaner approach would be to just have a value property on the schema (type boolean) which has a get and set.
We need to refactor across the board to support this pattern.
@jasongin you said you are already working on this, so tracking with an issue.
I have this almost done (following the same patterns as the thermostat translator we already ported). Will send PR shortly.
We need to add remaining APIs to complete this sample:
Add json schema and RAML for org.OpenT2T.Sample.SuperPopular.Thermostat, using the OCF format.
We are using the constructor to init devices in the new translator format currently being built in the dev
branch. We don't have a destructor (not supported in es6 JavaScript?) or any explicit disconnect/destroy button.
This is an issue for some translators, e.g. the Bluetooth LE based TI SensorTag temperature sensor. That needs an explicit connect and disconnect (both async).
For now we are working around this by create non-schema connect and disconnect methods in only the TI SensorTag temperature sensor. These methods are called explicitly in the unit tests.
Ideally connect/disconnect should be called automatically as part of translator lifecycle... for devices that need this, but we need to figure that out.
This could be something that is only important for non-hub translators. Since we are focused right now on hub based translators, this is something we can mull over.
We are about to publish opent2t-translator-helper-wink to npm to facilitate folks who are currently playing around with translators.
@sanjaiganesh previously published this: https://www.npmjs.com/package/opent2t-translator-helper-nest as well as this: https://www.npmjs.com/package/translator-nest-thermostat
This issue serves as a reminder that we need to unpublish all of these when no longer needed. The last one (translator-nest-thermostat) is not even the correct name and has been replaced by this one: https://www.npmjs.com/package/opent2t-translator-com-nest-thermostat
Translators need to throw exceptions that contain the HTTP status code for the request failure so services can determine how to handle the failure and propagate it to the user
We currently have folders with the name of the hardware corresponding to each translator (without namespacing) under each schema folder.
E.g. here we have folders like “Philips Hue Light Bulb” and “Osram Lightify Light Bulb”. These names are not namespaced, unlike schema names which are namespaced.
We need to update all the translator names to reverse URI based names, just like the schemas. The name of the hardware and the npm package name should be included in the package.json as description and name, respectively.
This will be a pretty disruptive change for anyone who depends on translators and the current structure of the repo, so we will need to make sure all dependencies are updated at the same time.
PR #23 added a translator and schema for a doorbell (with a concrete Wink doorbell implementation)
However, it is currently polling for whether the doorbell is pressed. This needs to be a signal that gets triggered when the doorbell is pressed.
When the opent2t.getSchemaAsync api is called the OcfSchemaReader module is not able to load because it is not part of a npm package and does not have opent2t installed that it can load.
var OcfSchemaReader = require("openT2T/schema/OcfSchemaReader");
PR #19 added a translator and schema for a smoke alarm (with a concrete Wink smoke alarm implementation)
However, it is currently polling for whether there is a fire. This needs to be a signal that gets triggered when the smoke alarm goes off.
#44 is creating the thermostat schema in OCF format.
In parallel, we need to update one translator (let's pick the Wink Thermostat Translator for ease) to implement that schema. This includes:
The manifest.xml
needs to reference the OCF schema(s), where it currently only references a single AllJoyn schema.
For example:
<schemas>
<schema id="org.opent2t.sample.thermostat.superpopular" main="true" type="OCF" />
<schema id="oic.r.temperature" type="OCF" />
<schema id="oic.core" type="OCF" />
<schema id="oic.baseResource" type="OCF" />
</schemas>
Note that we are OK (for now) duplicating the fact the dimming and binary will likely be $ref inside org.OpenT2T.Sample.SuperPopular.Lamp but will also be duplicated under schemas. We can discuss this further at a later date.
We need to update the translator methods to correspond to the RAML (get/put pattern) in OCF.
Initially, let's warn on test failures but later let's plan to make passing tests a gate for Pull Requests.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.