thingsboard · ashvayka · Nov 3, 2025 · Oct 19, 2025 · Oct 19, 2025 · Oct 20, 2025
diff --git a/_includes/docs/edge/troubleshooting.md b/_includes/docs/edge/troubleshooting.md
@@ -5,7 +5,7 @@
 
 ### MessagePack Processing Log
 
-To enable logging for the slowest and most frequently called rule-nodes, 
+To enable logging for the slowest and most frequently called rule nodes, 
 [update your logging configuration](#enable-certain-logs) with the following **logger**:
 
 ```bash

diff --git a/_includes/docs/edge/user-guide/alarms.md b/_includes/docs/edge/user-guide/alarms.md
@@ -19,7 +19,7 @@ The **Edge Alarms** are created and configured in the same way as the **Cloud Al
 
 The easiest way to create an Alarm is to use the [Alarm Rules within the Device profile](/docs/{{cloudDocsPrefix}}user-guide/device-profiles/#alarm-rules){: target="_blank"}. The majority of tasks can be configured with **Alarm Rules** with minimal effort.
 
-If more complex logic is required, we suggest using the alternative option, namely the ["Create Alarm"](/docs/{{cloudDocsPrefix}}user-guide/rule-engine-2-0/action-nodes/#create-alarm-node){: target="_blank"} and ["Clear Alarm"](/docs/{{cloudDocsPrefix}}user-guide/rule-engine-2-0/action-nodes/#clear-alarm-node){: target="_blank"} rule nodes in the [Rule Engine](/docs/{{cloudDocsPrefix}}user-guide/rule-engine-2-0/re-getting-started/){: target="_blank"}. This is a more advanced option that requires a certain level of programming expertise. Please refer to the [corresponding example](/docs/user-guide/rule-engine-2-0/tutorials/create-clear-alarms/){: target="_blank"}.
+If more complex logic is required, we suggest using the alternative option, namely the ["Create Alarm"](/docs/user-guide/rule-engine-2-0/nodes/action/create-alarm/){:target="_blank"} and ["Clear Alarm"](/docs/user-guide/rule-engine-2-0/nodes/action/clear-alarm/){: target="_blank"} rule nodes in the [Rule Engine](/docs/{{cloudDocsPrefix}}user-guide/rule-engine-2-0/re-getting-started/){: target="_blank"}. This is a more advanced option that requires a certain level of programming expertise. Please refer to the [corresponding example](/docs/user-guide/rule-engine-2-0/tutorials/create-clear-alarms/){: target="_blank"}.
 
 ## Alarms Pushing from the Cloud to the Edge
 
@@ -55,4 +55,4 @@ To push Alarms from the **Edge** to the **Cloud**, follow these steps:
 
 ## Next steps
 
-{% include templates/edge/guides-banner-edge.md %}
+{% include templates/edge/guides-banner-edge.md %}
diff --git a/_includes/docs/edge/user-guide/edge-attributes.md b/_includes/docs/edge/user-guide/edge-attributes.md
@@ -85,7 +85,7 @@ To use **Edge** attributes as placeholders in the **Rule Chain template**:
 * Then, find the **"rest api call"** node using the **Node search** bar. Drag and drop the node onto the **Rule Chain sheet**. In the pop-up window, enter the **node name** and click the **"Add"** button.
   * **Name:** Enter the node name.
   * **Headers:** Enter the request header and value. The header or value can be a static string, or pattern that is resolved using Message Metadata properties.
-  * Click the **"Add"** button. Read more about the **REST API Call node configuration** [here](/docs/{{peDocsPrefix}}user-guide/rule-engine-2-0/external-nodes/#rest-api-call-node){: target="_blank"}.
+  * Click the **"Add"** button. Read more about the **REST API Call node configuration** [here](/docs/user-guide/rule-engine-2-0/nodes/external/rest-api-call/){:target="_blank"}.
 * Connect the **"message type switch"** and **"related entity data"** nodes with the **“Post telemetry”** link label. Then, connect the **"related entity data"** and **"rest api call"** nodes with the **"Success"** link label. Click the **“Apply changes”** button on the **Rule Chain sheet**.
 
 {% include images-gallery.html imageCollection="edgeAttributesAsPlaceholders" %}

diff --git a/_includes/docs/edge/user-guide/rule-engine/queues.md b/_includes/docs/edge/user-guide/rule-engine/queues.md
@@ -8,8 +8,8 @@ In **ThingsBoard**, **queues** guarantee the message processing, handle occasion
 For a better understanding, read the [Platform Queues documentation](/docs/{{peDocsPrefix}}user-guide/rule-engine-2-5/queues/){: target="_blank"}.
 
 **Tenant administrators** can use any **queue** in the **Edge Rule Chain**, the same as the **Platform Rule Chain**.
-**Queues** can be used in [checkpoint node](/docs/{{peDocsPrefix}}user-guide/rule-engine-2-0/flow-nodes/#checkpoint-node){: target="_blank"} 
-or any [analytics nodes](/docs/pe/user-guide/rule-engine-2-0/analytics-nodes/){: target="_blank"} (for a Professional Edition).
+**Queues** can be used in [checkpoint node](/docs/user-guide/rule-engine-2-0/nodes/flow/checkpoint/){: target="_blank"} 
+or any [analytics nodes](/docs/user-guide/rule-engine-2-0/nodes/analytics/){: target="_blank"} (for a Professional Edition).
 
 Starting with **Edge 3.9**, Edge supports **Kafka** and **in-memory** types of message queues:
 * **In-Memory:** The built-in and default queue implementation. It is useful for development or proof-of-concept (PoC) environments, but is not recommended for production or any type of clustered deployments due to limited scalability.

diff --git a/_includes/docs/edge/user-guide/telemetry-sync.md b/_includes/docs/edge/user-guide/telemetry-sync.md
@@ -2,8 +2,8 @@
 {:toc}
 
 > **ThingsBoard Edge** does not automatically sync telemetry data. 
-Instead, it's **a rule-based process**. The ["push to cloud"](/docs/{{peDocsPrefix}}user-guide/rule-engine-2-0/action-nodes/#push-to-cloud){:target="_blank"}
-and ["push to edge"](/docs/{{peDocsPrefix}}user-guide/rule-engine-2-0/action-nodes/#push-to-edge){:target="_blank"} rule nodes are responsible for 
+Instead, it's **a rule-based process**. The ["push to cloud"](/docs/user-guide/rule-engine-2-0/nodes/action/push-to-cloud/){:target="_blank"}
+and ["push to edge"](/docs/user-guide/rule-engine-2-0/nodes/action/push-to-edge/){:target="_blank"} rule nodes are responsible for 
 the synchronization process.
 
 ### Edge → Cloud sync
@@ -36,7 +36,7 @@ The database tables updated in Cloud depend entirely on your Cloud‑side rule c
 
 ### Cloud → Edge sync
 
-Similarly, Cloud synchronizes data using the ["push to edge"](/docs/{{peDocsPrefix}}user-guide/rule-engine-2-0/action-nodes/#push-to-edge){:target="_blank"} rule node within a Cloud rule chain.
+Similarly, Cloud synchronizes data using the ["push to edge"](/docs/user-guide/rule-engine-2-0/nodes/action/push-to-edge/){:target="_blank"} rule node within a Cloud rule chain.
 
 The node converts the message into an **Edge Event** and stores it in the **Edge queue** on the Cloud (_either a local database or Kafka, depending on the queue type_). 
 The event is then **asynchronously** pushed to the target Edge.

diff --git a/_includes/docs/pe/solution-templates/swimming-pool-scada-system.md b/_includes/docs/pe/solution-templates/swimming-pool-scada-system.md
@@ -140,24 +140,24 @@ Each message passes through The **Swimming Pool Device Rule Chain**. Here, telem
 **Message processing flow:**
 
 * **Alarm generation**:
-  Every message first passes through the [device profile node](/docs/{{docsPrefix}}user-guide/device-profiles/#device-profile-rule-node){:target="_blank"}. This step allows the system to generate alarms based on the conditions defined in the device profiles (such as for the heat pump, water pump, and sand filter). If the telemetry exceeds the set thresholds, alarms are triggered and displayed on the dashboard.{% include images-gallery.html imageCollection="rule-chain-1" %}
+  Every message first passes through the [device profile node](/docs/user-guide/rule-engine-2-0/nodes/action/device-profile/){:target="_blank"}. This step allows the system to generate alarms based on the conditions defined in the device profiles (such as for the heat pump, water pump, and sand filter). If the telemetry exceeds the set thresholds, alarms are triggered and displayed on the dashboard.{% include images-gallery.html imageCollection="rule-chain-1" %}
 
 * **Message type switch**:
-  After the initial profile processing, the message moves to the [message type switch node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/filter-nodes/#message-type-switch-node){:target="_blank"}. This node routes messages based on their type, such as telemetry data, attribute updates, or RPC requests. It sends each message down the appropriate path for further processing.
+  After the initial profile processing, the message moves to the [message type switch node](/docs/user-guide/rule-engine-2-0/nodes/filter/message-type-switch/){:target="_blank"}. This node routes messages based on their type, such as telemetry data, attribute updates, or RPC requests. It sends each message down the appropriate path for further processing.
 
 {% include images-gallery.html imageCollection="rule-chain-2" %}
 
 * **General logic – save attributes, time series, and RPC requests**:
   Independent of the message type, these actions are performed for all devices.
 
-  * [save attributes node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/action-nodes/#save-attributes-node){:target="_blank"}: The telemetry data from devices is saved as attributes.
-  * [save time series node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/action-nodes/#save-timeseries-node){:target="_blank"}: Time series data is saved for historical analysis and monitoring.
-  * [rpc call request node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/action-nodes/#rpc-call-request-node){:target="_blank"}: The system can generate and send RPC requests to devices. These RPC commands may turn devices on/off, change operational modes, or control valve positions. For example, valves can be opened/closed, and pumps can be activated/deactivated based on predefined conditions or manual requests.
+  * [save attributes node](/docs/user-guide/rule-engine-2-0/nodes/action/save-attributes/){:target="_blank"}: The telemetry data from devices is saved as attributes.
+  * [save time series node](/docs/user-guide/rule-engine-2-0/nodes/action/save-timeseries/){:target="_blank"}: Time series data is saved for historical analysis and monitoring.
+  * [rpc call request node](/docs/user-guide/rule-engine-2-0/nodes/action/rpc-call-request/){:target="_blank"}: The system can generate and send RPC requests to devices. These RPC commands may turn devices on/off, change operational modes, or control valve positions. For example, valves can be opened/closed, and pumps can be activated/deactivated based on predefined conditions or manual requests.
 
 {% include images-gallery.html imageCollection="rule-chain-3" %}
 
 * **Device profile filtering**:
-  Once the telemetry data is saved, the message is routed through the [device profile switch node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/filter-nodes/#device-profile-switch){:target="_blank"}. This node filters the devices based on their profile, allowing for device-specific actions. When telemetry from the **heat pump** is detected, the system checks specific conditions—like target temperature, outdoor temperature, and pool temperature—through a [switch node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/filter-nodes/#switch-node){:target="_blank"}. If the telemetry conditions meet the thresholds for turning the heat pump on or off, an RPC request is sent to control the heat pump’s state.
+  Once the telemetry data is saved, the message is routed through the [device profile switch node](/docs/user-guide/rule-engine-2-0/nodes/filter/device-profile-switch/){:target="_blank"}. This node filters the devices based on their profile, allowing for device-specific actions. When telemetry from the **heat pump** is detected, the system checks specific conditions—like target temperature, outdoor temperature, and pool temperature—through a [switch node](/docs/user-guide/rule-engine-2-0/nodes/filter/switch/){:target="_blank"}. If the telemetry conditions meet the thresholds for turning the heat pump on or off, an RPC request is sent to control the heat pump’s state.
 
 {% include images-gallery.html imageCollection="rule-chain-4" %}
 
@@ -231,4 +231,4 @@ For more about alarms and how to configure them, read [here](/docs/{{docsPrefix}
 
 The Swimming Pool SCADA template provides a ready-to-use framework for managing swimming pool components. 
 It ensures seamless integration between sensors, and ThingsBoard, allowing real-time data collection, processing, and visualization. 
-This setup not only enhances operational efficiency but also provides a scalable and reliable solution for centralized supervision and control of swimming pool systems.
+This setup not only enhances operational efficiency but also provides a scalable and reliable solution for centralized supervision and control of swimming pool systems.
diff --git a/_includes/docs/pe/user-guide/custom-translation.md b/_includes/docs/pe/user-guide/custom-translation.md
@@ -282,7 +282,7 @@ First, add the "Weather" dashboard to your instance:
 - [Download the dashboard configuration as a JSON file](/docs/user-guide/resources/weather_dashboard.json){:target="_blank"}.
 - [Import](/docs/{{docsPrefix}}user-guide/dashboards/#import-dashboard){:target="_blank"} it into your ThingsBoard instance.
 
-For this dashboard, I&#39;m emulating telemetry data using a [Generator node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/action-nodes/#generator-node){:target="_blank"} with the function provided below:
+For this dashboard, I&#39;m emulating telemetry data using a [Generator node](/docs/user-guide/rule-engine-2-0/nodes/action/generator/){:target="_blank"} with the function provided below:
 
 ```js
 var temperature = toFixed(Math.random()*10 + 18, 2);
@@ -726,4 +726,4 @@ If at any time you need to delete a language or reset its translations to the de
 
 ## Next steps
 
-{% assign currentGuide = "AdvancedFeatures" %}{% include templates/multi-project-guides-banner.md %}
+{% assign currentGuide = "AdvancedFeatures" %}{% include templates/multi-project-guides-banner.md %}
diff --git a/_includes/docs/pe/user-guide/file-storage.md b/_includes/docs/pe/user-guide/file-storage.md
@@ -3,10 +3,10 @@
 
 ## Overview
 
-ThingsBoard has ability to store binary content (files) in the DataBase.
-Currently it is used to store report files generated by [Generate Report Node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/action-nodes/#generate-report-node).
-Stored files are accessed by [Send Email Node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/external-nodes/#send-email-node) to create email attachments.
-Another way to send a file is the [REST API Call Node](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/external-nodes/#rest-api-call-node).
+ThingsBoard has ability to store binary content (files) in the database.
+Currently it is used to store report files generated by [Generate Dashboard Report Node](/docs/user-guide/rule-engine-2-0/nodes/action/generate-dashboard-report/).
+Stored files are accessed by [Send Email Node](/docs/user-guide/rule-engine-2-0/nodes/external/send-email/) to create email attachments.
+Another way to send a file is the [REST API Call Node](/docs/user-guide/rule-engine-2-0/nodes/external/rest-api-call/).
 User can access stored files using **Files** or **Reports** widgets which is part of **Files** Widgets Bundle.   
 
 ## Files Widget

diff --git a/_includes/docs/pe/user-guide/integrations/aws-iot.md b/_includes/docs/pe/user-guide/integrations/aws-iot.md
@@ -229,7 +229,7 @@ JavaScript<small></small>%,%anonymous%,%templates/integration/aws-iot/aws-iot-do
 {% include content-toggle.liquid content-toggle-id="awsiotdownlinkconverterconfig" toggle-spec=awsiotdownlinkconverterconfig %}
 
 Next, configure the conditions under which a message will be sent through the AWS IoT Downlink integration.
-To do this, you need to open the Rule Chain used for the device (in our case, the default Root Rule Chain), then add an [integration downlink node](https://thingsboard.io/docs/{{docsPrefix}}user-guide/rule-engine-2-0/action-nodes/#integration-downlink-node), for link condition set the Attributes Updated.
+To do this, you need to open the Rule Chain used for the device (in our case, the default Root Rule Chain), then add an [integration downlink node](https://thingsboard.io/docs/user-guide/rule-engine-2-0/nodes/action/integration-downlink/), for link condition set the Attributes Updated.
 
 {% include images-gallery.html imageCollection="downlink_2-3" %}
 

diff --git a/_includes/docs/pe/user-guide/integrations/kafka.md b/_includes/docs/pe/user-guide/integrations/kafka.md
@@ -139,7 +139,7 @@ Confluent Cloud<br><small>Cloud solution</small>%,%confluent%,%/templates/integr
 
 ## Advanced Usage: Kafka Producer (Downlink)
 
-To get functionality such as Kafka Producer, you need to use the [Kafka Rule Node](https://thingsboard.io/docs/{{docsPrefix}}user-guide/rule-engine-2-0/external-nodes/#kafka-node) in which you can specify Bootstrap servers, Topic and other parameters to connect to the Kafka broker, you can find more details in the corresponding [guide](https://thingsboard.io/docs/{{docsPrefix}}user-guide/rule-engine-2-0/external-nodes/#kafka-node) .
+To get functionality such as Kafka Producer, you need to use the [Kafka Rule Node](https://thingsboard.io/docs/user-guide/rule-engine-2-0/nodes/external/kafka/) in which you can specify Bootstrap servers, Topic and other parameters to connect to the Kafka broker, you can find more details in the corresponding [guide](https://thingsboard.io/docs/user-guide/rule-engine-2-0/nodes/external/kafka/) .
 
 If it is not possible to send commands directly to devices to manage from ThingsBoard, but only through a broker, then in this case you can use the Kafka Downlink Rule Node. Let's consider a small example with its Node, suppose the data came from the broker and passed the converter and, according to the config of Device Profile, were directed to the custom Rule Chain ("Monitoring-sensor") and at the end of all processing, we will send a response about success or failure back to the broker ( you can change the response to commands to control your device, etc.)
 

diff --git a/_includes/docs/tutorials/function-based-on-telemetry-from-two-devices.md b/_includes/docs/tutorials/function-based-on-telemetry-from-two-devices.md
@@ -27,7 +27,7 @@ Create relationships between the **Warehouse A** asset and the **Indoor Thermome
 Since we are using virtual devices, they do not send telemetry data to the ThingsBoard. However, we can simulate the transmission of such data in real time.
 To do this, we will use [Rule Engine](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/overview/){:target="_blank"}.
 
-Let&#39;s add two [generator nodes](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/action-nodes/#generator-node){:target="_blank"} that will periodically produce messages with random temperature readings. 
+Let&#39;s add two [generator nodes](/docs/user-guide/rule-engine-2-0/nodes/action/generator/){:target="_blank"} that will periodically produce messages with random temperature readings. 
 Ideally, such use cases should have a dedicated [Rule Chain](/docs/{{docsPrefix}}user-guide/rule-engine-2-0/overview/#rule-chain){:target="_blank"}, but for simplicity, we&#39;ll use the **Root Rule Chain**.
 Route the messages from these nodes to the **device profile node**.
 
@@ -151,4 +151,4 @@ To monitor the temperature difference in real time, download and import this [da
 
 After that, the dashboard should display the temperature delta data between the two thermometers of the **Warehouse A** asset.
 
-{% include images-gallery.html imageCollection="delta-temperature-dashboard" %}
+{% include images-gallery.html imageCollection="delta-temperature-dashboard" %}