Issue There is uncertainty whether the controller output between terminals V1, G, and V2 should provide a constant 24V signal or an intermittent signal when the actuator reaches the end position, and whether this behavior is configurable. Product Line TAC Vista Environment TAC Xenta 100 controller Cause The controller operates using increase/decrease control logic and does not track the exact position of the actuator between fully open and fully closed. As a result, it continues sending control pulses even when the actuator has reached its end position. Resolution The output from the TAC Xenta 100 controller to motorized valves is not a steady 24V signal. Instead, it sends intermittent pulses to incrementally open or close the actuator. This behavior is inherent to the controller design and is not configurable. Most motorized actuators are designed to handle this type of control signal and include internal mechanisms, such as limit switches or magnetic clutch, to stop movement when end positions are reached. Note: The TAC Xenta 100 is an outdated product and is no longer supported.

Issue Currently, a procedure exists to do conversion of i2 to b3 and vice versa using Continuum Cyberstation and NetControllers.   However, it is much simpler to do the conversion using the RoamIO and the Infinet/BACnet Service Tools. Product Line Andover Continuum, EcoStruxure Building Operation Environment Continuum i2 Controllers (except -V) Continuum b3 Controller (except -V) Warning Electrostatic Discharge Required: Always discharge static electricity from your person by touching metal prior to handling any hardware. Failure to do so may result in damage to devices. Potential for Data Loss: The steps detailed in the resolution of this article may result in a loss of critical data if not performed properly. Before beginning these steps, make sure all important data is backed up in the event of data loss. If you are unsure or unfamiliar with any complex steps detailed in this article, please contact Product Support for assistance. Cause This article describes an alternate and simplified conversion method to the original procedure published to convert i2 to b3. Before using this procedure, read the Conversion of Continuum devices from i2 to b3 and vice-versa in the field Knowledge Base article in its entirety for important information about converting i2/b3 controllers in the field.  Resolution IMPORTANT NOTE If the device you are converting is of model i2/b3 865/866/885 STOP First confirm that the device is NOT a -V device, this is accomplished by inspecting its version number, -V devices have a "1" embedded in the second part (after the ".") of the version number   A -v device will show the version number as follows... 3.501027 A non -v device will show the version number as follows... 3.500027   Before starting the procedure, you need the following items: The device to be converted. The serial number of the device to be converted. A RoamIO2 configured to communicate with your PC via Bluetooth and the Infinet and BACnet Service Tools A special, firmware application upgrade file for the appropriate device model as provided by Product Support A bootloader file for the appropriate device model, provided by Product Support To convert i2 field devices into b3 BACnet using RoamIO2 Contact Product Support and request the conversion files for the specific model(s) you wish to convert. You will be provided with an application file (e.g. i2920toB3920B4.500077.upd) and a boot loader file (e.g. B3920BootB4.500077.upd) for each model you are converting. Connect the RoamIO2 directly to the i2 device (make sure device is disconnected from field bus) Launch the InfinetServiceToolPC.exe (attached) and click on the connect icon Once the device shows up on the tree, right click on it then select 'Uprev firmware...' Send the conversion application file provided by Product Support Once the uprev operation is complete, click the connect icon to disconnect the Infinet Service Tool from the i2 device then close the InfinetServiceTool app. Cycle power to the RoamIO2 then start the BACnet Service Tool In the BACnet Service Tool, de-select View by networks, then click the connect icon, the conversion from i2 to a b3 causes the device to default to baud 38400 and an invalid BACnet master MAC id, so upon connection the following error will be shown... Click 'Yes' to continue From the 'Tools' menu select 'Set b3 baud rate' and set it to Baud38400  From the 'Tools' menu select 'Set offline b3 MAC id' and enter the serial number of the device and a valid MAC id then click on 'Apply' If the baud and MAC id have been set successfully, the device will automatically pop up in the tree but it will only be partially online, to bring the device fully online, click the red disconnect icon on the BACnet Service Tool to disconnect from the device, wait about 30 seconds then  click the now green connect icon to reconnect the BACnet Service Tool to the device Right click on the device then select 'Update OS', send it the appropriate boot loader file provided by Product Support Once the uprev of the boot loader has completed, select the device and click on 'Cold start device' After the device re-start, click on the device in the tree and select 'Switch view', confirm the firmware and boot loader versions are correct. (you may need to do a refresh from the 'Tools' menu)

