eclipse-thingweb / node-wot Goto Github PK

It was unclear to me whether 8.x or 10.x was necessary. I assume you are using a recent version but it's not clear how recent it has to be. I installed 10.5.0 and got the following error when trying to run the examples/scripts:

~/thingweb.node-wot/examples/scripts$ wot-servient
WoT-Servient using defaults as 'wot-servient.conf.json' does not exist
DefaultServient configured with { servient: { scriptDir: '.', scriptAction: false },
  http: { port: 8080, selfSigned: false } }
HttpServer starting on port 8080
DefaultServient started
Trace: error building CLI Management Thing: TypeError: console.debug is not a function
    at /home/mmccool/Devel/thingweb.node-wot/packages/cli/dist/default-servient.js:82:25
    at process._tickCallback (internal/process/next_tick.js:103:7)
WoT-Servient cannot start: console.debug is not a function

Alternatively, fix the above so node-wot works with 10.x (of course, something else could be wrong here...)

It might be of use to find out about node-wot performance to check where there are possible bottlenecks if node-wot is part of a complete end-to-end setup. For that I'd like to have a module carrying out such measurements, like counters of samples sent in the last 5 minutes, rate, throughput, total 5min-bytes, overall total bytes , etc.

Property things currently returns null

Copied from thingweb/node-wot#57

A node-wot development installation takes more than 500 MiB because of the node_modules copies. Would be nice to reduce this footprint for less powerful devices such as old Raspberry Pis, Edisons, etc.

TODO:

• Create a target production with something like sudo lerna exec -- npm prune --production
• Try out https://yarnpkg.com/

A recent update related to coap-binding seems to require Node.js 10 to successfully run npm run bootstrap...

