style: npm run format

Author: danielpeintner

CODE_OF_CONDUCT.md

@@ -11,19 +11,19 @@ In the interest of fostering an open and welcoming environment, we as community
 
 Examples of behavior that contributes to creating a positive environment include:
 
--   Using welcoming and inclusive language
--   Being respectful of differing viewpoints and experiences
--   Gracefully accepting constructive criticism
--   Focusing on what is best for the community
--   Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
--   The use of sexualized language or imagery and unwelcome sexual attention or advances
--   Trolling, insulting/derogatory comments, and personal or political attacks
--   Public or private harassment
--   Publishing others' private information, such as a physical or electronic address, without explicit permission
--   Other conduct which could reasonably be considered inappropriate in a professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
 

NOTICE.md

@@ -2,7 +2,7 @@
 
 This content is produced and maintained by the Eclipse Thingweb project.
 
--   Project home: https://projects.eclipse.org/projects/iot.thingweb
+- Project home: https://projects.eclipse.org/projects/iot.thingweb
 
 ## Trademarks
 

examples/quickstart/README.md

@@ -3,8 +3,8 @@
 This set of Things can be used to build mashup applications for a smart home scenario.
 These Things are:
 
--   Simple coffee machine that can take an order to brew a coffee.
--   Presence sensor that emits an event when a person is detected.
--   Smart clock that runs 60 times faster than real time, where 1 hour happens in 1 minute.
+- Simple coffee machine that can take an order to brew a coffee.
+- Presence sensor that emits an event when a person is detected.
+- Smart clock that runs 60 times faster than real time, where 1 hour happens in 1 minute.
 
 These Things are hosted on plugfest.thingweb.io but can be also self-hosted.

examples/templates/exposed-thing/README.md

@@ -14,8 +14,8 @@ In the following examples, how to use the CoAP binding of node-wot is shown.
 
 ### Prerequisites
 
--   `npm install @node-wot/core`
--   `npm install @node-wot/binding-coap`
+- `npm install @node-wot/core`
+- `npm install @node-wot/binding-coap`
 
 ### Client Example
 

packages/binding-coap/README.md

@@ -10,9 +10,9 @@ In the following examples, how to use the File binding of node-wot is shown.
 
 ### Prerequisites
 
--   `npm install @node-wot/core`
--   `npm install @node-wot/binding-file`
--   local test file `test.txt` with content
+- `npm install @node-wot/core`
+- `npm install @node-wot/binding-file`
+- local test file `test.txt` with content
 
 ### Example 1
 