Issue Repeater panel is unable to establish communication with the main fire alarm panel. RS-485 communication card is installed and connected, and wiring and terminations have been verified, but communication is not established. Product Line ESMI Fire Detection Environment FFS00703910xx (Esmi Sense FDP221) FFS00703920xx (Esmi Sense FDP252) FFS00703930xx (Esmi Sense FDP292) FFS00702606xx (FMP Sense Fireman's Panel) Warning Electrostatic Discharge (ESD) Precautions Required Always follow standard electrostatic discharge (ESD) precautions when handling internal components. Discharge static electricity from your person by touching a grounded metal surface before touching internal hardware. Failure to do so may result in damage to electronic components. Cause There are several potential causes: INFO LINE not enabled in the panel configuration. Baud rate mismatch or configuration not aligned between panels. Required jumper (shunt) not installed on repeater panel B3 pins. Resolution Login to Fire Expert software and perform the following the steps. Open the configuration file. From the left-hand pane, select the desired panel. Navigate to the Connections tab. In the panel configuration, enable the INFO LINE option. Set the baud rate to 9600 on the main panel. Save the configuration changes. Repeater Panel Validations Ensure the repeater panel baud rate is set to 9600 (same as the main panel). Install a jumper (shunt) on the B3 pins of the repeater panel.  

Issue The EcoStruxure Building Operation demo environment can be accessed online or downloaded as a backup file for local demonstration. There may be confusion regarding availability of demo versions, usernames and passwords, differences between online and offline demos, and the support scope for demo databases. Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation demonstration database Cause Users may experience confusion when accessing the EcoStruxure Building Operation demo environment because multiple delivery methods (hosted online and local offline databases) are available, each with different access methods, behaviour, and support expectations. This can lead to inconsistent experiences such as shared changes in the online environment, differences in login credentials, and uncertainty about what is supported, particularly when users assume the demo behaves like a standard, single-user or production system. Resolution Two demo options are available: Online demo (hosted environment) Accessible via Schneider Electric hosted demo platform. Multiple users may be logged in simultaneously, and actions performed by other users may be visible and impact the demonstration experience. Offline demo (local installation) A backup copy of the demo database can be downloaded from mySchneider and installed locally to ensure exclusive access and a controlled demonstration environment. The database can be reinstalled at any time to restore the original state. Access to supporting materials: Login credentials and user guides are available via mySchneider Support expectations: The Demo Database is provided "as is" and is not supported by Product Support Product Support may assist with installation of core software components such as License Administrator or Enterprise Server Product Support does not support demo database content, features, or behavior

Issue Continuum i2 and b3 field devices use the same hardware. With the exception of their -V models and the bCX (bCX9640/bCX4040) controller, they were not designed to have their firmware swapped from Infinet to BACnet (or BACnet to Infinet) in the field. Product Line Andover Continuum, EcoStruxure Building Operation Environment Continuum i2 Controllers (except -V) Continuum b3 Controller (except -V) Warning Potential for Data Loss: The steps detailed in the resolution of this article may result in a loss of critical data if not performed properly. Before beginning these steps, make sure all important data is backed up in the event of data loss. If you are unsure or unfamiliar with any complex steps detailed in this article, please contact Product Support for assistance. Cause With the exception of the -V controllers, the devices were not designed to have their protocol (Infinet/BACnet) swapped in the field, however, due to changes in market needs R&D is now providing a method to allow the protocol to be changed in the field. Resolution IMPORTANT NOTES: If a RoamIO2 is available, it can be used to do the conversion without the need to have Continuum Cyberstation and Continuum controllers. https://community.se.com/t5/Building-Automation-Knowledge/Conversion-of-Continuum-devices-from-i2-to-b3-and-vice-versa-in/ta-p/448337    If the device you are converting is of model i2/b3 865/866/885 STOP First confirm that the device is NOT a -V device, this is accomplished by editing the device and inspecting its version number, -V devices have a "1" embedded in the second part (after the ".") of the version number   A non -v device will show the above version number as follow,,, 3.500027   To convert i2 field devices into b3 BACnet (or vice-versa) from CyberStation Contact PSS and request the conversion files for the specific model(s) you wish to convert. Follow the procedure detailed below or as per the attached document. To swap the firmware of any non -V i2 device from one protocol to the other (in this case, from Infinet to BACnet b3), you use the following procedure.  For more information, see section 1.3 “Converting Infinet i2 Field Devices to BACnet b3 Devices from CyberStation” below. NOTE: This procedure was developed by Schneider Electric’s R&D and tested in the Product Support Services (PSS) lab.   Before starting the procedure, you need the following items: An I2 device(s) to be converted. A Continuum CyberStation with i2 device(s) configured and online. A special, conversion b3 upgrade file for the appropriate device model as provided by PSS A b3 bootloader file for the appropriate device model, provided by PSS Physical access to the device.  You need this to push its Restart switch or to access the switch or breaker where you can shut off power to the device to force a restart. A bCX4040 controller configured in CyberStation xP Expansion I/O Note If the device to be converted from i2 to b3 has any expansion modules attached, make sure the modules do not exceed the power capacity of the expansion port (180 mA), it has been observed that the b3 devices adhere more strictly to the 180 mA limit than the i2 devices, resulting in loss of operation on IO channels located on the Expansion Port if the power limit is exceeded.  See attached xP Expansion IO Datasheet for information on power consumption of each xP IO module.   1.2 Preparing the Field Bus for the i2 to b3 Device Conversion To ensure a smooth conversion, it is necessary that you reduce the traffic on the field bus as much as possible in order to provide the necessary bandwidth to the upgrade operations required for the conversion. Before starting the process with the conversion file, be sure to follow these instructions.    To prepare the field bus for the i2 to b3 device conversion Disable all the programs in all the devices residing in the field bus. Close all Continuum Workstations except the one performing the upgrade. In the Workstation performing the upgrade, close all graphics, List views, and anything else that could be polling data from the field bus. Make sure MS/TP field bus is on same baud rate as Infinet field bus, mainly 19.2K 1.3 Converting i2 Field Devices into b3 BACnet from CyberStation You can convert Infinet i2 field devices into b3 BACnet field devices by swapping the firmware of any non -V model i2 device. IMPORTANT: When using this procedure, be aware of the following guidelines: It applies ONLY to the firmware or communication protocol (Infinet or BACnet) of the device. It does not convert the control application in the device. Following conversion, the device’s memory is cleared, so you need to configure a new control application. It may result in a loss of critical data if not performed properly. Before beginning, ensure that all important data is backed up in the event of data loss or the device losing its application and becoming non-operational.  For more information, see section 1.1 “Introduction” above. To convert i2 field devices into b3 BACnet from CyberStation Contact PSS and request the conversion files for the specific model(s) you wish to convert. You will be provided with an application file (namely, i2920toB3920B4.500077.upd) and a boot loader file (namely, B3920BootB4.500077.upd). From CyberStation, edit the i2 device and record its Serial Number and Infinet id. Consult the General tab to locate this information. From the Runtime tab, perform a Reset to clear the device’s database. Upgrade the i2 device using the application file provided by PSS. Once the upgrade is complete, the i2 device stays Offline since its communication protocol has now been swapped from Infinet to BACnet. Disconnect the device from the Infinet field bus of its host master controller (for example, a CX9680 or a bCX9640). Connect it to the bCX4040 MS/TP field bus. (MAKE SURE MS/TP FIELD BUS IS RUNNING AT SAME BAUD AS INFINET FIELD BUS DEVICE WAS ON, NAMELY 19.2K BAUD) In the bCX4040, configure a b3 device using the appropriate model as well the Serial Number and ID recorded previously. NOTE: You will need to provide BACnet Device ID. Typically, it will be the same as the Serial Number. You can also use a Learn to bring the device online under the bCX4040 and automatically assign the model, id etc.  Refer to this Knowledge Base article on using the serial number for the Device ID.  Remember here to set the Comm Port for comm2. Restart the device either by power cycling or using the restart button. The device will come online under the bCX4040 as a b3 device. Perform an Update b3 OS operation to send the appropriate b3 boot loader file provided by PSS. Go to the Runtime tab, and reset the device once the update is finished. Once the device reboots and comes back online, you can confirm it has the right boot loader by looking at the device from the BACnet side. The screenshots that follow display the before and after results of the i2 to b3 conversion process. Before: After: NOTE 1 If Continuum system is not available it is also possible to convert i2 to b3 using RoamIO and EBO server using the following steps Disconnect device from field bus and connect RoamIO directly to i2 device. Use InfinetServiceTool to send the application conversion file to the i2 device. After the uprev operation is done disconnect RoamIO and cycle power to the i2 device Connect converted device (now a b3) to MSTP of AS-P or other EBO server that supports BACnet MSTP Perform a b3 learn operation to bring the device online Right click the b3 device and proveed to 'Device->Update firmware...' Navigate to appropriate boot loader file for the b3 model After uprev of boot loader is complete, cycle power to the b3 device. NOTE 2 Similar steps can be used to convert b3 device to i2 device. Make sure to use the V2 version of the b3 to i2 conversion files as it was found the original set of b3 to i2 conversion files did not work in some cases. Please note that once a b3 device has been converted to i2 using this procedure the device will ONLY accept conversion uprev files, attempt to uprev using regular uprev file will result in the following error:   This Uprev file does not match this type of controller. This applies to b3 to i2 conversion only, it does not apply to i2 to b3 conversion.

Issue Users are unclear about how to complete the offline registration process in EcoStruxure Building Operation, particularly regarding the location and use of the System ID and Registration Code. Product Line EcoStruxure Building Operation Environment EBO Systems requiring offline activation Cause This confusion arises due to: Misinterpretation of the registration email: Users expect both the System ID and Registration Code to be included, but only the System ID is provided. Limited visibility of the registration code: The code is only shown in the browser on the online machine used for registration. Manual transfer requirement: Users may not realize that the registration code must be manually copied to the offline machine. Uncertainty around System ID resets: Users may not know how or when to reset the System ID, especially after hardware changes or reinstallation. Resolution System ID Visibility: The registration email contains only the System ID. The registration code is not included in the email. Where to Find the registration Code: The registration code is displayed in the web browser on the online machine during the registration process. This code must be manually copied and entered into the offline machine to complete activation. Resetting the System ID: If a reset is required, refer to the official guide: 🔗 Reset System ID – EcoStruxure Building Help Offline registration Instructions: 🔗 Offline Registration Guide 🔗 Registering Your System Offline Dialog Box

Issue An Engineering license obtained from Software Companion appears under the Demo license section in Workstation. This creates confusion about whether the license is behaving correctly or if it may impact system or configuration license validation.   Product Line EcoStruxure Building Operation Environment Building Operation 7.x Top server  Cause Both demo licenses and engineering licenses are currently tracked under the DemoLicense category. This is the expected behavior as confirmed by the product team. Resolution This behavior is expected and does not indicate a defect. To verify installed licenses: Check licensingmetadata to view installed licenses Demo licenses are listed under clientmetadata Engineering licenses are listed under servermetadata   The appearance of engineering licenses under the demo license icon does not impact system functionality or license validation.

Issue Direct bindings between Automation Server (AS-P) and Infinet (I2) controllers in EcoStruxure Building Operation (EBO) generate excessive Infinet traffic due to polling behavior. As the number of bound points increases, this can lead to network slowdowns and communication issues. Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation AS-P (Automation Server) Infinet network I2 controllers Cause Direct bindings configured through the EBO binding window or reference tab rely on polling mechanisms. For certain data flows (such as I2 to AS-P and I2 to I2 on the same network), values are polled at the configured interval (default 10 seconds), increasing network traffic. These bindings do not utilize the Continuum Import/Export (IE) system, resulting in inefficient, polling-based communication rather than event-driven updates. Note that for data flow from the AS-P to the I2 device, a direct binding maybe used because the AS-P will ensure data will be transferred only when the value changes. When doing DIRECT bindings via the binding window in EBO to/from I2 devices here is a summary of how the transfer is done for the different data paths ASP to I2 (Irrespective of whether the value resides under the Infinet interface or not) The value is transferred only when it changes I2 to AS-P Value is polled per the binding interval I2 to i2 on same Infinet network Value is polled per the binding interval I2 to I2 on the second Infinet network of the parent AS-P The value is transferred only when it changes I2 on Infinet of AS-P to I2 on Infinet of second (remote) AS-P No support for Continuum IE system, value is transferred by AS-P only when it changes.  Resolution For data paths that result in polling, use script program-based bindings to transfer data between controllers. This approach leverages the Continuum Import/Export system, where values are transferred only when they change, eliminating continuous polling and significantly reducing Infinet traffic. For optimal performance: Use script programs for I2 to AS-P and I2 to I2 data transfers. For data paths that result in polling, direct bindings may be used for a small number of points where traffic impact is minimal. When using the Import/Export system via Scripts, for values that do not change frequently (such as occupancy schedules), implement a periodic refresh or forced export in the script program to ensure updates are re-transmitted in case for whatever reason an update failed to reach one or more devices. This approach ensures efficient, event-driven communication and helps maintain stable Infinet network performance.

Issue When attempting to upgrade TimescaleDB from version 2.27.0 to 2.28.0 (or 2.28.1) on PostgreSQL 18.0, the upgrade process fails with the following error: ERROR: could not load link library "C:/Program Files/PostgreSQL/18/lib/timscaledb-2.28.0.dll".The specified procedure could not be found. CONTEXT: SQL statement:"SET LOCAL search_path TO pg_catalog,pg_temp" link script file"timescaledb--2.27.0--2.28.0.sql",near line 6​ Product Line EcoStruxure Building Operation Environment External Log Storage using PostgreSQL v 18.0 Cause The failure occurs due to a binary incompatibility between PostgreSQL 18.0 and the TimescaleDB 2.28.x extension build. The extension was compiled against a newer PostgreSQL version, resulting in missing or incompatible library procedures when loaded on PostgreSQL 18.0. This leads to the “could not load link library” error during the upgrade. Resolution Upgrade PostgreSQL from version 18.0 to 18.4 to ensure compatibility with the TimescaleDB 2.28.x extension. PostgreSQL 18.4 includes the required library compatibility for the extension, allowing the upgrade process to complete successfully. Steps: Upgrade the PostgreSQL installation from version 18.0 to 18.4. Restart the PostgreSQL service after the upgrade. Re-run the TimescaleDB extension upgrade to version 2.28.x. Validation: Confirm the extension upgrade completes without errors. Check that External Log Storage is functioning and logs are being written correctly.

Issue External Log Storage in EcoStruxure Building Operation is not reporting a fully healthy state following restoration of connectivity. “Ready for reads” remains False after Enterprise Server restart, and synching-related counters remain high. Trend logs are visible and accessible in WorkStation, indicating partial functionality. Product Line EcoStruxure Building Operation Environment Enterprise Server with External Log Storage configured External Log Storage using Microsoft SQL Server External Log Storage using PostgreSQL Server Cause The observed behaviour is due to a large backlog of pending log writes that accumulated while the External Log Storage Server was unreachable. Resolution Following a period of database disconnection, a significant backlog of log data is expected to accumulate. Once connectivity is restored, the system gradually processes and writes this backlog, which may take an extended amount of time (hours or days) depending on the volume of accumulated data. The “Synching logs count” visible from System > Modules > LogStorageManager > ExternalStorage represents the number of pending log entries that have not yet been written to the database. Monitor the Synching logs count over time. If the value is decreasing, the system is operating correctly and progressing through the backlog. The status “Ready for reads = False” will persist until the backlog has been sufficiently processed and the Synching logs count is zero. 

Issue Information is requested on whether Security Expert supports AES-256 encryption for operator login passwords and whether these credentials are stored in the SQL Server database using AES-256 encryption. Product Line EcoStruxure Security Expert Environment Security Expert Microsoft Active Directory Microsoft SQL Server Cause There is an assumption that operator passwords should be stored using AES-256 encryption, whereas Security Expert instead uses hashing for local authentication and defers password storage to Active Directory when integrated. Resolution When using Security Expert native authorization for operator logins, operator passwords are processed using a hashing mechanism before being stored in the SQL database, ensuring they are not stored in a readable format. AES-256 encryption is not used for password storage.    When Active Directory (AD) authorization is used, Security Expert does not store operator passwords. Only the operator username is stored, and all password encryption and storage are managed by Windows Active Directory.   AES-256 encryption is supported for communication between readers, controllers, and the server, but not for operator password storage. For encryption details within Active Directory, refer to Microsoft Windows documentation.

Issue Understand methods for integrating Security Expert with Active Directory for creation and management of Operators and Users. Product Line EcoStruxure Security Expert Environment Security Expert Active Directory SX-AD-OPR SX-AD-USR SX-DB-SYNC PowerShell Cause Security Expert Active Directory Integration provides synchronization and authentication for Active Directory users enabling organizations to leverage on the user management and security policies that Active Directory provides. This article looks at the details between each integration option. Resolution There are four options for Active Directory Integration. 1. Default Windows Authentication option. This allows for logging in to Security Expert with the Windows User account credentials which could include AD users if on a Domain. Operator object must be created in Security Expert and configuration of windows authentication option has some specific steps to be followed for it to work. Unable to login to Security Expert using Windows Authentication Remember to use syntax "<domain>\<username>" for the username when configuring the Operator for a Windows user ON a  Domain. Remember to use syntax "<computername>\<username>" for the username when configuring the Operator for a Windows user that is NOT on a Domain. No extra license is required for this. 2. SX-AD-OPR : License for adding Security Expert Operators from AD. Security Expert Operators will need to be added manually using the following steps: Navigate to Operators and click Add. Check the Windows Authentication box. Click the ellipsis adjacent to the User Name. Use the Active Directory Users window to search for the AD credentials you wish to use. Once the Operator has been added, you may check the Windows Authentication option when logging in. 3. SX-AD-USR : License for adding Security Expert Users from AD. This will allow an active directory domain windows group to be periodically polled for updates that will in turn update the Users in Security Expert. Individual options for importing users, disabling user if AD user is disabled, disabling user if AD user is deleted. Only user names are imported, other than this only action can be disabling of users in Security Expert. No other details can be updated or added. See application note AN-141 Security Expert LDAP User Import Configuration. 4. SX-DB-SYNC : Data Sync Service with Powershell script. Powershell script pulls user details out of AD and writes to a CSV file that the Data Sync Service then imports into Security Expert. Can perform more functions than SX-AD-USR as any attribute from AD users can be mapped to any attribute in Security Expert users. Will require powershell experience as the sample script may need to be modified. See SEC-APP-03-1.0 – SX AD integration using PowerShell for a sample script and in-depth details on how to configure this solution for importing User data. See SX-DB-SYNC Security Expert Data Sync Service Integration Guide for details on setting up and using the Data Sync Service. The guide is in the package ZIP file.

Issue What is the password policy for Security Expert operators, and how can it be configured to meet specific cybersecurity requirements? Product Line EcoStruxure Security Expert Environment Security Expert Server Security Expert Client Cause Some sites require customized password policies to comply with cybersecurity standards. These may include requirements such as: Enforcing regular password changes Preventing the reuse of previous passwords Setting minimum password length Requiring strong password complexity Resolution   Default Password Policy in Security Expert By default, Security Expert enforces the following password policy for operator accounts: Minimum password length: 8 characters Password change required: On first login For more information on Security Expert’s cybersecurity practices, refer to the SX-SRVR Security Expert System Hardening Reference Guide. Custom Password Policies via Active Directory Integration Security Expert does not support advanced password policy configuration directly within the client interface. However, enhanced password policies can be enforced by integrating Security Expert with Windows Active Directory. To implement this: Integrate Security Expert with Active Directory Follow the steps outlined in Option 1 of the How to Integrate Active Directory with Security Expert article or Option 2 for full Active Directory integration. See AN 288 Security Expert - Using Active Directory - Integration Guide for additional details. Configure Password Policies in Windows Domain Once integration is complete, operator accounts managed through Active Directory will adhere to the domain’s password policy. This allows you to enforce: Password expiration intervals Password history restrictions Minimum and maximum password lengths Complexity requirements (uppercase, lowercase, numbers, symbols)

Issue A large number of “Duplicate Network Identifier” alarms are generated when a BACnet network is shared between Schneider Electric and Third-party systems. Device discovery does not show duplicate device instance IDs or overlapping network IDs, and the alarms appear to originate from a BACnet gateway. Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation ES / AS Site with Schneider Electric and Third-party managed BACnet networks Cause Packet analysis shows multiple devices responding to “Who-Is-Router-To-Network” with “I-Am-Router-To-Network” messages. This indicates that multiple devices are advertising the same BACnet network numbers at the network layer (NPDU). As a result, multiple routing paths to the same network are exposed, which is not permitted by the BACnet standard and leads to routing ambiguity and duplicate network identifier alarms. Resolution Identify all devices that respond with “I-Am-Router-To-Network” on the shared BACnet internetwork and reduce routing to a single designated gateway or router per network path. To identify devices broadcasting the duplicate network IDs Capture BACnet traffic (e.g. Wireshark) on the relevant network Apply display filter such as bacnet.npdu.network_layer_message == 0x00 || bacnet.npdu.network_layer_message == 0x01 Identify the trigger request Who-Is-Router-To-Network   Inspect all corresponding responses I-Am-Router-To-Network from multiple devices Compare the advertised network numbers (Network List) in each response If multiple devices advertise the same network number, this confirms duplicate network identifiers Align BACnet network configuration between Schneider Electric and Third-party systems to ensure that network numbers are unique and not advertised by multiple routers.

Issue Poor communication is experienced between an Automation Server Premium (AS-P) and Deep Sea Electronics (DSE) generator or switchgear Modbus RTU slave devices. Product Line EcoStruxure Building Operation Environment Building Operation Automation Server Premium (AS-P) Deep Sea Electronics (DSE) Modbus RTU slave devices Cause When upgrading from an Automation Server (AS) to an Automation Server Premium (AS-P), Modbus communication performance may degrade. Communication that was stable with the AS may become unreliable or poor when using the AS-P. Resolution Ensure the AS-P is running version v3.2.3.8000 to improve Modbus RTU polling performance. If the issue persists, or if upgrading is not possible: Access the DSE Modbus slave configuration using the DSE software tool Locate the Inter-Frame delay parameter Change the value from 0 ms to 1 ms

Issue The Loytec NIC-852 interface remains offline after upgrading from EcoStruxure Building Operation (EBO) 3.2 to EBO 6.0 or later. The interface shows as offline within EBO Testing via the Loytec plugin indicates no issues System logs display the error: NSP.Pin.lon.orion OrionInit returned error code [1] Reverting back to EBO 3.2 restores normal operation, and the NIC-852 comes online without errors Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation WorkStation Loytec NIC-852 Loytec software Cause   The Loytec NIC-852 driver is outdated and not compatible with EBO 6.0 and later versions.   Resolution   Update the Loytec NIC-852 driver: Download the latest driver from the Loytec website: https://www.loytec.com/support/download?view=docman/NIC852-SW Create and log in to a Loytec user account to access the download Install the updated driver for the NIC-852 Once updated, the NIC-852 will come online in EBO 6.0 and later versions

Issue Questions arise about whether External Log Storage supports partial backups, partial restores, or the reimport of external log data into EcoStruxure Building Operation, and how backup and restore operations should be managed when using supported third-party databases. Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation External Log Storage PostgreSQL with TimescaleDB extension Microsoft SQL Server AVEVA PI System Warning Potential for Data Loss: External Log Storage databases are independent of EcoStruxure Building Operation backups. Restoring, modifying, or relocating an external database without following the documented External Log Storage procedures can result in data loss or data inconsistency. Cause External Log Storage databases are third-party systems. EcoStruxure Building Operation supports only integration, configuration, and data write/query behavior. Backup, restore, retention, recovery, reconciliation, and database maintenance are not managed or validated by EBO and remain the responsibility of the customer’s IT or database administration team. Resolution EcoStruxure Building Operation (EBO) does not support backup, restore, or re-import of External Log Storage data, either partially or in full, for any supported database platform (including PostgreSQL with TimescaleDB, Microsoft SQL Server, and AVEVA PI). Key Behaviour The EBO backup file (.xbk) and the external log database are completely independent There is no automatic synchronization between EBO backups and the external database External log data cannot be restored or re-ingested into EBO Backup and Restore Responsibility All backup and restore operations must be performed using the native tools and procedures of the external database platform Database lifecycle activities, including: backup restore retention recovery are owned by the customer’s IT or database administration team Coordinated Backup Requirement If consistent recovery across EBO and External Log Storage is required, backups must be coordinated at infrastructure level EBO does not provide any mechanism to align or enforce this coordination Relocation or Restore of External Log Storage When restoring or relocating an External Log Storage database: the documented External Log Storage Backup and Restore procedure must be followed: Disable external logging in EBO Perform all required database-specific restore procedures Complete any pre- and post-restore steps defined for the platform Re-enable external logging in EBO Failure to follow the documented procedure may result in: Data inconsistency Loss of historical log data

Issue Otis Destination Dispatch integration with controller models MP4502 and LP4502 experiences instability where Destination Entry Controllers (DECs) repeatedly cycle online and offline, and elevator access control intermittently stops working. In some cases, controllers remain online locally but appear offline in the system, and elevators either do not respond to badges or allow free access. Temporary workarounds such as rebooting the controller, modifying IP settings, or adding/removing a reader restore operation for a limited time before the issue reoccurs. Product Line EcoStruxure Access Expert Environment Mercury MP4502 controllers (firmware 2.7.x, 2.9, 2.10) Mercury LP4502 controllers (firmware 1.29.x, 1.30.x) Otis Destination Dispatch integration Otis Compass 360 system Warning Potential for Data Loss: Ensure all important data is backed up before proceeding. Cause Instability occurs when using Mercury MP4502 controllers with Otis Compass 360 Destination Dispatch systems, resulting in intermittent loss of communication between the controller and Destination Entry Controllers (DECs).   Mercury MP4502 firmware has been validated with earlier Otis Compass integrations, but not explicitly with Compass 360. In this scenario, MP4502 firmware versions (2.7.x through 2.10) establish communication over TCP port 3001, however, sessions do not remain stable, leading to repeated disconnect and reconnect behavior.   The issue does not occur when using Mercury LP4502 controllers running firmware 1.30.2, indicating a compatibility limitation between MP4502 firmware and the Compass 360 integration in this configuration. Resolution Stability was achieved by replacing the MP4502 controller with an LP4502 controller running firmware version 1.30.2. After this change, DEC devices no longer exhibited online/offline cycling and the integration remained stable during operation. Additional actions taken during troubleshooting included: Upgrading MP4502 firmware to version 2.9, which did not resolve the instability Attempting firmware downgrade, which was unsuccessful Performing multiple temporary workarounds (controller reboot, IP refresh, configuration changes) that restored functionality only temporarily The validated outcome is that LP4502 firmware in the 1.x branch provided stable operation for the integration, whereas MP4502 firmware versions tested did not consistently resolve the issue. Continued coordination with vendors is required for a fully supported and validated solution for Compass 360 with newer hardware.

Issue A license violation warning is displayed on an EcoStruxure Building Operation server when using ION client interface features, even though an Advanced license is activated. There is also uncertainty about which license tier includes the ION client interface. Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation 7.1.x Advanced Tier license activated Cause The license warning is triggered because ION client functionality (including tenant billing) is currently classified as preview capability and is not mapped to any available EcoStruxure Building Operation license tier. Resolution This is expected behavior in EBO 7.1.x and no corrective action is required, the warning can be safely ignored when it appears in relation to ION client features. The warning may be triggered when interacting with ION-related functionality. Core EcoStruxure Building Operation functionality remains fully operational. There is no impact on system performance, stability, or licensing compliance for supported features. Validation To confirm the condition is understood and no issue remains: Verify that standard Building Operation functions continue to operate normally. Confirm that no other unrelated license violations are present. Ensure the warning is only associated with ION-specific features. Additional notes ION functionality, including tenant billing capabilities, is not currently part of standard licensing and may have limited or controlled availability. Availability of these features may change in future releases.

Issue After installing SmartConnector components and configuring the EBO EWS interface according to the official integration guide, the EWS server remains in an offline state in EBO, generating alarms “Gsoap_Communication__Error: 65535” and “Device offline.”     Product Line EcoStruxure Security Expert, EcoStruxure Building Operation Environment Security Expert WorkStation EcoStruxure Building Operation Security Expert SmartConnector Cause The EWS Server is disabled by default; if not enabled, communication between SmartConnector (SC) and EBO via EWS cannot be established, preventing SC values from being updated or reflected in EBO. Resolution Enable the EWS Server in EBO WorkStation to allow SmartConnector communication via EWS. Log in to EBO WorkStation to the Enterprise/Automation Server. Navigate to Control Panel - Web Services under the target server. Open EWS Server Configuration. Select Enable EWS Server.