knx.ts 1.0.1 → 1.0.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +51 -21
- package/README.md +274 -61
- package/dist/@types/interfaces/connection.d.ts +80 -13
- package/dist/@types/interfaces/servers.d.ts +18 -0
- package/dist/@types/interfaces/servers.js +2 -0
- package/dist/connection/KNXService.d.ts +13 -30
- package/dist/connection/KNXService.js +4 -164
- package/dist/connection/KNXTunneling.d.ts +4 -4
- package/dist/connection/KNXTunneling.js +35 -62
- package/dist/connection/KNXUSBConnection.d.ts +20 -0
- package/dist/connection/KNXUSBConnection.js +358 -0
- package/dist/connection/KNXnetIPServer.d.ts +29 -12
- package/dist/connection/KNXnetIPServer.js +261 -83
- package/dist/connection/Router.d.ts +52 -32
- package/dist/connection/Router.js +225 -153
- package/dist/connection/TPUART.d.ts +8 -3
- package/dist/connection/TPUART.js +41 -37
- package/dist/connection/TunnelConnection.d.ts +3 -1
- package/dist/connection/TunnelConnection.js +6 -4
- package/dist/core/CEMI.d.ts +7 -2
- package/dist/core/CEMI.js +5 -8
- package/dist/core/EMI.d.ts +312 -200
- package/dist/core/EMI.js +511 -1007
- package/dist/core/KNXnetIPStructures.d.ts +10 -1
- package/dist/core/KNXnetIPStructures.js +15 -10
- package/dist/core/MessageCodeField.d.ts +1 -1
- package/dist/core/cache/GroupAddressCache.d.ts +57 -0
- package/dist/core/cache/GroupAddressCache.js +227 -0
- package/dist/core/data/KNXDataDecode.d.ts +2 -2
- package/dist/core/data/KNXDataDecode.js +198 -183
- package/dist/core/enum/EnumControlField.d.ts +0 -5
- package/dist/core/enum/EnumControlField.js +1 -7
- package/dist/core/enum/EnumControlFieldExtended.d.ts +1 -1
- package/dist/core/enum/EnumShortACKFrame.d.ts +1 -1
- package/dist/core/enum/ErrorCodeSet.js +59 -0
- package/dist/core/enum/KNXnetIPEnum.d.ts +2 -2
- package/dist/core/enum/KNXnetIPEnum.js +19 -1
- package/dist/core/layers/data/NPDU.d.ts +2 -1
- package/dist/core/layers/data/NPDU.js +6 -3
- package/dist/index.d.ts +19 -2
- package/dist/index.js +36 -1
- package/dist/server/KNXMQTTGateway.d.ts +13 -0
- package/dist/server/KNXMQTTGateway.js +164 -0
- package/dist/server/KNXWebSocketServer.d.ts +12 -0
- package/dist/server/KNXWebSocketServer.js +118 -0
- package/dist/utils/CEMIAdapter.d.ts +4 -3
- package/dist/utils/CEMIAdapter.js +26 -30
- package/dist/utils/Logger.d.ts +4 -4
- package/dist/utils/Logger.js +3 -7
- package/package.json +28 -8
package/LICENSE
CHANGED
|
@@ -1,21 +1,51 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.
|
|
10
|
+
|
|
11
|
+
"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.
|
|
12
|
+
|
|
13
|
+
"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
|
|
14
|
+
|
|
15
|
+
"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.
|
|
16
|
+
|
|
17
|
+
"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.
|
|
18
|
+
|
|
19
|
+
"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
|
|
20
|
+
|
|
21
|
+
"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).
|
|
22
|
+
|
|
23
|
+
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
|
|
24
|
+
|
|
25
|
+
"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."
|
|
26
|
+
|
|
27
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.
|
|
28
|
+
|
|
29
|
+
2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
|
|
30
|
+
|
|
31
|
+
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
|
|
32
|
+
|
|
33
|
+
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
|
|
34
|
+
|
|
35
|
+
You must give any other recipients of the Work or Derivative Works a copy of this License; and
|
|
36
|
+
You must cause any modified files to carry prominent notices stating that You changed the files; and
|
|
37
|
+
You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
|
|
38
|
+
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
|
|
39
|
+
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
|
|
40
|
+
|
|
41
|
+
5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.
|
|
42
|
+
|
|
43
|
+
6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
|
|
44
|
+
|
|
45
|
+
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
|
|
46
|
+
|
|
47
|
+
8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
|
|
48
|
+
|
|
49
|
+
9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
|
|
50
|
+
|
|
51
|
+
END OF TERMS AND CONDITIONS
|
package/README.md
CHANGED
|
@@ -1,32 +1,88 @@
|
|
|
1
1
|
# knx.ts
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Spanish version: see [readme-es.md](./readme-es.md).
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
A high-performance **KNXnet/IP** and **Hardware Interface** library such as **HID USB** and **TPUART**, written in **TypeScript**.
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
7
|
+
This project focuses on protocol strictness, reading and sending any kind of **EMI** or **CEMI** message, broad DPT (Data Point Type) support, connection stability, and direct hardware integration, specifically optimized to provide a reliable experience when used as a Gateway for ETS or as a core for custom KNX controllers.
|
|
8
|
+
|
|
9
|
+
## 🌟 Capabilities
|
|
10
|
+
|
|
11
|
+
- **Robust UDP Tunneling**: Implements a strict *Stop-and-Wait* queue and sequence number management. This eliminates common "connection interrupted" issues in ETS or other applications during long sessions.
|
|
12
|
+
- **KNXnet/IP Routing**: Supports multicast routing (only in the **KNXnet/IP** server).
|
|
13
|
+
- **Discovery in the KNXnet/IP server**: Supports `SEARCH_REQUEST`, `SEARCH_REQUEST_EXTENDED`, `DESCRIPTION_REQUEST`, `CONNECT_REQUEST`, and `CONNECTIONSTATE_REQUEST` so applications such as ETS can discover it without manual configuration.
|
|
14
|
+
- **Direct Hardware Interfaces**: Native support for **KNX USB interfaces** (via `node-hid`) and **TPUART** serial chips (via `serialport`).
|
|
15
|
+
- **Learning Bridge (Router)**: Advanced multi-interface routing with Loop Prevention, Signature Tracking, and Individual Address (IA) learning, allowing you to bridge multiple physical interfaces and tunnels simultaneously.
|
|
9
16
|
- **Intuitive Address-Based Events**: Listen to specific telegrams using group addresses as event names (e.g., `server.on("1/1/1", ...)`).
|
|
10
|
-
- **Echo Cancellation**: Automatically filters
|
|
17
|
+
- **Echo Cancellation**: Automatically filters loopback messages to prevent telegram processing loops.
|
|
11
18
|
- **High Performance**: Optimized for Node.js environments with minimal overhead.
|
|
12
19
|
|
|
13
|
-
## 🚧 Status: Experimental
|
|
20
|
+
## 🚧 Status: Experimental and In Development
|
|
14
21
|
|
|
15
|
-
|
|
22
|
+
According to `TODO.md`, several features are currently **experimental** or under development:
|
|
16
23
|
|
|
17
|
-
- **TCP Support**:
|
|
18
|
-
- **
|
|
19
|
-
- **Advanced Routing**: Complex routing between multiple Tunnels and TPUART via the `Router` class is under evaluation.
|
|
20
|
-
- **Device Parameterization**: Support for *Programming Mode* (progMode) is planned to allow full device configuration via ETS.
|
|
24
|
+
- **TCP Support**: The implementation is present, but testing is currently in an experimental phase.
|
|
25
|
+
- **Device Parameterization**: Support for *Programming Mode* (`progMode`) is planned to allow full device configuration through ETS.
|
|
21
26
|
- **Source Filtering**: Filtering based on source addresses and selective routing is on the roadmap.
|
|
27
|
+
- **Use of NPDU, TPDU, and APDU layers**: EMI still needs to use them for correct deserialization.
|
|
22
28
|
|
|
23
|
-
## 📦 Installation
|
|
29
|
+
## 📦 Installation via git
|
|
24
30
|
|
|
25
31
|
```bash
|
|
26
32
|
git clone https://github.com/Wesxt/KNX.ts.git
|
|
27
33
|
cd KNX.ts
|
|
34
|
+
npm install
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## 📦 Installation via npm
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
npm install knx.ts
|
|
28
41
|
```
|
|
29
42
|
|
|
43
|
+
## 🧩 External Dependencies
|
|
44
|
+
|
|
45
|
+
This library depends on a few key modules, both external and native, to enable its full functionality:
|
|
46
|
+
|
|
47
|
+
- **[Pino](https://getpino.io/)**: Used as the central logging engine. It is highly efficient, and the library exports a singleton logger so your application can share the same instance without overhead.
|
|
48
|
+
- **[node-hid](https://github.com/node-hid/node-hid)**: Used by `KNXUSBConnection` to interact natively with KNX USB interfaces. Keep in mind that native modules may require build tools on some operating systems.
|
|
49
|
+
- **[serialport](https://serialport.io/)**: Used by `TPUARTConnection` for direct UART communication. Like `node-hid`, this is a native module.
|
|
50
|
+
|
|
51
|
+
## 📚 API Reference (What is exported)
|
|
52
|
+
|
|
53
|
+
The library exposes a rich set of classes and utilities that allow both high-level usage and low-level protocol manipulation:
|
|
54
|
+
|
|
55
|
+
### 1. Connections and Gateways
|
|
56
|
+
|
|
57
|
+
These classes form the core of your interaction with the network. All of them inherit from a `KNXService` base and emit common events.
|
|
58
|
+
|
|
59
|
+
- `KNXnetIPServer`: Creates a standard KNXnet/IP server (Gateway). Perfect for providing tunneling slots to ETS or other tunneling clients.
|
|
60
|
+
- `KNXTunneling`: Connects as a client to an existing KNXnet/IP gateway.
|
|
61
|
+
- `KNXUSBConnection`: Connects directly to local KNX USB interfaces (ABB, MDT, Weinzierl, Zennio, etc.).
|
|
62
|
+
- `TPUARTConnection`: Connects directly to KNX through TPUART serial hardware.
|
|
63
|
+
- `Router`: A powerful bridge that interconnects different hardware connections or tunneling clients (**KNXUSBConnection**). You can attach multiple `KNXService` instances to it (e.g., one USB connection and 5 tunnels), and it will automatically route telegrams between them, handling Individual Address learning and loop prevention.
|
|
64
|
+
|
|
65
|
+
### 2. Data Conversion (DPTs)
|
|
66
|
+
|
|
67
|
+
- `KnxDataDecode`: Static utility to decode raw `Buffer` payloads into standard JavaScript/TypeScript types (e.g., numbers, booleans) depending on the KNX Data Point Type (DPT).
|
|
68
|
+
- `KnxDataEncoder`: Static utility to encode JavaScript/TypeScript values back into `Buffer` chunks ready to be sent onto the KNX bus.
|
|
69
|
+
|
|
70
|
+
### 3. Core KNX Frames and Types
|
|
71
|
+
|
|
72
|
+
For developers building advanced monitoring or injection tools, the library exports the entire internal frame structure:
|
|
73
|
+
|
|
74
|
+
- `CEMI` / `EMI` classes for parsing and serializing Common EMI and legacy EMI frames.
|
|
75
|
+
- `APDU`, `NPDU`, `TPDU` classes for manipulating the Network, Transport, and Application layers.
|
|
76
|
+
- `ControlField` to parse and serialize the control field of CEMI or EMI messages.
|
|
77
|
+
- `ExtendedControlField` to parse and serialize the `Extended Control Field` or `Control Field 2` of CEMI messages.
|
|
78
|
+
- `AddressType` is an enum that helps identify the Address Type (AT) bit in `ExtendedControlField`, so you can know whether the destination address is group or individual.
|
|
79
|
+
- `APCI` parses and serializes APCI values hosted between TPDU and APDU data. You must be careful because APCI uses 10 bits and writes into the 2 least significant bits of the byte shared with TPCI, while the following bits may belong to APCI or be data depending on the frame.
|
|
80
|
+
- `APCIEnum` is an enum that helps write APCI values according to the specification. **Warning**: this enum assumes all commands inside it are 10-bit or 2-byte values within the `0x3FF` mask; those with 4-bit length are simply represented inside a `0x3C0` mask.
|
|
81
|
+
- `TPCI` parses and serializes TPCI values in the TPDU layer.
|
|
82
|
+
- `TPCIType` is an enum that helps write or identify TPCI values according to the specification.
|
|
83
|
+
- `DPTs`: the library exports interfaces such as `DPT5001` or `DPT1`. These interfaces are used by `KnxDataDecode` to return JavaScript objects and by `KnxDataEncoder` as parameter types to convert them into `Buffer`s.
|
|
84
|
+
- `ServiceMessage` is an interface implemented by all CEMI and EMI messages, and also by NPDU, TPDU, and APCI layers. This is useful because they all expose two helpful methods: `toBuffer` to serialize the instance into a buffer and `describe` to provide a human-readable view of the instance. **Note**: most exported classes in this library that do not implement this interface, such as `APCI`, still provide a `describe` method.
|
|
85
|
+
|
|
30
86
|
## 🛠️ Quick Start
|
|
31
87
|
|
|
32
88
|
### Create a KNXnet/IP Server (Gateway)
|
|
@@ -34,51 +90,72 @@ cd KNX.ts
|
|
|
34
90
|
Perfect for creating a bridge between your IP network and the KNX bus.
|
|
35
91
|
|
|
36
92
|
```typescript
|
|
37
|
-
import { KNXnetIPServer } from '
|
|
93
|
+
import { KNXnetIPServer, ServiceMessage, KnxDataDecode } from 'knx.ts';
|
|
38
94
|
|
|
39
95
|
const server = new KNXnetIPServer({
|
|
40
96
|
localIp: '192.168.1.50',
|
|
41
|
-
individualAddress: '1.1.0',
|
|
42
|
-
friendlyName: 'TypeScript KNX Gateway',
|
|
43
|
-
clientAddrs: '1.1.10:5' //
|
|
97
|
+
individualAddress: '1.1.0', // Be careful not to create conflicts
|
|
98
|
+
friendlyName: 'TypeScript KNX Gateway', // This name is shown in ETS
|
|
99
|
+
clientAddrs: '1.1.10:5' // Provides 5 tunneling slots starting from 1.1.10
|
|
44
100
|
});
|
|
45
101
|
|
|
46
102
|
server.connect().then(() => {
|
|
47
|
-
console.log('KNXnet/IP
|
|
103
|
+
console.log('The KNXnet/IP server is running');
|
|
48
104
|
});
|
|
49
105
|
|
|
50
|
-
// Specific
|
|
51
|
-
server.on('1/1/1', (cemi) => {
|
|
52
|
-
console.log('New data on 1/1/1:', cemi.TPDU.apdu.data);
|
|
106
|
+
// Specific listener for a Group Address
|
|
107
|
+
server.on('1/1/1', (cemi: ServiceMessage) => {
|
|
108
|
+
console.log('New data on 1/1/1:', cemi.TPDU.apdu.data); // Raw APDU data
|
|
109
|
+
console.log('Decoded data:', KnxDataDecode.decodeThis("1.001", cemi.TPDU.apdu.data)); // Converted JavaScript value
|
|
110
|
+
});
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
### Direct USB Connection
|
|
114
|
+
|
|
115
|
+
```typescript
|
|
116
|
+
import { KNXUSBConnection } from 'knx.ts';
|
|
117
|
+
|
|
118
|
+
const usb = new KNXUSBConnection({
|
|
119
|
+
// Omitting path/vendorId will automatically discover the first known KNX USB interface
|
|
120
|
+
});
|
|
121
|
+
|
|
122
|
+
usb.connect().then(() => {
|
|
123
|
+
console.log('Connected directly to the KNX USB interface');
|
|
124
|
+
});
|
|
125
|
+
|
|
126
|
+
usb.on('indication', (cemi) => {
|
|
127
|
+
console.log('USB telegram source:', cemi.sourceAddress);
|
|
53
128
|
});
|
|
54
129
|
```
|
|
55
130
|
|
|
56
131
|
### Tunneling Client
|
|
57
132
|
|
|
58
133
|
```typescript
|
|
59
|
-
import { KNXTunneling } from '
|
|
134
|
+
import { KNXTunneling } from 'knx.ts';
|
|
60
135
|
|
|
61
136
|
const tunnel = new KNXTunneling({
|
|
62
|
-
ip: '192.168.1.100',
|
|
137
|
+
ip: '192.168.1.100',
|
|
63
138
|
port: 3671,
|
|
64
139
|
localIp: '192.168.1.50'
|
|
65
140
|
});
|
|
66
141
|
|
|
67
142
|
tunnel.connect().then(() => {
|
|
68
|
-
console.log('Connected to KNX
|
|
143
|
+
console.log('Connected to the KNX bus');
|
|
69
144
|
});
|
|
70
145
|
```
|
|
71
146
|
|
|
72
147
|
## 📝 Logging
|
|
73
148
|
|
|
74
|
-
The library uses a global
|
|
149
|
+
The library uses a single global logger based on [Pino](https://getpino.io/). You can configure it at the beginning of your application using `setupLogger`.
|
|
150
|
+
|
|
151
|
+
This is important because you do not need to instantiate Pino yourself; the internal `knxLogger` manages its state to avoid the performance overhead of multiple instances.
|
|
75
152
|
|
|
76
153
|
```typescript
|
|
77
|
-
import { setupLogger, knxLogger } from '
|
|
154
|
+
import { setupLogger, knxLogger } from 'knx.ts';
|
|
78
155
|
|
|
79
156
|
// Configure the global logger
|
|
80
157
|
setupLogger({
|
|
81
|
-
level: 'debug', // e.g
|
|
158
|
+
level: 'debug', // e.g. 'info', 'warn', 'error', 'debug'
|
|
82
159
|
logToFile: true,
|
|
83
160
|
logDir: './logs',
|
|
84
161
|
});
|
|
@@ -87,103 +164,239 @@ setupLogger({
|
|
|
87
164
|
knxLogger.info("Application started");
|
|
88
165
|
```
|
|
89
166
|
|
|
90
|
-
All internal components (`KNXnetIPServer`, `KNXTunneling`, `Router`, etc.) automatically use this shared logger
|
|
167
|
+
All internal components (`KNXnetIPServer`, `KNXTunneling`, `Router`, etc.) automatically use this shared logger.
|
|
91
168
|
|
|
92
|
-
## 📡 Events
|
|
169
|
+
## 📡 Events and Callbacks
|
|
93
170
|
|
|
94
|
-
The library is event-driven.
|
|
171
|
+
The library is event-driven. Depending on the class you use, different events are emitted to provide detailed control and monitoring.
|
|
95
172
|
|
|
96
173
|
### Common Events
|
|
97
174
|
|
|
98
|
-
|
|
175
|
+
All connection classes (`KNXnetIPServer`, `KNXTunneling`, `KNXUSBConnection`, `TPUARTConnection`) inherit from `KNXService` and emit the following standard events:
|
|
99
176
|
|
|
100
177
|
| Event | Description | Callback Arguments |
|
|
101
|
-
|
|
102
|
-
| `connected` | Connection established and ready. | `void` (Server) / `{ channelId }` (Tunnel) |
|
|
103
|
-
| `disconnected` | Connection lost or closed. | `void` |
|
|
104
|
-
| `error` |
|
|
105
|
-
| `indication` | Any incoming KNX telegram (L_Data.ind). | `cemi:
|
|
178
|
+
|--------|-------------|-------------------------|
|
|
179
|
+
| `connected` | Connection established and hardware/socket ready. | `void` (Server/USB/TPUART) / `{ channelId }` (Tunnel) |
|
|
180
|
+
| `disconnected` | Connection lost or explicitly closed. | `void` |
|
|
181
|
+
| `error` | A fatal error occurred during operation. | `err: Error` |
|
|
182
|
+
| `indication` | Any incoming standard KNX telegram (cEMI / L_Data.ind). | `cemi: ServiceMessage` |
|
|
183
|
+
| `raw_indication`| The raw `Buffer` before parsing (EMI/cEMI/payload). | `data: Buffer` |
|
|
106
184
|
|
|
107
|
-
###
|
|
185
|
+
### Class-Specific Events
|
|
108
186
|
|
|
109
|
-
|
|
187
|
+
Depending on the connection type, some classes emit additional specific events:
|
|
110
188
|
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
})
|
|
115
|
-
|
|
189
|
+
#### **KNXnetIPServer**
|
|
190
|
+
|
|
191
|
+
- `queue_overflow`: Fired when the internal tunneling queue for a connected client overflows.
|
|
192
|
+
- `<GroupAddress>` (e.g., `"1/1/1"`): Listen directly to specific group addresses (e.g., `server.on("1/1/1", (cemi) => {...})`).
|
|
193
|
+
|
|
194
|
+
#### **TPUARTConnection**
|
|
195
|
+
|
|
196
|
+
- `busmonitor`: Emitted in Busmonitor mode with raw cEMI frames.
|
|
197
|
+
- `bus_ack`: Emitted when the bus confirms a transmission (Ack, Nack, Busy).
|
|
198
|
+
- `warning`: Emitted for non-fatal hardware warnings (e.g., slave collision detected, transmission error).
|
|
199
|
+
|
|
200
|
+
#### **KNXUSBConnection**
|
|
201
|
+
|
|
202
|
+
- `indication_emi`: Emitted when an older EMI1/EMI2-formatted message is received from legacy USB interfaces.
|
|
203
|
+
|
|
204
|
+
#### **KNXTunneling**
|
|
205
|
+
|
|
206
|
+
- `feature_info`: Emitted when querying the features supported by a KNXnet/IP server.
|
|
207
|
+
- `raw_message`: Emitted with the raw IP payload (including full KNXnet/IP headers, not only cEMI).
|
|
208
|
+
|
|
209
|
+
#### **Router (Learning Bridge)**
|
|
210
|
+
|
|
211
|
+
Because `Router` links multiple interfaces, it emits link-specific routing events instead of standard indications:
|
|
212
|
+
|
|
213
|
+
- `indication_link`: Emitted when a packet is routed through the bridge. Argument: `{ src: string, msg: ServiceMessage }`, where `src` is the class name of the source connection.
|
|
214
|
+
- `error`: Emitted when an underlying link fails. Argument: `{ link: KNXService, error: Error }`.
|
|
116
215
|
|
|
117
|
-
### Understanding the
|
|
216
|
+
### Understanding the Telegram Object
|
|
118
217
|
|
|
119
|
-
The `cemi` object (
|
|
218
|
+
The `cemi` or `emi` object (implementing `ServiceMessage`) contains all the information about the KNX telegram. Here are the most relevant properties:
|
|
120
219
|
|
|
121
220
|
| Property | Type | Description |
|
|
122
|
-
|
|
221
|
+
|-----------|------|-------------|
|
|
123
222
|
| `sourceAddress` | `string` | Physical address of the sender (e.g., `"1.1.5"`). |
|
|
124
|
-
| `destinationAddress` | `string` | Group address (e.g., `"1/1/1"`) or
|
|
223
|
+
| `destinationAddress` | `string` | Group address (e.g., `"1/1/1"`) or physical address. |
|
|
125
224
|
| `TPDU.apdu.data` | `Buffer` | The raw payload data. |
|
|
126
225
|
| `TPDU.apdu.apci.command` | `string` | Command type (`A_GroupValue_Write`, `A_GroupValue_Read`, etc.). |
|
|
127
226
|
|
|
128
227
|
#### Handling Data Payloads
|
|
129
228
|
|
|
130
|
-
KNX handles data in two ways depending on
|
|
229
|
+
KNX handles data in two ways depending on size:
|
|
131
230
|
|
|
132
|
-
- **Short Data (<= 6 bits)**: For DPT1 (Switch), DPT3 (Control), etc.
|
|
133
|
-
- **Extended Data (> 6 bits)**: For DPT5 (Scaling), DPT9 (Float), etc. The `cemi.TPDU.apdu.data`
|
|
231
|
+
- **Short Data (<= 6 bits)**: For DPT1 (Switch), DPT3 (Control), etc. `cemi.TPDU.apdu.data[0]` contains the value.
|
|
232
|
+
- **Extended Data (> 6 bits)**: For DPT5 (Scaling), DPT9 (Float), etc. The `cemi.TPDU.apdu.data` buffer contains the full payload (e.g., 2 bytes for DPT9).
|
|
134
233
|
|
|
135
|
-
## 🔢 Data Encoding
|
|
234
|
+
## 🔢 Data Encoding and Decoding
|
|
136
235
|
|
|
137
|
-
The library provides static utilities to handle KNX Data Point Types (DPT)
|
|
236
|
+
The library provides static utilities to handle conversion of KNX Data Point Types (DPT) between raw buffers and high-level TypeScript objects.
|
|
138
237
|
|
|
139
238
|
### Decoding Incoming Data
|
|
140
239
|
|
|
141
|
-
Use `KnxDataDecode` to transform raw
|
|
240
|
+
Use `KnxDataDecode` to transform raw cEMI data into readable values. There are several methods with the `asDpt` prefix for specific cases; `decodeThis` is convenient if you do not want to deal with those directly:
|
|
142
241
|
|
|
143
242
|
```typescript
|
|
144
|
-
import { KnxDataDecode } from '
|
|
243
|
+
import { KnxDataDecode } from 'knx.ts';
|
|
145
244
|
|
|
146
245
|
server.on('1/1/1', (cemi) => {
|
|
147
246
|
// Decode as DPT 1 (Boolean)
|
|
148
247
|
const value = KnxDataDecode.decodeThis(1, cemi.TPDU.apdu.data);
|
|
149
248
|
console.log('Decoded value:', value); // true or false
|
|
150
249
|
|
|
151
|
-
// Decode as DPT
|
|
250
|
+
// Decode only as DPT 1 (Boolean)
|
|
251
|
+
const value1 = KnxDataDecode.asDpt1(cemi.TPDU.apdu.data);
|
|
252
|
+
|
|
253
|
+
// Decode as DPT 9 (2-byte float, e.g. Temperature)
|
|
152
254
|
const temp = KnxDataDecode.decodeThis(9, cemi.TPDU.apdu.data);
|
|
153
255
|
console.log('Temperature:', temp, '°C');
|
|
256
|
+
|
|
257
|
+
// The first parameter also accepts strings with the standard DPT numbering
|
|
258
|
+
const temp1 = KnxDataDecode.decodeThis("9", cemi.TPDU.apdu.data)
|
|
259
|
+
const percentage = KnxDataDecode.decodeThis("5.001", cemi.TPDU.apdu.data)
|
|
154
260
|
});
|
|
155
261
|
```
|
|
156
262
|
|
|
157
263
|
### Encoding Data for Sending
|
|
158
264
|
|
|
159
|
-
Use `KnxDataEncoder` with the `encodeThis` method to prepare buffers for KNX telegrams; the second parameter is always an object
|
|
265
|
+
Use `KnxDataEncoder` with the `encodeThis` method to prepare buffers for KNX telegrams; the second parameter is always an object. There are several `encodeDpt`-prefixed methods for specific cases, but `encodeThis` is convenient if you do not want to deal with those directly:
|
|
160
266
|
|
|
161
267
|
```typescript
|
|
162
|
-
import { KnxDataEncoder } from '
|
|
268
|
+
import { KnxDataEncoder } from 'knx.ts';
|
|
163
269
|
|
|
164
270
|
// Encode a Boolean (DPT 1)
|
|
165
271
|
const buf1 = KnxDataEncoder.encodeThis(1, { value: true });
|
|
166
272
|
|
|
167
273
|
// Encode a Percentage (DPT 5.001)
|
|
168
|
-
const
|
|
274
|
+
const bufOnly5 = KnxDataEncoder.encodeDpt5({ valueDpt5001: 50 });
|
|
275
|
+
const buf5 = KnxDataEncoder.encodeThis(5001, { valueDpt5001: 50 });
|
|
276
|
+
const buf5001 = KnxDataEncoder.encodeThis("5.001", { valueDpt5001: 50 });
|
|
169
277
|
|
|
170
278
|
// Encode a Temperature (DPT 9.001)
|
|
171
279
|
const buf9 = KnxDataEncoder.encodeThis(9, { valueDpt9: 22.5 });
|
|
172
280
|
```
|
|
173
281
|
|
|
174
|
-
### Type Safety
|
|
282
|
+
### Type Safety and IntelliSense
|
|
175
283
|
|
|
176
284
|
Both `KnxDataDecode.decodeThis()` and `KnxDataEncoder.encodeThis()` are strictly typed. This means:
|
|
177
285
|
|
|
178
|
-
- **IntelliSense Support**: Your IDE will automatically suggest
|
|
286
|
+
- **IntelliSense Support**: Your IDE will automatically suggest supported DPTs as you type the first parameter.
|
|
179
287
|
- **Automatic Data Validation**: The second parameter (the data object) automatically adjusts its required properties based on the DPT selected in the first parameter.
|
|
180
|
-
- **Supported DPTs**: You can programmatically
|
|
288
|
+
- **Supported DPTs**: You can programmatically inspect the list of supported DPTs (they return an array of numbers):
|
|
181
289
|
|
|
182
290
|
```typescript
|
|
183
291
|
console.log(KnxDataDecode.dptEnum);
|
|
184
292
|
console.log(KnxDataEncoder.dptEnum);
|
|
185
293
|
```
|
|
186
294
|
|
|
295
|
+
## 🧪 Manual Message Construction and Sending (Experimental)
|
|
296
|
+
|
|
297
|
+
The library exports low-level classes for building or reading **cEMI** and **EMI** messages in a granular way. This is useful for diagnostics, custom telegram injection, or implementing services not covered by the high-level API.
|
|
298
|
+
|
|
299
|
+
### Hierarchy of a KNX Message
|
|
300
|
+
|
|
301
|
+
In the actual API of this project, you typically build the **APDU** and **TPDU** layers first, and then create the final **cEMI** or **EMI** service. For a standard `L_Data.req` telegram, the final class is `CEMI.DataLinkLayerCEMI["L_Data.req"]`.
|
|
302
|
+
|
|
303
|
+
#### 1. APDU (Application Protocol Data Unit)
|
|
304
|
+
|
|
305
|
+
Defines the command (**APCI**) and the message data.
|
|
306
|
+
|
|
307
|
+
```typescript
|
|
308
|
+
import { APDU, APCI, APCIEnum } from 'knx.ts';
|
|
309
|
+
|
|
310
|
+
const apci = new APCI(APCIEnum.A_GroupValue_Write_Protocol_Data_Unit);
|
|
311
|
+
const apdu = new APDU(undefined, apci, Buffer.from([0x01]), true);
|
|
312
|
+
```
|
|
313
|
+
|
|
314
|
+
#### 2. TPDU (Transport Protocol Data Unit)
|
|
315
|
+
|
|
316
|
+
Wraps the APDU and defines the transport type.
|
|
317
|
+
|
|
318
|
+
```typescript
|
|
319
|
+
import { TPDU, TPCI, TPCIType } from 'knx.ts';
|
|
320
|
+
|
|
321
|
+
const tpdu = new TPDU(
|
|
322
|
+
new TPCI(TPCIType.T_DATA_GROUP_PDU),
|
|
323
|
+
apdu,
|
|
324
|
+
apdu.data,
|
|
325
|
+
);
|
|
326
|
+
```
|
|
327
|
+
|
|
328
|
+
#### 3. cEMI `L_Data.req`
|
|
329
|
+
|
|
330
|
+
In this library you do not build a generic `new CEMI()` for this case. You must instantiate the concrete cEMI service and pass its control fields, addresses, and `TPDU`.
|
|
331
|
+
|
|
332
|
+
```typescript
|
|
333
|
+
import {
|
|
334
|
+
AddressType,
|
|
335
|
+
CEMI,
|
|
336
|
+
ControlField,
|
|
337
|
+
ExtendedControlField,
|
|
338
|
+
Priority,
|
|
339
|
+
} from 'knx.ts';
|
|
340
|
+
|
|
341
|
+
const controlField1 = new ControlField();
|
|
342
|
+
controlField1.frameType = true;
|
|
343
|
+
controlField1.priority = Priority.LOW;
|
|
344
|
+
|
|
345
|
+
const controlField2 = new ExtendedControlField();
|
|
346
|
+
controlField2.addressType = AddressType.GROUP;
|
|
347
|
+
controlField2.hopCount = 6;
|
|
348
|
+
|
|
349
|
+
const cemi = new CEMI.DataLinkLayerCEMI["L_Data.req"](
|
|
350
|
+
null,
|
|
351
|
+
controlField1,
|
|
352
|
+
controlField2,
|
|
353
|
+
"1.1.1",
|
|
354
|
+
"1/1/1",
|
|
355
|
+
tpdu,
|
|
356
|
+
);
|
|
357
|
+
```
|
|
358
|
+
|
|
359
|
+
#### 4. Additional Information (optional)
|
|
360
|
+
|
|
361
|
+
`AdditionalInformationField` is not filled by assigning `type` and `data` manually. You must create instances of the concrete types defined in `KNXAddInfoTypes` and add them to the field.
|
|
362
|
+
|
|
363
|
+
```typescript
|
|
364
|
+
import {
|
|
365
|
+
AdditionalInformationField,
|
|
366
|
+
ManufacturerSpecificData,
|
|
367
|
+
} from 'knx.ts';
|
|
368
|
+
|
|
369
|
+
const addInfo = new AdditionalInformationField();
|
|
370
|
+
const manufacturerInfo = new ManufacturerSpecificData();
|
|
371
|
+
manufacturerInfo.data = Buffer.from([0x00, 0x01]);
|
|
372
|
+
addInfo.add(manufacturerInfo);
|
|
373
|
+
|
|
374
|
+
cemi.additionalInfo = addInfo;
|
|
375
|
+
```
|
|
376
|
+
|
|
377
|
+
#### 5. EMI (External Message Interface)
|
|
378
|
+
|
|
379
|
+
`EMI` is also not used as a generic instance with `new EMI()`. The class acts as a service container and parser (`EMI.fromBuffer(...)`). In connections such as `KNXUSBConnection`, the library automatically converts a cEMI `ServiceMessage` to EMI when needed.
|
|
380
|
+
|
|
381
|
+
### Final Assembly and Sending Example
|
|
382
|
+
|
|
383
|
+
Once the structure is built, you can send it directly as a `ServiceMessage`, or serialize it with `toBuffer()` if you really need the raw buffer.
|
|
384
|
+
|
|
385
|
+
```typescript
|
|
386
|
+
import { KNXTunneling } from 'knx.ts';
|
|
387
|
+
|
|
388
|
+
const tunnel = new KNXTunneling({
|
|
389
|
+
ip: '192.168.1.10',
|
|
390
|
+
port: 3671,
|
|
391
|
+
});
|
|
392
|
+
|
|
393
|
+
await tunnel.connect();
|
|
394
|
+
await tunnel.send(cemi);
|
|
395
|
+
|
|
396
|
+
// If you need the serialized buffer:
|
|
397
|
+
await tunnel.send(cemi.toBuffer());
|
|
398
|
+
```
|
|
399
|
+
|
|
187
400
|
## 🛠️ Development
|
|
188
401
|
|
|
189
402
|
To build the project:
|
|
@@ -208,4 +421,4 @@ npm run test:connection
|
|
|
208
421
|
|
|
209
422
|
## ⚖️ License
|
|
210
423
|
|
|
211
|
-
This project is licensed under the
|
|
424
|
+
This project is licensed under the Apache License 2.0. See the [LICENSE](LICENSE) and [NOTICE](NOTICE) files for details.
|