@@ -75,7 +75,7 @@ The example tries to load a locally stored TestThing TD and reads the `fileConte
 
 ### Prerequisites
 
--   local TD file `TD.jsonld` with content as in Example 1
+- local TD file `TD.jsonld` with content as in Example 1
 
 `node example2.js`
 

packages/binding-file/README.md

@@ -14,8 +14,8 @@ In the following examples, how to use the HTTP binding of node-wot is shown.
 
 ### Prerequisites
 
--   `npm install @node-wot/core`
--   `npm install @node-wot/binding-http`
+- `npm install @node-wot/core`
+- `npm install @node-wot/binding-http`
 
 ### Client Example
 
@@ -373,11 +373,11 @@ servient.start().then(async (WoT) => {
 
 **Symbols** :
 
--   Y implemented
--   N not implement and not planned
--   N.A not applicable
--   ? need to be verified
--   P planned
+- Y implemented
+- N not implement and not planned
+- N.A not applicable
+- ? need to be verified
+- P planned
 
 ## More Details
 

packages/binding-http/README.md

@@ -43,11 +43,11 @@ mbus+tcp:// <host> [ : <port> ] [/ <unitid> [ ?offset=<offset> [&timeout=<timeou
 
 with the following meaning:
 
--   `<host>` is the host name or IP address of the M-Bus slave
--   `<port>` is the optional TCP port number used to access the M-Bus slave. Default is 805
--   `<unitid>` is the M-Bus unit id of the M-Bus slave; same as [mbus:unitID](#mbus:unitID)
--   `<offset>` is the id of the data; see [mbus:offset](#mbus:offset)
--   `<timeout>` is the optional timeout in milliseconds of the request. Default is 1000; see [mbus:timeout](#mbus:timeout)
+- `<host>` is the host name or IP address of the M-Bus slave
+- `<port>` is the optional TCP port number used to access the M-Bus slave. Default is 805
+- `<unitid>` is the M-Bus unit id of the M-Bus slave; same as [mbus:unitID](#mbus:unitID)
+- `<offset>` is the id of the data; see [mbus:offset](#mbus:offset)
+- `<timeout>` is the optional timeout in milliseconds of the request. Default is 1000; see [mbus:timeout](#mbus:timeout)
 
 When specified URL values override the corresponding `form` parameter.
 
@@ -78,8 +78,8 @@ The protocol does not support security.
 
 This implementation handles multiple requests to the same slave by combining them if possible. In the following, the terms **request** and **transaction** are used as follows to describe this:
 
--   A **request** is a read request to a resource as issued by a user of the node-wot API.
--   A **transaction** is a M-Bus operation and may cover the data of multiple **requests**.
+- A **request** is a read request to a resource as issued by a user of the node-wot API.
+- A **transaction** is a M-Bus operation and may cover the data of multiple **requests**.
 
 ## Combination
 
@@ -108,8 +108,8 @@ Reads the data with the id of 1 of the unit 2
 
 ## TODOs
 
--   [ ] TEST
--   [ ] (M-Bus Server Protocol Binding)
+- [ ] TEST
+- [ ] (M-Bus Server Protocol Binding)
 
 ## More Details
 

packages/binding-mbus/README.md

@@ -104,11 +104,11 @@ modbus+tcp:// <host> [ : <port> ] [/ <unitid> [ / <address> ] [&quantity=<quanti
 
 with the following meaning:
 
--   `<host>` is the hostname or IP address of the MODBUS slave
--   `<port>` is the optional TCP port number used to access the MODBUS slave. Default is 502
--   `<unitid>` is the MODBUS unit id of the MODBUS slave; same as [modv:unitID](#modv:unitID)
--   `<address>` is the starting address register number; see [modv:address](#modv:address)
--   `<quantity>` is the optional number of registers to access. Default is 1; see [modv:quantity](#modv:quantity)
+- `<host>` is the hostname or IP address of the MODBUS slave
+- `<port>` is the optional TCP port number used to access the MODBUS slave. Default is 502
+- `<unitid>` is the MODBUS unit id of the MODBUS slave; same as [modv:unitID](#modv:unitID)
+- `<address>` is the starting address register number; see [modv:address](#modv:address)
+- `<quantity>` is the optional number of registers to access. Default is 1; see [modv:quantity](#modv:quantity)
 
 When specified URL values override the corresponding `form` parameter.
 
@@ -118,19 +118,19 @@ The MODBUS binding uses and provides plain binary data for reading and writing.
 
 Along with content type `application/octet-stream`, this protocol binding accepts also an optional `byteSeq` parameter. `byteSeq` specifies the endian-ness of the raw byte data being read/written by the MODBUS binding. It follows the notation `application/octet-stream;byteSeq=value`, where its value can be one of the following:
 
--   `BIG_ENDIAN`, which is the default value
--   `LITTLE_ENDIAN`
--   `BIG_ENDIAN_BYTE_SWAP`
--   `LITTLE_ENDIAN_BYTE_SWAP`
+- `BIG_ENDIAN`, which is the default value
+- `LITTLE_ENDIAN`
+- `BIG_ENDIAN_BYTE_SWAP`
+- `LITTLE_ENDIAN_BYTE_SWAP`
 
 **Note**: the list above may be extended in the future.
 
 In particular, the decimal numbers `9545` and `22880` will be encoded as follows:
 
--   `BIG_ENDIAN`: `25 49 59 60`
--   `LITTLE_ENDIAN`: `60 59 49 25`
--   `BIG_ENDIAN_BYTE_SWAP`: `49 25 60 59`
--   `LITTLE_ENDIAN_BYTE_SWAP`: `59 60 25 49`
+- `BIG_ENDIAN`: `25 49 59 60`
+- `LITTLE_ENDIAN`: `60 59 49 25`
+- `BIG_ENDIAN_BYTE_SWAP`: `49 25 60 59`
+- `LITTLE_ENDIAN_BYTE_SWAP`: `59 60 25 49`
 
 For register resources, the payload is just the plain sequence of bytes read from or written to the registers. For coils and discrete inputs, the payload is a sequence of bytes, each corresponding to a single coil or discrete input. Each byte contains the value `0` or `1`. So the encoder and decoder should work on this series of bytes and does not have to take care about handling the individual bits. Mapping each coil or discrete input to a single property of type `boolean` works just fine.
 
@@ -145,8 +145,8 @@ The protocol does not support security.
 
 This implementation handles multiple requests to the same slave by serializing and combining them if possible. In the following, the terms **request** and **transaction** are used as follows to describe this:
 
--   A **request** is a read or write request to a resource as issued by a user of the node-wot API.
--   A **transaction** is a Modbus operation and may cover the data of multiple **requests**.
+- A **request** is a read or write request to a resource as issued by a user of the node-wot API.
+- A **transaction** is a Modbus operation and may cover the data of multiple **requests**.
 
 ### Combination
 
@@ -221,14 +221,14 @@ Polls the 8th holding register of the unit 1 every second.
 
 ## TODOs
 
--   [x] TEST
--   [ ] (Modbus Server Protocol Binding)
--   [x] Connection pooling
--   [ ] More sophisticated algorithm for combining requests. Some ideas
-    -   Not only append or prepend requests to transactions, but also combine transactions which become neighboured later on
-    -   Impose some limit to the overall number of registers. The MODBUS protocol has such a limit and devices may define even lower values
--   [ ] When a connection times out, re-connection does not work (see `connectionTimeout` in modbus-client.ts)
--   [x] When a Modbus device is not reachable, scripts using binding-modbus stop working - corresponding error handling is necessary
+- [x] TEST
+- [ ] (Modbus Server Protocol Binding)
+- [x] Connection pooling
+- [ ] More sophisticated algorithm for combining requests. Some ideas
+    - Not only append or prepend requests to transactions, but also combine transactions which become neighboured later on
+    - Impose some limit to the overall number of registers. The MODBUS protocol has such a limit and devices may define even lower values
+- [ ] When a connection times out, re-connection does not work (see `connectionTimeout` in modbus-client.ts)
+- [x] When a Modbus device is not reachable, scripts using binding-modbus stop working - corresponding error handling is necessary
 
 ## More Details
 

packages/binding-modbus/README.md

@@ -16,8 +16,8 @@ In the following examples it is shown how to use the MQTT binding of node-wot.
 
 ### Prerequisites
 
--   `npm install @node-wot/core`
--   `npm install @node-wot/binding-mqtt`
+- `npm install @node-wot/core`
+- `npm install @node-wot/binding-mqtt`
 
 ### MQTT Thing Example I
 
@@ -182,10 +182,10 @@ There are example implementations provided in the [example/scripting folder](htt
 
 Please setup node-wot as described at the [node-wot main page](https://github.com/eclipse-thingweb/node-wot#as-a-standalone-application).
 
--   example-mqtt-publish.js: Shows when node-wot acts as a MQTT Client that publishes data (latest counter value) to a broker.
-    At the same time, another client can invoke an action, such as `resetCounter`, by sending a publication message to the topic of this action.
-    This other client does not have to be node-wot, any MQTT client can interact with this Thing.
-    For node-wot clients, make sure to provide MQTT broker details (`host`, `port`, `username`, `password`, `clientId`) in the wot-servient.conf.json:
+- example-mqtt-publish.js: Shows when node-wot acts as a MQTT Client that publishes data (latest counter value) to a broker.
+  At the same time, another client can invoke an action, such as `resetCounter`, by sending a publication message to the topic of this action.
+  This other client does not have to be node-wot, any MQTT client can interact with this Thing.
+  For node-wot clients, make sure to provide MQTT broker details (`host`, `port`, `username`, `password`, `clientId`) in the wot-servient.conf.json:
 
 ```js
 {
@@ -202,7 +202,7 @@ Please setup node-wot as described at the [node-wot main page](https://github.co
 
 Start the script by the command `wot-servient mqtt-publish.js` or `node ../../packages/cli/dist/cli.js mqtt-publish.js`.
 
--   example-mqtt-subscription.js: Shows how node-wot consumes a Thing Description to do MQTT subscription on the provided event (=latest counter value) as well as initiate the action (reset counter).
+- example-mqtt-subscription.js: Shows how node-wot consumes a Thing Description to do MQTT subscription on the provided event (=latest counter value) as well as initiate the action (reset counter).
 
 Start the script by the command `wot-servient -c mqtt-subscribe.js` or `node ../../packages/cli/dist/cli.js -c mqtt-subscribe.js`.