In situations where the hub can do a refresh of the access token it should do that, such as in the case of Wink.

@jasongin you said you are already working on this, so tracking with an issue.

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.

For #44 and #45 we need at least BinarySwitch and Dimming schemas from OCF. We should consider adding a few more as well, since they will likely be needed soon by translators we write.

http://docs.winkapiv2.apiary.io/#

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.

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

#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:

1. Add more schema properties, specifically things like thermostat modes etc.
2. Implement the new schema methods in the translator.

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.

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 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.

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?

Let's use this issue to work on:

1. How do we mark a property as notifyable in the RAML + JSON OCF schema
2. We have some unit tests to actual emit events from the translator checked into the OpenT2T repo, we need to update the translator to use the same (e.g. EventEmitter etc)
3. How do we use the Wink subscriptions to get an event back, and then raise the event. How do we register for a callback from wink inside the translator.
4. How do we update our cloud sample to make this work end to end and send a push notification to a caller when the doorbell rings.

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 need to add remaining APIs to complete this sample:

1. Push notifications / webhooks
2. Device and account management
3. Etc...

Add json schema and RAML for org.OpenT2T.Sample.SuperPopular.Thermostat, using the OCF format.

See https://www.iotivity.org/

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.

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.

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

Identifiers

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.

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.

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.

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.

REST API here: https://us.lightify-api.org/

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

Update translators for breaking changes in the new design, including:

• Node module exports
• Translator metadata in package.json
• Schema composability, and directory structure changes that result from it
• Properties and signals
• Hub devices

As part of PR #53 review @jasongin flagged that:

There is actually a "baseResource" RAML at oneiota.org, should that be included here?
(I didn't find a "core" RAML.)

I will follow up with a subsequent checkin for that RAML. I don't think it is a blocking issue right now.

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.

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)

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.

I have this almost done (following the same patterns as the thermostat translator we already ported). Will send PR shortly.

Initially, let's warn on test failures but later let's plan to make passing tests a gate for Pull Requests.

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));
}
}

Replace console.log() in translators and perhaps other code to use debug and provide filters so we can turn the debug on off.

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;

@tjaffri Need to create an npm package for the Wink translator

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

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

#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:

Updating the manifest file

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.

Updating the methods in the translator itself

We need to update the translator methods to correspond to the RAML (get/put pattern) in OCF.

The Wink Lamp translator still needs to add support for dimming and color.