Giter Club home page Giter Club logo

node-wot's Introduction

Thingweb node-wot logo

A fast and extensible framework to connect any device with your application

Default CI Pipeline npm codecov Telegram Group Discord

The Eclipse Thingweb node-wot is a framework for implementing Web of Things servers and clients in Node.js. It is written from the ground up with Typescript with the goal of providing a fast and extensible framework for IoT applications. Node-wot wants to give developers the ability to create complex business logic without worrying about protocol and low-level details leveraging on a standard metadata format, the Thing Description (TD). Thanks to the TD abstraction developers can find a set of satellite tools to create their applications in a fast and easy way.

Web of Things principles in a Nutshell

The Web of Things (WoT) tackles IoT fragmentation by extending standardized web technologies. It simplifies IoT application development, promoting flexibility and interoperability. WoT preserves existing IoT standards, ensuring reuse, and provides an adaptable, abstract architecture based on real-world use cases across domains. In essence, WoT paves the way for seamless IoT integration by defining an information model capable of describing Things and Services and how to interact with them. This information model is called the Thing Description (TD) and it is a JSON-LD document that describes the Thing and its capabilities, including its network services (APIs), its network interactions, and security requirements. The TD is the cornerstone of the Web of Things architecture and it is the main abstraction that node-wot uses to implement its functionalities. Every Thing has the following capabilities or "affordances":

  • โš™๏ธ Properties: a property is a value that can be read, written or observed. For example, a temperature sensor can have a property that represents the current temperature.
  • ๐Ÿฆพ Actions: an action is an operation that can be invoked. For example, a light bulb can have an action that turns it on or off.
  • โšก Events: an event is a notification. For example, a motion sensor can send an event when it detects motion.

For further information please refer to the official W3C Web of Things website.

Table of Contents

Installation

The framework can be used in two ways: as a library or as a CLI tool. In this section we will explain how to install the framework in both ways.

As a library

The framework is composed by different packages that users can use as they please. The core package is @node-wot/core and it is the only mandatory package to install. The other packages are bindings that allow the framework to communicate with different protocols and optionally we offer a set of tools in the @node-wot/td-tools package.

Node.js

Warning

We no longer actively support Node.js version 16 and lower.

Platforms specific prerequisites:

  • Linux: Meet the node-gyp requirements:
    • Python v3.6, v3.7, or v3.8
    • make
    • A proper C/C++ compiler toolchain, like GCC
  • Windows: Install the Windows build tools through a CMD shell as administrator:
    • npm install -g --production windows-build-tools
  • Mac OS: Meet the node-gyp requirements:
    • xcode-select --install

If you want to use node-wot as a library in your Node.js application, you can use npm to install the node-wot packages that you need. To do so, cd inside your application folder, and run:

npm i @node-wot/core @node-wot/binding-http --save

Browser

To use node-wot as a browser-side JavaScript Library, the browser needs to support ECMAScript 2015. Supported browsers include:

  • Microsoft Edge 15 and later
  • Firefox 54 and later
  • Chrome 58 and later
  • Safari 10 and later

Using a browser with only ES5 support (e.g., IE 11) might be possible if you add polyfills. If you want to use node-wot as a library in your browser application, you can install the @node-wot/browser-bundle as following:

npm i @node-wot/browser-bundle --save

you can find more installation options in the specific package README.

As a CLI tool

You can alternatively use node-wot via its command line interface (CLI). Please visit the CLI tool's Readme to find out more.

As a docker image

Another option is to use node-wot inside a docker image. Make sure you are under Linux or under WSL if you are running on Windows.

Clone the repository:

git clone https://github.com/eclipse-thingweb/node-wot

Go into the repository:

cd node-wot

Build the Docker image named wot-servient from the Dockerfile:

npm run build:docker

Run the wot-servient as a container:

docker run --rm wot-servient -h

Examples

With node-wot you can create server-side Things, in WoT jargon we call this operation "expose a Thing" or you can create client-side Things, in WoT jargon we call this operation "consume a Thing". An exposed Thing allows you to bring your device or services to the Web with just a few lines of code. On the other hand, with a consumed Thing, you have a fixed interface to interact with devices, potentially using different protocols/frameworks. In the following section, we will show how to create a simple counter Thing and how to consume it. Assuming you have installed and configured node-wot as a library, you can create and expose a counter Thing as follows:

// Required steps to create a servient for creating a thing
const { Servient } = require("@node-wot/core");
const { HttpServer } = require("@node-wot/binding-http");

const servient = new Servient();
servient.addServer(new HttpServer());

