Merge branch 'staging/4.2' into release/4.2

Author: ashvayka

_data/clients-feedback.yml

@@ -123,6 +123,30 @@ smart-buildings:
   label: Smart Buildings
   icon: https://img.thingsboard.io/smart-buildings-icon.svg
   feedback:
+    - author: Rifat Şeker
+      position: Founder
+      companyName: ARIOT
+      id: ariot
+      link: https://www.ariot.com.tr/
+      authorImage: https://img.thingsboard.io/customers/ariot-person.webp
+      companyImage: https://img.thingsboard.io/customers/ariot.svg
+      companyImageWidth: 80
+      companyImageHeight: 62
+      text:
+        0: 'Transforming compliance and patient safety through IoT-enabled real-time monitoring'
+        1: "At ARIOT, our mission with Medline Adana Hospital was to elevate their operational reliability to match their world-class JCI accreditation. By leveraging the flexibility of ThingsBoard combined with robust LoRaWAN infrastructure, we transformed their critical environmental monitoring from a reactive, manual process into a proactive, data-driven operation. This solution provided immediate value by ensuring 100% data integrity for compliance audits and eliminating the risk of high-value pharmaceutical spoilage through real-time alerting. Ultimately, we didn't just install sensors; we delivered peace of mind and a scalable digital backbone that secures patient safety and optimizes hospital efficiency around the clock."
+    - author: Duran ICTEN
+      position: IT Chief
+      companyName: Sensolyze GmbH
+      id: medline
+      link: https://www.medlineadana.com.tr/en/
+      authorImage: https://img.thingsboard.io/customers/medline-person.webp
+      companyImage: https://img.thingsboard.io/customers/medline.svg
+      companyImageWidth: 180
+      companyImageHeight: 62
+      text:
+        0: 'Ensuring absolute cold-chain integrity through real-time IoT visibility and alerts'
+        1: 'ARIOT transformed our JCI compliance from a manual burden into a digital asset. By deploying the ThingsBoard platform with Milesight LoRaWAN sensors, we eliminated human error and secured 100% data integrity for our critical cold chain. This solution gives us total visibility and immediate alerts, ensuring patient safety is never compromised.'
     - author: Andreas Brandl
       position: Founder & CEO
       companyName: Sensolyze GmbH

_includes/docs/user-guide/device-connectivity-status.md

@@ -104,6 +104,18 @@ All configuration is done using global parameters defined in **thingsboard.yml**
 
 - **state.defaultInactivityTimeoutInSec** - period of time after which a device is considered inactive by Device State service if no activities were reported. Value is set in seconds.
 Default value is 600 seconds (10 minutes). A user can overwrite this parameter for an individual device by setting the **inactivityTimeout** server-side attribute (value is set in milliseconds).
+
+{% capture difference %}
+**Please note:**
+<br>
+This parameter controls only how the core service detects a device’s connectivity status (the value is stored in **"active"** attribute of device); it does **not** affect the device session timeout.
+The device session inactivity timeout is configured separately via the **transport.sessions.inactivity_timeout** property.
+
+To avoid inconsistencies, we recommend keeping these two parameters in sync: the transport session inactivity timeout should be **greater than or equal to** the device inactivity timeout.
+
+{% endcapture %}
+{% include templates/info-banner.md content=difference %}
+
 - **state.defaultStateCheckIntervalInSec** - interval for periodic checks of a device activity state, performed by a Device State service. Value is set in seconds. Default value is 60 seconds (1 minute).
 - **state.telemetryTtl** - time-to-live value for activity telemetry data. Value is set in milliseconds. Default value is 0 milliseconds (meaning time-to-live mechanism is disabled).
 {% if docsPrefix == 'pe/' %}
@@ -112,6 +124,7 @@ Default value is 600 seconds (10 minutes). A user can overwrite this parameter f
 {% endif %}
 - **transport.activity.reporting_strategy** - activity reporting strategy for transports. Allowed values: ALL, FIRST, LAST, FIRST_AND_LAST. Default value is LAST.
 - **transport.sessions.report_timeout** - duration of a reporting period for transports. Value is set in milliseconds. Default value is 3000 milliseconds (3 seconds).
+- **transport.sessions.inactivity_timeout** - defines how long the device transport session will be opened after the last message arrives from the device. Value is set in milliseconds. Default value is 60000 milliseconds (10 min).
 
 ## Next steps
 

_includes/docs/user-guide/tenant-profiles.md

@@ -75,7 +75,7 @@ For example, the message listed below contains 5 data points, because the “jso
 
 **Data points storage days** are calculated for all time-series data points that are stored in the database. 
 Platform multiplies the number of data points by the number of days those data points will be stored. The TTL parameter is used to extract the number of days to store the data. 
-For example, if you store 3 data points for 30 days, this is 90 storage data point days.
+For example, if you store 3 data points for 30 days, this is 90 data point storage days.
 A System Administrator is able to configure default TTL using the "**Default Storage TTL Days**" parameter in the tenant profile.
 A Tenant Administrator is able to overwrite default TTL using the "**Save Timeseries**" ule node configuration or using the “TTL” parameter in the post telemetry request.