With version 8 I get lots of issues (e.g. also related to #10) while with Node.js 10 everything seems to work fine again.

1. I am not sure if it is already the time to switch
2. There are more issues with binding-websockets package
   node_modules/@types/ws/index.d.ts(179,24): error TS2694: Namespace '"net"' has no exported member 'AddressInfo'.
   Adding the following to ws.ts for example does the trick
   declare module 'net' {export interface AddressInfo {} }
3. TODO (we need to setup Travis again to avoid/notice such issues in the future)

Currently the converter methods of ContentCodec just have the following simple signatures:

  bytesToValue(bytes: Buffer): any
  valueToBytes(value: any): Buffer

It would be helpful to provide more information to these methods to help them doing the correct encoding and decoding.

For bytesToValue it would be helpful to have the following additional information:

• "type" of the expected result, as e.g. specified for a property in the TD
• additional parameters of the media type, e.g. charset or other specific parameters for specific media types

For valueToBytes the "type" of the property is probably not needed, as this is the type of the parameter itself. It would however be helpful to properly understand the value parameter. The additional parameters to the media type however would also be required in some cases to do a proper encoding.

It is desired to setup Travis testing again (see #11).

Unfortunately I do not have sufficient rights to do so..
https://travis-ci.org/eclipse/thingweb.node-wot

Who has sufficient rights?

I've been perusing the latest W3C documents and combing through various implementations for a while, and have yet to find a way to update the name or description of a thing.

The various bindings seem to reject update methods to the root resource of each thing where these fields are defined, and the properties collection seems to be for more tangible/real-world properties and not for friendly names, display information, etc.

An extension of this question might be whether there is a prescribed way to represent other discrete data about the thing (such as manufacturer or serial number). I see the "support = none" property in the counter example, but I wasn't sure if this was a similar use case and, again, I couldn't discern any API for changing these values.

I apologize if there is a more appropriate project to log this issue under, but this is the most comprehensive implementation I've seen, so it seemed like my best bet.

Running the coap-servient example provided produces an error:

Unexpected token t in JSON at position 2

adding double quotes to type (lines with { type: "string" }) resolves it.

Its probably due to the way ExposedThing handles the schemas.

When running npm run build I got this error

@node-wot/[email protected] build /home/pi/WoT/thingweb.node-wot/packages/binding-websockets
tsc

lerna ERR! npm run build exited 2 in @node-wot/demo-servients
lerna ERR! npm run build stdout:

@node-wot/[email protected] build /home/pi/WoT/thingweb.node-wot/packages/demo-servients
tsc

src/bridge-cli-servient.ts(23,30): error TS2307: Cannot find module @node-wot/binding-oracle.
src/oracle-festo-proxy.ts(20,30): error TS2307: Cannot find module @node-wot/binding-oracle.

lerna ERR! npm run build stderr:
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! @node-wot/[email protected] build: tsc
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @node-wot/[email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2018-10-30T19_21_08_203Z-debug.log

lerna ERR! npm run build exited 2 in @node-wot/demo-servients
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! @ build: lerna run build
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @ build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2018-10-30T19_21_08_366Z-debug.log

But the binding-fujitsu, binding-file, binding-coap, binding-http, binding-mqtt works find.

When using the CoAP binding in clients and the server does not send any answer to a request, no timeout is triggered. The promise is never fulfilled or rejected, means using "await" results in an endless waitstate.

Running a script with cli, e.g.
// Read value
UCount = await UT.properties.count.read();
with the CoAP server to read from being offline results in endless wait.

Adding
req.on("timeout", () => {
console.log('CoAP client got timeout when accessing ${form.href}');
reject("Timeout");
});
in coap-client.ts > readResource did not solve the problem. Still investigating.

Copied from thingweb/node-wot#24

TODO:

• we use https://gitpitch.com/
• we add a PITCHME.md
• we link the rendered version from the README

POC:

• https://gitpitch.com/harald-mueller/node-wot/issue_24_Pitchme?grs=github&t=white
• https://github.com/harald-mueller/node-wot/tree/issue_24_Pitchme
• [![GitPitch](https://gitpitch.com/assets/badge.svg)](https://gitpitch.com/harald-mueller/node-wot/issue_24_Pitchme?grs=github&t=white)

Add a field to wot-servient.conf.json, which is passed to the Helper to statically add them to the getAddresses function.

-v should show node-wot version.

A recent update made the requirements of Phyton executable required.

If this is going to stay ( @mkovatsc ?) we may need to mention it here https://github.com/eclipse/thingweb.node-wot#prerequisites

Loading a configuration from the command line in the CLI does not work as documented.

In the help, the function is documented as:

options:
-f, --configfile=file   load configuration from specified file

Doing this does not work.

When using the file binding I get the following warning on the console:

(node:9222) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

The reason is the following line:

https://github.com/eclipse/thingweb.node-wot/blob/b4bcbd5a22bbab74c88a3df7a39e6ef970909348/packages/binding-file/src/file-client.ts#L55

I propose to follow the recommendation given in the warning and replace the constructor by one of the factory methods.

TD parser has default namespace context.

REMINDER: Depending on the outcome of w3c/wot-thing-description#185 (and whether it will be part of the next release) we need to align also...

TD:

...
  "id": "<YOUR THING's ID - A URI/URN>",
  "security": [
    {
      "scheme": "apikey",
      "in": "header",
      "pname": "<X-YOUR-HEADER-FIELD-NAME>"
    }
  ],
...

wot-servient.conf.json

...
  "credentials": {
    "<YOUR THING's ID - A URI/URN>": {
      "apikey": "<YOUR KEY>"
    }
  }
...

The write(value) method of the ExposedThingProperty class which is called when a request is received to change the value of a property, returns a promise.

It checks if a property writeHandler is defined, and if so, get's the promise this handler returns, waits for it to resolve, does some logging and internal state updating, and then resolves it own promise accordingly.

However, if the promise returned by writeHandler is rejected, there is not catch() to handle this rejection. This means that the promise returned by write() is never rejected and just hangs.

As an example, if my writeHandler rejects a certain property write (for example because it's invalid) , this results in an UnhandledPromiseRejectionWarning being thrown and in the write request hanging indefinitely.

A possible solution would be to add:
.catch((err) => { reject(err); })
after the then() block in exposed-thing.ts line 294.

The latest ThingDescription spec uses contentType again (it used to be contenttype, lower-case).

How can I create a property with a contenttype equal to image/jpeg? In general, is there a way to change the contenttype of the created forms?

securityDefinitions is mandatory (https://w3c.github.io/wot-thing-description/#thing), however, a Thing Producer does not generate a TD with this term at top level.

• type in DataSchema must not be required (see w3c/wot-scripting-api#133)
• DataSchema has now IntegerSchema and NumberSchema

In Add a Property definition to the Thing examples, the writable is still in use. Only readOnly and writeOnly should be used.

Copied from thingweb/node-wot#26.

We already use conventional commit messages for thingweb.node-wot. What is missing is an automated changelog.

Options:

• commitizen & conventional-changelog: https://commitizen.github.io/cz-cli/
• https://github.com/semantic-release/semantic-release

How to reproduce:
Run counter example node packages\cli\dist\cli.js examples\scripts\counter.js and retrieve the TD which reports a property count with "writeable": true.

The property is not writable and reports 500 error on PUT.

When I am sending a CoAP GET message, I get the following error:

CoapClient sending GET to coap://193.234.219.199:5683/3303/0/5700
/usr/src/app/thingweb.node-wot/packages/binding-coap/node_modules/coap/lib/option_converter.js:143
    throw new Error('No matching format found')
    ^

When I am sending the same request with the coap-shell app, everything works.

Below is the response I get with coap-shell:

Options: {"Content-Format":"text/plain"}
Status : 205-Reset Content, Payload: 3B
................................... Payload ....................................
8.3

I am using the Leshan LWM2M Client (prebuilt) as CoAP server.

(Note that, due to firewalls, the IP address of the CoAP server above is not reachable from the Internet, so you will unfortunately not be able to test it)

All the new examples of the TD standard uses:

    "@context": [
        "http://www.w3.org/ns/td",
        {"htv": "http://www.w3.org/2011/http#"}
    ]
... 
(in a form)
...
  "htv:methodName": "GET"

First problem is that the default assumption should be for htv:methodName and not http:methodName (or both). However, the recommended way would be to find the term that links to http context from @context. So even if someone uses:

    "@context": [
        "http://www.w3.org/ns/td",
        {"abc": "http://www.w3.org/2011/http#"}
    ]
... 
(in a form)
...
  "abc:methodName": "GET"

node-wot should be able to use the correct HTTP method.

http-client.ts looks for this at line 339.

Currently, the wot-typescript-definitions dependency is listed as a devDependency in the coremodule even though many of its type definitions are re-exported. (for example in wot-impl.d.ts)

When trying to use @node-wot/core as a dependency in a typescript project, an error occurs due to missing type definitions.

As we export some of the types it defines, wot-typescript-definitions should be listed as a normal dependency.

In the current wot-impl.ts implementation, when a fetch() operation is performed, the contentType of the response is checked to make sure it is either "application/td+json" or "application/ld+json".

if (content.type !== ContentSerdes.TD &&
    content.type !== ContentSerdes.JSON_LD ) {
    console.warn(`WoTImpl received TD with media type '${content.type}' from ${uri}`);
}

However this check always returns false when using a http client right now.
this is because the http client uses the function checkResponse() to generate the content object, and this function currently creates an object with the wrong attributes.

Copied from thingweb/node-wot#77

On the way to production, we need to include proper logging. We could use the debug module, which is good for library modules and frameworks (e.g., used by express):

const debug = require('debug')('my-namespace')
const name = 'my-app'
debug('booting %s', name)

Line 35 of the thingweb.node-wot/packages/binding-http/src/http-client-factory.ts file does not check if this.config is null . The this.config.proxy access results in an error if no configuration is set during HttpClientFactory initialization.

Line which caused the error: servient.addClientFactory(new HttpClientFactory());

Adding the null check (this.config != null) solved the problem for me.

HttpClientFactory.prototype.getClient = function () {
        if (this.config != null) {
            if (this.config.proxy && this.config.proxy.href && this.config.proxy.href.startsWith("https:")) {
                console.warn("HttpClientFactory creating client for 'https' due to secure proxy configuration");
                return new http_client_1.default(this.config, true);
            }
        }
        else {
            console.log("HttpClientFactory creating client for '" + this.scheme + "'");
            return new http_client_1.default(this.config);
        }
    };

Note: The CoAPS library (node-coap-client) is unfortunately very limited, e.g., it does not even support Uri-Query.

TD:

...
  "id": "<YOUR THING's ID - A URI/URN>",
  "security": [{ "scheme": "psk"}],
...

wot-servient.conf.json

...
  "credentials": {
    "<YOUR THING's ID - A URI/URN>": {
      "identity": "<PSK IDENTITY>",
      "psk": "<YOUR PSK AS STRING - try \uXXXX for binary>"
    }
  }
...

In the TDs automatically generated by node-wot, the op field in the forms of a properties is always an array that contains both "readproperty" and "writeproperty". (even if writable is set to false.)

This field is defined as a string and not an array according to the spec draft.
So the expected behaviour is for it to be set to "readproperty" if the property is not writable and to be set to "writeproperty" if the property is write only.

I am not sure what the correct value should be when a property is both readable and writable though.

TD alignments for F2F Princeton

This is meant to b a sticky placeholder to keep track of missing alignments (with https://w3c.github.io/wot-thing-description/).

• TODOs (Look into)
  • Eventing in general: cancellation, subscription, ...
  • ExpectedResponse (@wiresio)
• uriVariables (df9ecdd)
• forms on top-level (i.e. read-all) (cd99e8f)
• Versioning (DP: field added. More needed? --> @sebastiankb I tested this feature. Works!)
• MultiLanguage (DP: field added. More needed? --> @sebastiankb I tested this feature. Works!)
• scopes, security, and uriVariables on InteractionFragment level (fixed in 2b830e3)
• op in forms (@sebastiankb, please check also outcome of w3c/wot-thing-description#236 (comment))
• observable properties with http longpoll (@sebastiankb)
• Add safe and idempotent to Action (d80eea9)
• Remove writable and replace it with readOnly and writeOnly (fixed in 96c37f6 and 85e9cd7)
• Security (fixed in 1c8df2e)
  • SecurityScheme: rename proxyURI to proxy
  • Rename APIKeySecurityScheme to ApikeySecurityScheme
  • BearerSecurityScheme: add attribute authorization
  • CertSecurityScheme: missing
  • Rename PskScheme to PSKSecurityScheme and add attribute identity
  • PublicSecurityScheme: missing
  • Rename PopSecurityScheme to PoPSecurityScheme
  • OAuth2SecurityScheme: add attributes token and refresh
• mediaType/contenttype renamed to contentType (fixed in 2c889b5)

Please comment below if you encounter anything else missing...

Thing level forms is used for reading/writing all properties but the TD generated by node-wot doesn't include the readAllProperties value for op in forms.
cd99e8f doesn't add this feature.

@egekorkan You wanted to create more documentation: thingweb/node-wot#68

Can you please outline what exactly you wanted to create?
Also see #12.

Copied from thingweb/node-wot#97.

See thingweb/node-wot#96 for a quick fix.

TODO:

• think of a good way to do it

Copied from thingweb/node-wot#38.

The cli already uses a wot-servient.conf.json for configuration. This should in future also be used to include protocol binding implementations by including entries such as:

"servers" : [
   "@node-wot/binding-http"
],
"clients" : [
   "@node-wot/binding-http",
   "@node-wot/binding-coap"
]

There can then be required, but we would need standardized class names, I guess.
Is there a better way to do such dynamic dependencies?

To face the issue that was mention in PR #9 (getAddress()) we should think about to make the td-generator.ts more generic for any protocol bindings.

So far, if there is a new protocol binding such as MQTT with remote broker address assignment or specific protocol handling such as http long poll some if statements have to be added within generateTD() method. This should be avoided in the future and TD generator should be more generic for any new bindings.

Proposal is to provide a getForms() method in the protocol-interfaces.ts that have to be implemented by the protocol binding packages. The getForms() returns a array with all communication metadata that are relevant for the underlying protocol binding.

What do you think?

Using NPM, you can install NodeJS independent from the usually outdated package managers such as apt. This is nicely done by n:

sudo npm cache clean -f
sudo npm install -g n

To get the "stable" version:

sudo n stable

To get the "latest" version:

sudo n latest

Finally, make the node command available through:

sudo ln -sf /usr/local/n/versions/node/<VERSION>/bin/node /usr/bin/node

Needs to be implemented...
ExposedThingProperty needs a Subject and next() calls.

When trying to access a node-wot Thing (server mode) from a browser application hosted on a different domain, a Cross-Origin Resource Sharing (CORS) pre-flight request is needed in certain cases.

This is an HTTP OPTIONS request, and currently it always returns with a 405 Error, making the Thing inaccessible from a browser when it sends automatic CORS preflight requests.

In the Scripting API call we decided to align the get/set vs read/write terms used also in the TD and Binding Templates to a uniform read/write.

See w3c/wot-scripting-api#127

The tsc command fails to create a correct JS file.
When running for example "node packages\cli\dist\cli.js examples\scripts\counter.js" I get

thingweb.node-wot\packages\cli\node_modules\wot-typescript-definitions\index.d.ts:1
(function (exports, require, module, __filename, __dirname) { export as namespace WoT;
                                                              ^^^^^^

SyntaxError: Unexpected token export
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:616:28)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (D:\Projects\WoT\thingweb\thingweb.node-wot\packages\c
li\dist\default-servient.js:17:36)