fix: fix typos in documentation

.github/bot-scripts/importConfigCreatePR.js

@@ -58,7 +58,7 @@ async function main(param) {
 
 If anyone feels compelled to help out, please follow these steps:
 
-- Fork this respository if you haven't already. If you have, synchronize your fork so you get a copy of the new branch.
+- Fork this repository if you haven't already. If you have, synchronize your fork so you get a copy of the new branch.
 - Make the necessary changes in the branch \`${process.env.branchname}\` in your fork
 - Create a pull request with your branch \`${process.env.branchname}\` as the source and our branch \`${process.env.branchname}\` as the target.
 

.github/workflows/dependency-review.yml

@@ -1,6 +1,6 @@
 # Dependency Review Action
 #
-# This Action will scan dependency manifest files that change as part of a Pull Reqest, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
+# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
 #
 # Source repository: https://github.com/actions/dependency-review-action
 # Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement

docs/api/controller.md

@@ -39,7 +39,7 @@ The options parameter is used to specify the inclusion strategy and provide call
     **Not recommended**, because S2 should be used where possible.
 
 -   `InclusionStrategy.Security_S0`: Use _Security S0_, even if a higher security mode is supported. Issues a warning if _Security S0_ is not supported or the secure bootstrapping fails.  
-    **Not recommended** because S0 should be used sparingly and S2 preferred whereever possible.
+    **Not recommended** because S0 should be used sparingly and S2 preferred wherever possible.
 
 -   `InclusionStrategy.Security_S2`: Use _Security S2_ and issue a warning if it is not supported or the secure bootstrapping fails.  
     **Not recommended** because `Default` is more versatile and less complicated for the user.
@@ -892,7 +892,7 @@ enum InclusionState {
 
 ## Controller events
 
-The `Controller` class inherits from the Node.js [EventEmitter](https://nodejs.org/api/events.html#events_class_eventemitter) and thus also supports its methods like `on`, `removeListener`, etc. The available events are avaiable:
+The `Controller` class inherits from the Node.js [EventEmitter](https://nodejs.org/api/events.html#events_class_eventemitter) and thus also supports its methods like `on`, `removeListener`, etc. The available events are available:
 
 ### `"inclusion started"`
 

docs/api/driver.md

@@ -10,7 +10,7 @@ new (port: string, options?: ZWaveOptions) => Driver
 
 The first constructor argument is the address of the serial port. On Windows, this is similar to `"COM3"`. On Linux this has the form `/dev/ttyAMA0` (or similar). Alternatively, you can connect to a serial port that is hosted over TCP (for example with the `ser2net` utility), see [Connect to a hosted serial port over TCP](usage/tcp-connection.md).
 
-For more control, the constructor accepts an optional options object as the second argument. See [`ZWaveOptions`](#ZWaveOptions) for a detailed desription.
+For more control, the constructor accepts an optional options object as the second argument. See [`ZWaveOptions`](#ZWaveOptions) for a detailed description.
 
 ## Driver methods
 
@@ -795,5 +795,5 @@ For more control over writing the cache files, you can use the `storage` options
 The `throttle` option allows you to fine-tune the filesystem. The default value is `"normal"`.
 Note that the lockfiles to avoid concurrent cache accesses are updated every couple of seconds. If you have concerns regarding SD card wear, you can change the `lockDir` option to point a directory that resides in a RAM filesystem.
 
-For custom logging options you can use `logConfig`, check [`LogConfig`](#LogConfig) interface for more informations.
+For custom logging options you can use `logConfig`, check [`LogConfig`](#LogConfig) interface for more information.
 The logging options can be changed on the fly using the [`updateLogConfig`](#updateLogConfig) method.

docs/api/endpoint.md

@@ -126,7 +126,7 @@ If the `Z-Wave+` Command Class is supported, this returns the icon to be shown t
 readonly commandClasses(): CCAPIs
 ```
 
-This property provides access to simplified APIs that are taylored to specific CCs.
+This property provides access to simplified APIs that are tailored to specific CCs.
 
 Make sure to check support of each API using `API.isSupported()` before using it, since all other API calls will throw if the API is not supported. Example:
 

docs/api/node.md

@@ -900,7 +900,7 @@ When configuring devices or during longer message exchanges, this behavior may b
 
 ## ZWaveNode events
 
-The `Node` class inherits from the Node.js [EventEmitter](https://nodejs.org/api/events.html#events_class_eventemitter) and thus also supports its methods like `on`, `removeListener`, etc. The available events are avaiable:
+The `Node` class inherits from the Node.js [EventEmitter](https://nodejs.org/api/events.html#events_class_eventemitter) and thus also supports its methods like `on`, `removeListener`, etc. The following events are available:
 
 ### `"wake up"` / `"sleep"`
 

docs/api/valueid.md

@@ -60,7 +60,7 @@ interface ValueMetadataAny {
 
 -   `type`: The type of the value. Can be: `any`, `number`, `boolean`, `string`, `number[]`, `string[]`, `boolean[]`. Depending on the `type`, each metadata can have additional properties (see below).
 -   `readable`: Whether the value can be read. Default: `true`
--   `writable`: Wheather a value can be written. Default: `true`
+-   `writable`: Whether a value can be written. Default: `true`
 -   `description`: A description of the value
 -   `label`: A human-readable label for the property
 -   `ccSpecific`: CC specific information to help identify this value [(see below)](#CC-specific-fields)
@@ -90,7 +90,7 @@ interface ValueMetadataNumeric extends ValueMetadataAny {
 }
 ```
 
--   `min`: The minumum value that can be assigned to this value
+-   `min`: The minimum value that can be assigned to this value
 -   `max`: The maximum value that can be assigned to this value
 -   `steps`: When only certain values between min and max are allowed, this determines the step size
 -   `default`: The default value

docs/config-files/file-format.md

@@ -395,7 +395,7 @@ Many devices unnecessarily use endpoints when they could (or do) provide all fun
 
 ### `preserveRootApplicationCCValueIDs`
 
-The Z-Wave+ specs mandate that the root endpoint must **mirror** the application functionality of endpoint 1 (and potentially others). For this reason, `zwave-js` hides these superfluous values. However, some legacy devices offer additional functionality through the root endpoint, which should not be hidden. To achive this, set `preserveRootApplicationCCValueIDs` to `true`.
+The Z-Wave+ specs mandate that the root endpoint must **mirror** the application functionality of endpoint 1 (and potentially others). For this reason, `zwave-js` hides these superfluous values. However, some legacy devices offer additional functionality through the root endpoint, which should not be hidden. To achieve this, set `preserveRootApplicationCCValueIDs` to `true`.
 
 ### `skipConfigurationNameQuery`
 

docs/config-files/style-guide.md

@@ -81,7 +81,7 @@ The primary reporting group (usually group 1 for Z-Wave Plus) **must** be called
 
 Shorten labels wherever possible. E.g. `Threshold at which to send a battery report` becomes `Battery Report Threshold`.
 
-Labels should be clear and concise. They should clearly explain what the parameter does while avoiding unnnecessary technical jargon:
+Labels should be clear and concise. They should clearly explain what the parameter does while avoiding unnecessary technical jargon:
 
 ?> Labels should be **Title Case**.
 

docs/config-files/using-templates.md

@@ -312,7 +312,7 @@ Templates defined in the manufacturer-specific template should be built on top o
 	"enable_deadbolt_alarm": {
 		"$import": "../../templates/master_template.json#base_enable_disable",
 		"label": "Deadbolt Alarm",
-		"defaultValue": 1 // Note that ordinarily 0 is the default value for the base, but this paramter requires a default of 1.
+		"defaultValue": 1 // Note that ordinarily 0 is the default value for the base, but this parameter requires a default of 1.
 	},
 ```
 

docs/getting-started/migrating-to-v6.md

@@ -8,7 +8,7 @@ The environment variables for logging are no longer evaluated lazily, so they no
 
 ## Updated `interview failed` event handler signature
 
-The second parameter (`errorMessage: string`) was replaced with an [object parameter](api/node?id=quotinterview-failedquot) that was previously the optional third parameter. If you are using the legacy signature with two params, replace the occurences of the error message with `args.errorMessage`. If you are using the transitional signature with three params, remove the second parameter.
+The second parameter (`errorMessage: string`) was replaced with an [object parameter](api/node?id=quotinterview-failedquot) that was previously the optional third parameter. If you are using the legacy signature with two params, replace the occurrences of the error message with `args.errorMessage`. If you are using the transitional signature with three params, remove the second parameter.
 
 ## New `"value notification"` event
 

docs/getting-started/philosophy.md

@@ -27,13 +27,13 @@ Other Z-Wave drivers work around many more issues, sometimes going as far as pro
 This may sound cynical but I don't think this should be done at all.
 Buggy devices should really become a problem of the manufacturers who release them and don't offer any support whatsoever. The huge bunch of workarounds that other drivers implemented make it too easy for manufacturers to reject responsibility and claim _"But it works in XYZ, cannot be our fault!"_
 
-I can understand the sentiment of making things work when you're using unofficial APIs etc, but Z-Wave is a standard, devices have to be certified and still too many devices with non-compliant behavior slip through the cracks - partially empowered by softwares with workarounds.
+I can understand the sentiment of making things work when you're using unofficial APIs etc, but Z-Wave is a standard, devices have to be certified and still too many devices with non-compliant behavior slip through the cracks - partially empowered by software with workarounds.
 
 Only when we **stop solving the manufacturers' mistakes for them** and make them fix them, then we can get to a point where it becomes a benefit for the smart home community. Many issues I keep seeing would have been caught by QA if they bothered to test it at all, e.g.:
 
 -   RGB controllers that are missing the blue channel from their list of supported colors
 -   Thermostats with off-by-one errors, leading to the wrong scales/units being advertised (or none at all)
--   Power meters that randomly flip the most siginificant bit in their reports
+-   Power meters that randomly flip the most significant bit in their reports
 
 Unfortunately, I can't make manufacturers do that, but I can take a stance and choose not to fix their mistakes (and neither should the other projects), even if it is annoying for users.
 But maybe **having a majority of their users complain** because their stuff does not work with a standards-compliant software will change that mentality:

docs/getting-started/security-s2.md

@@ -113,7 +113,7 @@ This dialog MUST be shown when `zwave-js` calls the `validateDSKAndEnterPIN` use
 
 ### Confirming the inclusion process
 
-Security bootstrapping (exchanging keys) happens after a node was included into the network. Since things can go wrong here (including timeouts during user interaction), a node can end up with a lower security class than intended. The `"node added"` event callback contains this infomation:
+Security bootstrapping (exchanging keys) happens after a node was included into the network. Since things can go wrong here (including timeouts during user interaction), a node can end up with a lower security class than intended. The `"node added"` event callback contains this information:
 
 ```ts
 driver.controller.on("node added", (node, result) => {