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.
Files changed (50) hide show
  1. package/LICENSE +51 -21
  2. package/README.md +274 -61
  3. package/dist/@types/interfaces/connection.d.ts +80 -13
  4. package/dist/@types/interfaces/servers.d.ts +18 -0
  5. package/dist/@types/interfaces/servers.js +2 -0
  6. package/dist/connection/KNXService.d.ts +13 -30
  7. package/dist/connection/KNXService.js +4 -164
  8. package/dist/connection/KNXTunneling.d.ts +4 -4
  9. package/dist/connection/KNXTunneling.js +35 -62
  10. package/dist/connection/KNXUSBConnection.d.ts +20 -0
  11. package/dist/connection/KNXUSBConnection.js +358 -0
  12. package/dist/connection/KNXnetIPServer.d.ts +29 -12
  13. package/dist/connection/KNXnetIPServer.js +261 -83
  14. package/dist/connection/Router.d.ts +52 -32
  15. package/dist/connection/Router.js +225 -153
  16. package/dist/connection/TPUART.d.ts +8 -3
  17. package/dist/connection/TPUART.js +41 -37
  18. package/dist/connection/TunnelConnection.d.ts +3 -1
  19. package/dist/connection/TunnelConnection.js +6 -4
  20. package/dist/core/CEMI.d.ts +7 -2
  21. package/dist/core/CEMI.js +5 -8
  22. package/dist/core/EMI.d.ts +312 -200
  23. package/dist/core/EMI.js +511 -1007
  24. package/dist/core/KNXnetIPStructures.d.ts +10 -1
  25. package/dist/core/KNXnetIPStructures.js +15 -10
  26. package/dist/core/MessageCodeField.d.ts +1 -1
  27. package/dist/core/cache/GroupAddressCache.d.ts +57 -0
  28. package/dist/core/cache/GroupAddressCache.js +227 -0
  29. package/dist/core/data/KNXDataDecode.d.ts +2 -2
  30. package/dist/core/data/KNXDataDecode.js +198 -183
  31. package/dist/core/enum/EnumControlField.d.ts +0 -5
  32. package/dist/core/enum/EnumControlField.js +1 -7
  33. package/dist/core/enum/EnumControlFieldExtended.d.ts +1 -1
  34. package/dist/core/enum/EnumShortACKFrame.d.ts +1 -1
  35. package/dist/core/enum/ErrorCodeSet.js +59 -0
  36. package/dist/core/enum/KNXnetIPEnum.d.ts +2 -2
  37. package/dist/core/enum/KNXnetIPEnum.js +19 -1
  38. package/dist/core/layers/data/NPDU.d.ts +2 -1
  39. package/dist/core/layers/data/NPDU.js +6 -3
  40. package/dist/index.d.ts +19 -2
  41. package/dist/index.js +36 -1
  42. package/dist/server/KNXMQTTGateway.d.ts +13 -0
  43. package/dist/server/KNXMQTTGateway.js +164 -0
  44. package/dist/server/KNXWebSocketServer.d.ts +12 -0
  45. package/dist/server/KNXWebSocketServer.js +118 -0
  46. package/dist/utils/CEMIAdapter.d.ts +4 -3
  47. package/dist/utils/CEMIAdapter.js +26 -30
  48. package/dist/utils/Logger.d.ts +4 -4
  49. package/dist/utils/Logger.js +3 -7
  50. package/package.json +28 -8
package/LICENSE CHANGED
@@ -1,21 +1,51 @@
1
- MIT License
2
-
3
- Copyright (c) 2025 Arnold Steven Beleño Zuletta
4
-
5
- Permission is hereby granted, free of charge, to any person obtaining a copy
6
- of this software and associated documentation files (the "Software"), to deal
7
- in the Software without restriction, including without limitation the rights
8
- to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
- copies of the Software, and to permit persons to whom the Software is
10
- furnished to do so, subject to the following conditions:
11
-
12
- The above copyright notice and this permission notice shall be included in all
13
- copies or substantial portions of the Software.
14
-
15
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
- IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
- FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
- AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
- LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
- OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
- SOFTWARE.
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
- A high-performance **KNXnet/IP** library written in **TypeScript**. This project focuses on protocol strictness and connection stability, specifically optimized to provide a reliable experience when used as a Gateway for ETS.
3
+ Spanish version: see [readme-es.md](./readme-es.md).
4
4
 