servient.start().then( async (WoT) => {
    // Then from here on you can use the WoT object to produce the thing
    let count = 0;
    const exposingThing = await WoT.produce({
        title: "Counter",
        description: "A simple counter thing",
        properties: {
            count: {
                type: "integer",
                description: "current counter value",
                observable: true,
                readOnly: true
            }
        },
        actions: {
            increment: {
                description: "increment counter value",
            }
        }
    })
    exposingThing.setPropertyReadHandler("count", () => { return count; });
    exposingThing.setActionHandler("increment", () => { count++; exposingThing.emitPropertyChange("count"); });
    await exposingThing.expose();
    // now you can interact with the thing via http://localhost:8080/counter
});

Now supposing you want to interact with the device, you have to consume its Thing Description as follows:

// client.js
// Required steps to create a servient for a client
const { Servient } = require("@node-wot/core");
const { HttpClientFactory } = require("@node-wot/binding-http");

const servient = new Servient();
servient.addClientFactory(new HttpClientFactory(null));

servient.start().then(async (WoT) => {
    const td = await WoT.requestThingDescription("http://localhost:8080/counter");
    // Then from here on you can consume the thing
    let thing = await WoT.consume(td);
    thing.observeProperty("count", async (data) => { console.log("count:", await data.value()); });
    for (let i = 0; i < 5; i++) {
        await thing.invokeAction("increment");
    }
}).catch((err) => { console.error(err); });

If you execute both scripts you will see count: ${count} printed 5 times. We host a more complex version of this example at http://plugfest.thingweb.io/examples/counter.html and you can find the source code in the counter example folder. You can also find more examples in the examples folder for JavaScript and in the examples folder for TypeScript. Finally, for your convenience, we host a set of online Things that you can use to test your applications. You can find more information about them in the Online Things section.

Implemented/supported features

Protocol Support

Note

More protocols can be easily added by implementing ProtocolClient, ProtocolClientFactory, and ProtocolServer interface.

Note

The bindings for binding-fujitsu and binding-oracle were removed after v0.7.x due to lack of maintainers.

MediaType Support

  • JSON โœ”๏ธ
  • Text (HTML, CSS, XML, SVG) โœ”๏ธ
  • Base64 (PNG, JPEG, GIF) โœ”๏ธ
  • Octet stream โœ”๏ธ
  • CBOR โœ”๏ธ
  • EXI โฒ๏ธ

Can't find your preferred MediaType? More codecs can be easily added by implementing ContentCodec interface. Read more in the Documentation section.

No time for explanations - show me a running example!

Using Node.js

Run all the steps above including "Link Packages" and then run this:

wot-servient -h
cd examples/scripts
wot-servient

Without the "Link Packages" step, the wot-servient command is not available and node needs to be used (e.g., Windows CMD shell):

# expose
node packages\cli\dist\cli.js examples\scripts\counter.js
# consume
node packages\cli\dist\cli.js --client-only examples\scripts\counter-client.js

Using Docker

First build the docker image and then run the counter example:

# expose
docker run -it --init -p 8080:8080/tcp -p 5683:5683/udp -v "$(pwd)"/examples:/srv/examples --rm wot-servient /srv/examples/scripts/counter.js
# consume
docker run -it --init -v "$(pwd)"/examples:/srv/examples --rm --net=host wot-servient /srv/examples/scripts/counter-client.js --client-only
  • The counter exposes the HTTP endpoint at 8080/tcp and the CoAP endpoint at 5683/udp and they are bound to the host machine (with -p 8080:8080/tcp -p 5683:5683/udp).
  • The counter-client binds the network of the host machine (--net=host) so that it can access the counter thing's endpoints.
  • --init allows the containers to be killed with SIGINT (e.g., Ctrl+c)
  • -v "$(pwd)"/examples:/srv/examples mounts the examples directory to /srv/examples on the container so that the node inside the container can read the example scripts.

Using a browser

An example of how to use node-wot as a browser-side library can be found under examples/browser/index.html. To run it, open examples/browser/index.html in a modern browser, and consume the test Thing available under http://plugfest.thingweb.io:8083/testthing to interact with it.

The JavaScript code that uses node-wot as a library to power this application can be found under: examples/browser/index.js

Online Things

We offer online simulated Things that are available to be used by anyone.

Their TDs are available at the following links:

All of them require no security mechanism to be communicated with. Below are small explanations of what they can be used for:

  • Counter: It has a count property that can be read or observed and can be incremented or decremented via separate actions. It is also possible to reset the count value, obtain when the last change occurred, subscribe to a change in the count value or get the count value as an image.
  • TestThing: This Thing exists primarily for testing different data schemas and payload formats. It also has events attached to affordances that notify when a value changes.
  • Smart Coffee Machine: This is a simulation of a coffee machine that also has a simple user interface that displays the values of properties. In addition to proving a real-life device example, it can be used for testing uriVariables. You can ask it to brew different coffees and monitor the available resource level.
  • Presence Sensor: It mocks the detection of a person by firing an event every 5 seconds.
  • Smart Clock: It simply has a property affordance for the time. However, it runs 60 times faster than real-time to allow time-based decisions that can be easily tested.
  • Simple Coffee Machine: This is a simpler simulation of the coffee machine above.