5
- ## 🌟 Current Capabilities
5
+ A high-performance **KNXnet/IP** and **Hardware Interface** library such as **HID USB** and **TPUART**, written in **TypeScript**.
6
6
 
7
- - **Robust UDP Tunnelling**: Implements a strict *Stop-and-Wait* queue and sequence number management (KNX Spec Vol 3/8/4). This eliminates common "connection broken" issues in ETS during long sessions.
8
- - **KNXnet/IP Routing**: Supports standard multicast routing for seamless bus integration.
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 out loopback messages to prevent telegram processing loops.
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 & Work-In-Progress
20
+ ## 🚧 Status: Experimental and In Development
14
21
 
15
- As per the `TODO.md`, several features are currently in an **experimental** state or under development:
22
+ According to `TODO.md`, several features are currently **experimental** or under development:
16
23
 
17
- - **TCP Support**: Implementation is present but testing is currently in an experimental phase.
18
- - **TPUART Hardware**: Integration with TPUART chips via serial is implemented but awaits full hardware verification, this implementation is based from the knxd.
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 './src/index.ts';
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' // Provide 5 tunneling slots starting from 1.1.10
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 Server is up and running');
103
+ console.log('The KNXnet/IP server is running');
48
104
  });
49
105
 
50
- // Specific listening for a Group Address
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 './src/index.ts';
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 Bus');
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 singleton logger based on [Pino](https://github.com/pinojs/pino). You can configure it at the very beginning of your application using `setupLogger`.
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 './src/index.ts';
154
+ import { setupLogger, knxLogger } from 'knx.ts';
78
155
 
79
156
  // Configure the global logger
80
157
  setupLogger({
81
- level: 'debug', // e.g., 'info', 'warn', 'error', 'debug'
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 to avoid spawning multiple Pino instances.
167
+ All internal components (`KNXnetIPServer`, `KNXTunneling`, `Router`, etc.) automatically use this shared logger.
91
168
 
92
- ## 📡 Events & Callbacks
169
+ ## 📡 Events and Callbacks
93
170
 
94
- The library is event-driven. You can listen for system events or specific KNX Group Addresses.
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
- Both `KNXnetIPServer` and `KNXTunneling` emit the following events:
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` | An error occurred during operation. | `Error` |
105
- | `indication` | Any incoming KNX telegram (L_Data.ind). | `cemi: L_Data_ind` |
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
- ### Address-Based Events (Server Only)
185
+ ### Class-Specific Events
108
186
 
109
- You can listen to specific Group Addresses directly:
187
+ Depending on the connection type, some classes emit additional specific events:
110
188
 
111
- ```typescript
112
- server.on("1/1/1", (cemi) => {
113
- // Triggered only for telegrams to 1/1/1
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 `cemi` Object
216
+ ### Understanding the Telegram Object
118
217
 
119
- The `cemi` object (specifically `L_Data_ind`) contains all the information about the KNX telegram. Here are the most relevant properties:
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 Physical address. |
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 the size:
229
+ KNX handles data in two ways depending on size:
131
230
 
132
- - **Short Data (<= 6 bits)**: For DPT1 (Switch), DPT3 (Control), etc. The `cemi.TPDU.apdu.data[0]` contains the value.
133
- - **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).
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 & Decoding
234
+ ## 🔢 Data Encoding and Decoding
136
235
 
137
- The library provides static utilities to handle KNX Data Point Types (DPT) conversion between raw Buffers and high-level TypeScript objects.
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 CEMI data into readable values:
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 './src/core/data/KNXDataDecode';
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 9 (2-byte Float, e.g., Temperature)
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 (Problem: all DPTs other than DPT1 belonging to a property are different keys instead of just "value" values; this will be fixed in the future):
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 './src/core/data/KNXDataEncode';
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 buf5 = KnxDataEncoder.encodeThis(5.001, { valueDpt5001: 50 });
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 & IntelliSense
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 the supported DPTs as you type the first parameter.
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 check the list of supported DPTs by accessing the static `dptEnum` property:
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 MIT License.
424
+ This project is licensed under the Apache License 2.0. See the [LICENSE](LICENSE) and [NOTICE](NOTICE) files for details.