Documentation

Warning

โš’๏ธ We are planning to extend this section and to provide a more detailed documentation. Stay tuned!

The API

This library implements the WoT Scripting API:

Additionally, you can have a look at our API Documentation.

To learn by examples, see examples/scripts to have a feeling of how to script a Thing or a Consumer.

Adding a new codec

To add a new codec, you need to implement the ContentCodec interface. The interface is defined as follows:

export interface ContentCodec {
    getMediaType(): string;
    bytesToValue(bytes: Buffer, schema: DataSchema, parameters?: {[key: string]: string}): any;
    valueToBytes(value: any, schema: DataSchema, parameters?: {[key: string]: string}): Buffer;
}

Finally you can add to your servient the new codec as follows:

const { ContentSerdes, JsonCodec } = require("@node-wot/core");

// e.g., assign built-in codec for *new* contentType
const cs = ContentSerdes.get();
cs.addCodec(new JsonCodec("application/calendar+json"));

// e.g., assign *own* MyCodec implementation (implementing ContentCodec interface)
cs.addCodec(new MyCodec("application/myType"));

TD Tooling

The package td-tools provides utilities around Thing Description (TD) tooling:

Logging

Logging in node-wot is implemented via the debug package. This allows users to enable log messages for specific logging levels (info, debug, warn, or error) or packages. Which log messages are emitted is controlled by the DEBUG environment variable.

In the following, we will show a couple of examples of its usage using wildcard characters (*). Note, however, that the syntax for setting an environment variable depends on your operating system and the terminal you use. See the debug documentation for more details on platform-specific differences.

First, you can enable all log messages by setting DEBUG to a wildcard like so:

DEBUG=* npm start

To only show node-wot-specific logging messages, prefix the wildcard with node-wot:

DEBUG=node-wot* npm start

To only show a specific log level, use one of info, debug, warn, or error as the suffix. Note in this context that you can provide multiple values for DEBUG. For example, if you want to show only debug and info messages, you can use the following:

DEBUG='*debug,*info' npm start

Finally, you can choose to only display log messages from a specific node-wot package. For example, if you only want to see log messages for the core package, use the following:

DEBUG=node-wot:core* npm start

Using the log levels above, you can also apply more fine-grained parameters for logging. For instance, if you only want to see error messages from the binding-coap package, use this:

DEBUG=node-wot:binding-coap*error npm start

Install new/different versions of Node.js

Using NPM, you can install Node.js 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

Contributing

Please check out our contributing guidelines for more details.

License

Dual-licensed under:

Pick one of these two licenses that fits your needs. Please also see the additional notices and how to contribute.

Development Internals

details

Publishing on NPM

Run npm publish --workspaces in root node-wot folder.

Regenerating package-lock.json

  1. Delete package-lock.json file
  2. Delete any local cache (like node_modules folders etc.)
  3. Run npm install
  4. Run npm dedupe (see #765 (comment))

node-wot's People

Contributors

6d77 avatar citrullin avatar ctron avatar danielpeintner avatar dependabot[bot] avatar derwehr avatar egekorkan avatar erkann-sen avatar erossignon avatar fadysalama avatar fatadel avatar fillobotto avatar hasanheroglu avatar hasbel avatar hidetak avatar iomz avatar jkrhb avatar johannesmerkt avatar joshco avatar justus237 avatar kaz040 avatar lennyhevs avatar lukesmolo avatar martinmeyer1 avatar miguelrk avatar mkovatsc avatar relu91 avatar sebastiankb avatar timkam avatar wiresio avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

node-wot's Issues

http-client-factory.js null check missing

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

Error in coap-servient example

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.

op field in generated Thing Descriptions

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.

Updating name and description

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.

binding-file: replace deprecated new Buffer

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.

Thing level forms does not include op

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.

http client assumes http:methodName and does not look at @context

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.

core/content-serdes.ts: provide more information to ContentCodecs

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.

How to configure CoAPS security?

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

ExposedThingProperty.write() does not handle rejected promises

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.

Running example script fails with "Unexpected token export" error

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)

WoT.fetch(): contentType check always returns false

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.

Flag "writeable" for properties seems to be broken

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.

Logging

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)

Document version of Node.js used

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

wot-typescript-definitions should be in dependencies

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.

How to install new/different versions of NodeJS, e.g., on Raspberry Pi?

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

node-wot metrics

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.

error when running build

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.

How to configure API key in HTTP header field?

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

CORS pre-flight requests are rejected

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.

TD alignments for F2F Princeton

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

Proposal for a new td-generator.ts implementation in @node-wot/core

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?

CLI does not correctly read config files

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.

Node.js 10 requirement and more issues?

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)

CoAP binding (Client) blocks in case of no answer from server

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.

Configuration of Protocol Bindings for the cli (`wot-servient`)

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?

No matching format found error when sending CoAP GET

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.