Building Automation Knowledge Base

Issue What is the difference between an EBO SmartDriver and Smart Connector? Product Line EcoStruxure Building Operation Environment Building Operation SmartDriver Cause SmartDriver and Smart Connector enhance the openness for the EcoStruxure Building Operation, EBO, BMS system. They enable integration between EBO and 3rd party systems, even via not supported or nonstandard protocols. Resolution SmartDriver: SmartDriver enables you to create a customized interface to monitor and control 3rd party devices from the EBO server. The following block diagram shows a SmartDriver Interface and a SmartDriver Driver. The SmartDriver Interface (similar in concept to other protocol interfaces such as Modbus and BACnet) is part of EcoStruxure Building Operation software and enables you to create SmartDriver objects in the System Tree pane. The SmartDriver Driver is installed on the server drive and provides the network communications control. More information at Web Help SmartDriver Overview. Smart Connector: A development framework that simplifies and accelerates integrations with third-party systems or other data sources. It is an open, extensible and configurable application framework that allows developers to create innovative new capabilities, applications, and solutions that extend and enhance EcoStruxure Building solutions. The Smart Connector itself runs outside the EBO server and consume or server data to EBO server via the EcoStruxure web services "EWS". Watch short explainer video for more information: https://www.youtube.com/embed/DXHvRRL4ycY   For more information, visit the Smart Connector Developer Community on the Exchange: https://community.se.com/t5/SmartConnector/ct-p/smart-connector   For developers wanting to get started using the Smart Connector framework visit: https://www.smartconnectorserver.com   Smart Connector shop at Exchange:  https://shop.exchange.se.com/en-US/home 

Issue Need to upgrade V3 Access Expert On Premise software to the most current version in order to gain additional functionality. Product Line Access Expert Environment Access Expert Premise Software V3  Cause It is unclear how to upgrade the Premise V3 software to the most current version of V3. Resolution Access Expert Premise Upgrades now require an SLA to obtain the actual software. Please contact your Sales and/or Security Contact for more details. Both the Access Expert (AX) Premise Server and Client Software need to be upgraded in order for additional features to work. Please note that you will experience issues if your AX clients do not match the AX server version. Take a backup of Mongo database (See MongoDB Backup section located here: https://community.se.com/t5/Building-Automation-Knowledge/Backup-and-Restore-MongoDB-for-Windows-for-Access-Expert-On/ta-p/583) Ensure ALL Windows Updates are completed. Capture screenshots of software installed on server. This can be done by navigating to Control Panel > Add/Remove Programs. It is imperative that you capture the following software and their versions: Access Expert Keep MongoDB SEQ At the writing of this, AX 20.3.1 is the latest. Please check this link to see if there is a new release. Once you have the software downloaded, there will be seven (7) files in the folder: Right-click on “Feenics.Keep.Installer.exe” From there, follow the steps from the Keep by Feenics On Premise Deployment Walkthrough starting from page 8 through page 18.  Note: You must be logged into the Feenics website to access the link in this step.  Navigate to https://www.feenics.com/training/ to login and then click the link above in this step. After a successful installation, click on the “Setup_AX.msi” or “Setup_AX.exe” file to install the latest On Premise client for customer machines. If you run into any issues, please contact Product Support and Services by submitting a case here: https://www.nampss.com/ If you require assistance or would like Schneider Electric to perform this upgrade for you, you can submit a request for that here: https://www.nampss.com/apps_request.php

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. Issue Introducing a previously commissioned Continuum IOU module such as an AC-1 to an Access Expert or Security Expert site can cause communication issues in the LON bus due to duplicated node id. Product Line Andover Continuum, EcoStruxure Security Expert, EcoStruxure Access Expert Environment Continuum AC-1 Continuum Net Controller Continuum Net Controller II Access Expert Controller Security Expert Controller Cause When IOU modules are commissioned in a Continuum system, the Net Controller assigns each module a Node ID, this is in addition to the LON Module ID that is unique to each module hardware, the purpose of the Node ID, is to decouple the identifier used by Continuum for communication from the specific piece of hardware, this in order to facilitate the replacement of a failed module without the need to change its Continuum identifier. The module stores the Node ID in nonvolatile memory so that it persists across power loss. If a Continuum IOU module is introduced to a LON network (Security Expert SP-AC1 or Access Expert AX-SSC) without clearing its Node ID, there is a risk of creating a duplicate Node ID condition that will prevent the LON network from operating properly. IMPORTANT This should not be an issue during the normal transition of Continuum site to Security Expert or Access Expert, as all the modules on the running LON bus should have unique Node IDs, this is only a problem when adding a module, or replacing a module with one that has been used before. Resolution In order to signal its presence on the LON network, each module will transmit on resetting its status network variable. If upon receiving this message, the Net Controller determines that the module is NOT in its local database, the controller will decommission the module by setting its Node ID to zero. Before introducing a Continuum IOU module that has been previously commissioned to the LON network of an SP-AC1 or SX-SSC controller, decommission the IOU module using the steps below: Attach the module to an empty Net Controller that is powered down with its battery removed. For a Net Controller II, in order to be absolutely sure that the Net Controller has an empty database, you may need to clear its backup in flash from a browser or by the use of the reset IP switch. See LL on how to use the controller's reset IP switch to clear its flash backup https://community.se.com/t5/Building-Automation-Knowledge/How-to-clear-the-controller-flash-backup-from-the-hardware-using/ta-p/5877 Power up the Net Controller Once the CPU led on the Net Controller starts blinking, press the 'Reset' button on the IOU module. Wait 30 seconds to make sure the decommissioning process has completed. Power down the Net Controller Remove the IOU module

Issue When running VisiSat 2.1 build 196 (200 or 201) a message is displayed - “Unable to Load the Schneider Electric CET Style DLL” and VisiSat fails to launch. Product Line Satchwell MicroNet Environment Windows (Windows, XP Professional, Windows 7, Windows Vista Ultimate) Microsoft Visio Cause .NET Framework 2.0 is not installed. Resolution Check that the version of VisiSat installed is either v2.1 196 or for SP1 build 200 or for SP2 build 201 on a computer running with a supported operating system and Microsoft’s Visio version.   MicroNet Software Datasheet   The suggested procedure to correct the “Unable to Load the Schneider Electric CET Style DLL” issue as follows: - Uninstall VisiSat Install .NET Framework 2.0 Install VisiSat 2.1 196, add service packs 1 and 2 files as required. Re-boot computer Run VisiSat. Links to VisiSat software and information:   The VisiSat main software can be downloaded from the link below: https://ecoxpert.se.com/search?documentUUID=c93346a7-9d82-48e7-9b54-a866ac75bb71&title=VisiSat%202.1%20Build%20196%20-%20Software   VisiSat service pack 1 can be downloaded from the link below: https://ecoxpert.se.com/search?documentUUID=fd2e9849-1ffe-4c10-b3a6-5f27bac91870&title=VisiSat%20Release%202.1.196%20Service%20Pack%201%20(2.1.200)%20-%20Software   VisiSat service pack 2 can be downloaded from the link below: https://ecoxpert.se.com/search?documentUUID=839c09d2-400d-4434-8b1e-97f339545034&title=VisiSat%20Release%202.1.196%20Service%20Pack%202%20(2.1.201)%20-%20Software   VisiSat documentation can be downloaded from the link below: https://community.se.com/t5/Building-Automation-Knowledge/Download-latest-VisiSat-Data-Sheets-Engineering-Guides/ta-p/6110

Issue Is it possible to print alarms automatically with SBO Workstation in matrix printer whenever there is an alarm? Product Line EcoStruxure Building Operation Environment Building Operation Workstation Cause A number of sites still prefer to directly connect a Dot Matrix Printer to their BMS to automatically print off incoming alarms rather than using more modern emailing of alarms available from EBO. Resolution The following File2Printer software has been made freely available on the EcoStruxure Building Operation Community for exactly this purpose. https://community.se.com/t5/EcoStruxure-Building-Operation/File2Printer/m-p/351127#M71948

Issue 37-bit cards not working correctly even though a Credential Type has been configured correctly for Infinity37 cards (as seen below), the site code and/or card number read does not match what is printed on the card or the expected value. Parity errors could also be seen if the card is not truly of the Infinity37 format. Product Line Security Expert Environment Security Expert Server Security Expert Controller Cause Various cards have 37-bit data lengths but different formats; some guidance is needed on how to differentiate the ACC Infinity37 cards.  Resolution There are two pieces of data that can be used to verify if a 37-bit card is ACC Infinity27 format.   ACC Infinity 37 card format includes a Manufacturer's Code field; the field is 4 bits long, starting on the second bit and ending on the fifth bit. The Manufacturer's Code field always has a value of 4, the first bit of the card is used for the ODD parity, so the first 5 bits of ALL ACC Infinity37 cards ALWAYS look like P0100.... If we see a raw bitstream of a 37-bit card like the one in the screen capture below, we can immediately determine that even though the card has 37 bits, it is NOT an Infinity37 card since bits 2,3,4 and 5 do not add up to a value of 4 See https://community.se.com/t5/Building-Automation-Knowledge/How-to-display-RAW-bit-data-stream-of-Wiegand-card-in-Security/ta-p/390720  We can not assume that because a 37-bit card has  0100 on bits 2-5 it is 100% evidence that the card is indeed an Infinity37 card since that pattern (0100) could be present on the card as part of a different field (i.e., Site Code) on a different 37-bit card format. The second piece of data that could help determine if the card is true of the Infinity37 format is the parity bits, Infinity37 card format has a somewhat unique interlaced parity scheme. If parity errors are seen when cards are presented to the reader, this should be taken as an indication that the 37-bit card might not be Infinity37 card format. The attached zip file contains an Excel sheet that can be used to calculate the parity bits of an ACC Infinity37 card by entering the raw bitstream of the card; if the calculated values for both parity bits (bits 1 and 37) do not match what the card has, then the card is NOT an Infinity37 card format.    

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. Issue There is a limit of around 200 user-created objects in b3/i2 devices, once that limit is reached, an attempt to create a new object of any type in the device will result in  "Invalid Handle" error. See https://community.se.com/t5/Building-Automation-Knowledge/Creating-an-object-in-a-BACnet-B3-or-Infinet-controller-results/ta-p/9490 for more info.   Product Line Andover Continuum, EcoStruxure Building Operation Environment Continuum b3920 Controller Continuum i2920 Controller Cause Each Continuum object is represented in the system by a "Handle Id", in b3/i2 devices, the handle ID is stored in the controller as a byte value which allows for a maximum of 255 handles, the system objects (System Variables etc.) use around 55 of the handles leaving around 200 for user-created objects.  CX controllers store handle IDs using a 2 bytes value, which allows for 65535 handles, CX controllers rarely run out of handle IDs. Resolution One way to deal with this limitation in the Continuum field devices is to combine InfinityNumeric, InfinityDateTime objects (when possible) into one object configured as an array (manual log).   EXAMPLE: The screen capture below shows 10 InfinityNumeric objects in an i2920 device that are used in the control application of a room named "MainLab"     Let's say for the purpose of this illustration that the following is the control program for MainLab     Since InfinityNumeric objects MainLab.a thru MainLab.j are used exclusivity to store values *** (i.e Setpoint etc), we can configure one of the objects as an array and have it hold all 10 values, thus allowing us to delete 9 InfinityNumeric objects and free 9 handle ids       Before deleting MainLab.b thru MainLab.j we need to modify ALL references to those objects, instead of referencing MainLab.b - MainLab.j we need to reference MainLab.a[1] - MainLab.a[9], note that MainLab.a holds its value (70) normally (not as part of the array), so in this case, we are only using 9 of the 10 array elements.     ***IMPORTANT Only InfinityNumeric and InfinityDateTime objects that are used exclusively to hold a value should be combined, if the object is being used for any of the following operations then it should be left as its own object.   Object triggers one or more programs Object is configured as a log Object is Occupancy flag of a schedule Object has alarms associated with it or is alarm point Object is a setpoint

Issue Are there any Example Reports for the new native Notification Reports which came out in EBO 3.2 to replace the now deprecated WebReports and Report Server? Product Line EcoStruxure Building Operation Environment Building Operation Workstation Cause As of EBO 2022 (4.0) WebReports and the Report Server have now been deprecated and replaced by External Log Storage using Postgres SQL and Timescale DB, plus the new native Notification Reports which are now built into EBO 3.2 and above, but there are no examples to help new starters to get going. Resolution A Schneider-Electric Community page has been set up specifically for Notification Report users so that they can share their Reports and collaborate on Reporting ideas: https://community.se.com/t5/EcoStruxure-Building-Operation/Reports-showcase-share-your-reports/m-p/388619#M75732

Issue PT1000 temperature sensors RTD Input Product Line EcoStruxure Building Operation Environment AS Classic, ASP  UI16, RTD-DI-16 - Central IO Module ASB, RPC, MPC Need for temperature to be extremely accurate PT1000 platinum resistance thermometer, RTD Resistance Temperature Detector Cause The AS Central IO Module Universal Inputs (UI16) were designed to interface to various thermistors that can have resistance values that are usually much higher than 1000 ohms. They were not designed to interface directly to a PT1000 RTD, and will not provide good accuracy when measuring these lower resistance sensors. The resistance input type was intended to allow for measuring the position of a 10K potentiometer that is used on some wall sensors. The accuracy specification for a resistance input is: +/-(7+0.004*R) ohms. This would result in an error of +/-11 ohms at 1000ohms – therefore a temperature measurement error approaching +/-3.0C. Resolution AS, ASP For RTD PT1000 (Pt100, Pt1000, Ni1000, LG-Ni1000, JCI-Ni1000) use RTD-DI-16 - Central IO Module, then choose 2 or 3 wire RTD Temperature Input ASB Choose 2-wire RTD Temperature Input (Pt1000, Ni1000, LG-Ni1000, JCI-Ni1000) RPC, MPC, MPV Choose RTD Temperature Input (Pt1000, Ni1000, LG-Ni1000)   For more details see SpaceLogic Hardware Reference Guide

Issue Information for User Permissions using Access Expert is needed Product Line EcoStruxure Access Expert Environment Access Expert V3 Hosted Cause Access Expert User Permissions Overview  Resolution Overview User groups and permission are set by an Administrator to manage and control what aspects of the system an operator has. There are no default user login credentials. The user group (permissions) determines what areas of the software a user can access as well as what type of actions they can execute (i.e. update, delete, etc.).   User Groups A key aspect of the Keep permissions engine is the ability to explicitly Deny a trait or option for an operator. This Deny approach allows Administrators to quickly and easily create a new Permission group like an Administrative level operator but without a specific item.   User Group Lists From the General Configuration tab, click on the Groups icon in the Administrative section. This will open a list of all the Permissions currently available in your system. Every system comes with a single System Administrator permission level and there is no limit to the number of Permissions a single system can have.   Adding User Groups To add a new Permission: Click “Add Group”. Assign a Display Name. Assign a Description. The Description should be concise but also provide enough information about the functionality this role will have. Add desired Permissions. Click "Save" or "Save & Close". ***IMPORTANT: The minimum permissions to log in are read on the Instance.   Keep Objects Begin by adding rights to the new Permission Group. Note this process starts with the first available tab at the bottom of the screen which is the Objects.   Click Add Permission – This will start the process of building out the rights for this type of operator. A full list of Object Types will be provided at the bottom of this article with the associated Linking options. Key Terms: Object Type – the type of Keep object to be assigned. Object types follow the menu structure of the Keep system such as Access Levels, Badge Design and Controllers. Selecting the All Types option will provide full access to all aspects of the Keep system. Create – Allows the user to create new objects. Read – Allows the user to read the objects. Update – Allows the user to modify existing objects. Delete – Allows the user to delete the objects. Publish – Allows the user to publish events with the object type specified. Advanced Actions - Allows the user to enable advanced actions for integrations such as HID Origo and Single-Sign On. Linking – When an object type is selected the Linking column will become active. Each object type has a unique series of possible linking traits. When Linking traits are available, the Linking window will display “…”. By clicking the “…” the operator will be presented with the full list of possible traits that can be Added or Removed by checking the available boxes. Tags – A keyword applied to a series of objects within Keep to help provide additional separation of permissions. An example: an operator can be provided with Administrative level permission but only for items with a specific keyword. Applies To – Allows the administrator to limit controls to a specific device or series of devices. When being used simply click the “…” icon and the operator will be presented with the ability to choose the devices needed by clicking the Assign Object. Multiple objects can be added. Once the Assign Object icon is pushed simply start typing in the name of the device(s) needed. Type – Allows for Granting or Denying rights for the object type in that line. The second portion of setting up a new Permissions Group is to determine the Event Types that the operator will be able to interact with. Event Types is a very dynamic list because the available options will be determined based upon the integrations deployed on your system. The Event Types section is focused on the types of messages that an operator will be able to see as well as the type of commands the operator will be able to take. Key Terms: Application – the specific service associated with an application in the system such as Mercury Controllers, Allegion Locks, Video Expert, Mobile, and LDAP. Event Types – The specific traits associated with the Application. Each Event Type will be different and the options available will be determined by the integrations deployed on your system. Tags - a keyword applied to a series of objects within Keep to help provide additional separation of permissions. An example: an operator can be provided with Administrative level permission but only for items with a specific keyword. Type - Allows for Granting or Denying rights for the object type in that line. Object Types Each object type has a unique series of possible linking traits. When Linking traits are available, the Linking window will display “…”. By clicking the “…” the operator will be presented with the full list of possible traits that can be Added or Removed by checking the available boxes.

Issue Information is needed about the Access Expert Kone Elevator Integration Product Line EcoStruxure Access Expert Environment Access Expert Hosted V3 Cause Kona Elevator integration information  Resolution Overview: Destination Dispatch is a licensed feature for Access Expert and used when customers are modernizing their elevator systems or deploying newer ones which do not utilize the relay-based approach for floor control and selection. Within Access Expert, 3 different elevator platforms are supported which include Otis, Kone and ThyssenKrupp. For this document, we will focus on a KONE deployment. It is important to note that a single Access Expert can support multiple integrations at the same time. The KONE integration supports up to 128 total floors of control. When using front and rear entry points within the elevator cabs), each entry point is considered to a separate destination. This means a 32- story building using front and rear entry points will result in 64 individual destinations.   A KONE protocol was created so that the LP controllers can manage access for the KONE Elevator Group Controller. Mercury will support configuration for Destination Operation Panels (DOPs), Car Operation Panels (COPs), and turnstiles. This feature is supported on the LP4502, and EP4502. The support for KONE Elevators was added in firmware 1.25.5.   Prerequisites: 1. Access Expert System 2. KONE Destination Dispatch License - FN-DEST-KONERS 3. Appropriate Reader Licenses 4. AX-LP4502 5. Coordination with the Elevator Contractor A KONE Elevator Destination Dispatching System mode was created within Access Expert so that the LP4502 intelligent controller can inform a KONE DEC (Destination Entry Computer, E.g. touch screen or keypad) allowed and authorized floors for a cardholder. This feature is only supported on the LP4502.   Controller Page 1. On the LP4502 controller page, navigate to the "Destination Dispatch" Tab. 2. Select Kone. 3. Enable "Has front and rear floors" if your Kone setup has front and rear floors. Make sure to take into consideration this flag when assigning elevator floors access. It is also recommended to consider the door when creating names. Examples like 2F or 2R are beneficial to system operators. 4. Set the Maximum Cabin Configurations. This is the number of Kone Cabin Access configurations that can be stored on the controller. 5. Press Save. 6. From the "Add Downstream" dropdown, select Kone KGC under the network port. 7. Enter the Display Name to be applied to be used.  8. Enter the KONE primary KGC IP address and Port. 9. Leave 2005 as the default port number. Press Save 10. Repeat steps 6 to 8 for the Backup KGC. 11. Issue a "Push Controller Database" command.   Reader Page Once the Interface Controller has been saved, add/Navigate to a reader attached to the Controller, and move to the elevator tab. The Reader does not reside on the KONE KGC downstream. The KGC downstream is only used to configure the controller with the Primary/Backup KGCs. The readers must be on the regular Mercury downstream modules or attached to the LP4502. Because of this, the actual reader setup is similar to a regular door/elevator deployment with the addition of new settings on the Elevator Tab. Once the Elevator Type is set to Destination Dispatch, a series of settings will be enabled and displayed. You will be presented with a WARNING Message when the Elevator Type is selected. This message is normal and you should select YES. 1. On the reader page, navigate to the "Elevator" tab. 2. Select "Kone Destination Dispatching" as the Elevator Type. 3. Select the Kone Operation Type. Please note that Kone does not support mixing Remote Call Giving Interface (RCGIF or turnstiles) with Destination Operation Panel (DOP) and/or Car Operation Panel (COP). Only one is supported at a time. 4. Depending on the Operation Type, specify the fields. 5. If desired, select an Override Elevator Access Level. This will allow a set of floors to be public during defined schedules. 6. Press Save. Kone Cabin Access Page 1. Navigate to "Access Configuration" on the Main Ribbon bar. 2. Go to "Kone Cabin Access". 3. Click on "Add Kone Cabin Access". 4. Enter a Display Name. 5. Enter the allowed cabins (up to 255). You can use the following formats to enter values: 1-10,15,16. 6. Press Save. Person Page Once the reader has been saved navigate to the person(s) who you want to grant access to the destination dispatch and select the new destination dispatch tab at the bottom of the page this will take you to a new Destination dispatch tab. To add an Elevator user setting, simply select the elevator type you wish to grant access to and click the add button. You will be prompted to select a controller. If there are no active LP4502 elevator controllers, then the dropdown will be empty meaning the user needs to add a valid controller. 1. On the person page, navigate to the "Destination Dispatch Settings" tab. 2. On the "Kone Settings" tab, click on "Add Kone Setting". 3. Select the Kone controller and press OK. 4. Enter the Default Floor. 5. Enter the Default Floor Side. 6. Select a Cabin Access 7. Select the Kone Elevator flags to be applied to the person. 8. Press Save.  *Users must configure the Instance Settings to reflect the correct number of floors. The Cab used will be sent by the Kone system to Keep on an 'Access Granted' and displayed in event data. Masks Kone has Global and Specific Masks that are used when setting schedules. These can be set and cleared by right-clicking on the controller and selecting the appropriate option. Setting the Global Mask opens the Global Mask Configuration window. To add a floor configuration, click the "Add Floor Configuration" button, then select the desired floors. From there the options for each floor can be selected by setting the appropriate flags for the floor. Click "OK" to save the changes. Other Information: Each Elevator Manufacturer has specific settings, commands or fields when deploying the Destination Dispatch integration. The following are specific to KONE: Supported Reader Types: 1. Destination Operation Panel (DOP) – Destination operation panels are located outside of the elevator car. Each of these will be configured as a separate reader. 2. Car Operation Panel (COP) – Destination operation panels are located inside the elevator cab. Each of these will be configured as a separate reader. 3. Turnstile (RCGIF) – Turnstiles are half-height sensor barrier solutions designed for public and commercial buildings and airports. Each turnstile will be configured as a reader and must use a Mercury reader port.

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. Issue Access Expert SSC and Mercury controllers require firmware updates Product Line EcoStruxure Access Expert Environment Access Expert V3 Hosted Cause SSC and Mercury controller firmware needs to be updated for a fix or feature change Resolution Overview Mercury Controllers operate based on their firmware version and programmed configuration within Keep. It is necessary to update the Mercury firmware on occasion to ensure the most recent features, bug fixes and security upgrades are on the Mercury panel.    Updating Firmware Mercury controllers can be updated using the Keep by Feenics software. Before updating the controller, confirm the controller is powered on and connected to a Keep by Feenics instance. It is important to have a stable internet connection throughout the entire firmware update process. The duration of the firmware update will depend on the network bandwidth but typically will take between 5 to 10 minutes for a complete update. Users can issue multiple firmware updates to different intelligent controllers at the same time, but not downstream devices.   Updating the Firmware on a Controller To update the firmware on a controller: Open the controller page.  Beside the Version field, click on the "Update Firmware" button. Open the Live Monitoring window and set the priority to 0. In the Live Monitor, you will see the "Downloading Firmware Event". Once the controller has completed the firmware update, it will reboot.  After, close and re-open the controller page to see the updated firmware version. EP Controller Firmware The EP Series controller's current version is 1.29.1.633 and was released on 2020/01/31. Due to the controllers being End of Life, no new versions of firmware will be released for the EP series controllers.   On-Premise Deployments Note: On-Premise Deployments are no longer supported. All sites will convert to hosted. The previous process to upgrade firmware for On-premise deployments (servers managed on-site): They can have their firmware updated out of band by placing the latest Mercury CRC files in the appropriate directory. Once the files are in place users can proceed with the update steps outlined in this article. The default directory for firmware files can be found at C:\Program Files (x86)\Feenics\Mercury Service\MercuryFirmware. 

Issue When a value in one Automation Server is transferred to a value in another Automation Server what port is used? Product Line EcoStruxure Building Operation Environment EcoStruxure Building Operation Workstation EcoStruxure Building Operation Automation Server (ASP/ASB) Cause Documentation required on ports being used Resolution EcoStruxure Automation servers can use one of three different communication protocols: Transport Control Protocol - TCP Hypertext Transfer Protocol - HTTP Hypertext Transfer Protocol Secure- HTTPS   The communication protocol and ports are configured in the Server wizard when you add an EcoStruxure BMS server via the Enterprise Server   EcoStruxure Automation servers can listen on one of the three communication protocols from Version 1.3 upwards. The TCP port is fixed but please refer to Changing the Automation Server HTTP/HTTPS ports TCP on port 4444 (fixed) HTTP on port 80 (default) HTTPS on port 443 (default)   Each EcoStruxure Automation server maintains a list of all the other EcoStruxure servers in the system and the communication parameters of those EcoStruxure BMS servers. To see the list and which protocol/port is being used select the server (1), select the Communications tab (2) and view the list (3) or individual server settings (4). Note when selecting an Automation Server the individual server settings (4) of other Automation Servers will be greyed out.   When an automation server is added, its communication parameters are distributed by the Enterprise Server to all other EcoStruxure BMS servers in the system. For additional information please refer to EcoStruxure BMS Server Communication   If the IP address or protocol port number in an already commissioned EcoStruxure Automations server is changed, this information must be manually updated in the Enterprise Server Communication view. The Enterprise Server then distributes the new parameters to the other EcoStruxure Automation servers. Select the Enterprise Server (1), select the Communication tab (2), select the server to be changed (3), update the settings (4):   If there are problems with the communication parameters please refer to Inconsistent Communication Parameters

Issue Out of range alarm attached to i2 device does not work when point's value is out of the range. The 'Alarms' system variable in the controller shows 0 Product Line Andover Continuum Environment CyberStation All i2 devices All InfinityControllers Cause Out of Range alarm is a BACnet alarm and can not be used with Infinity points Resolution Use Expression or Infinity Low/High Limit alarm type.

Issue MSTP controllers go offline when changing the MaxMaster value in the Automation Server from it's default of 127 Product Line EcoStruxure Building Operation Environment Building Operation Workstation Building Operation Automation Server MSTP Master Controllers Cause The MaxMaster value is being set lower than some or all of the MSTP controllers on the network Resolution EcoStruxure Building Operation supports MSTP Master controllers in the address range 0-127 (often refered to as the node id). The MSTP network is a token passing network where the token is passed around the network, until a controller has the token it cannot 'talk' to other devices.   The MaxMaster value is defaulted to 127 to allow all devices on the network to receive the token and reply to online status requests, send values etc. If the MaxMaster value is less than any of the MSTP Master controller addresses then those controllers never receive the token and cannot respond to online status requests.   The value for the MaxMaster needs to be equal to or greater than the highest addressed MSTP controller node id.  For example, if the highest node id=54 then the MaxMaster will need to be set to 54 or higher. For maximum efficiency the MaxMaster should be set 1 or 2 greater than the highest controller address, this allows for adding future devices without needlessly polling for many non-existent devices.    Please refer to BACnet MS/TP Network Properties – Basic Tab or Configuring the MS/TP Network for b3 Communication 

Issue Alarm colors in Workstation Product Line EcoStruxure Building Operation Environment  Building Operation Workstation Cause The default color for active alarms is white font with a red background. Some customers may want this to be in a different color.  Resolution In Building Operation Workstation System tree, go to Alarm Control Panel > Alarm Styles.  From here, the font type, font color and background color of acknowledged, active, disabled, fault or reset alarm states can be changed.  Refer to: Styling the Alarm States in the Alarms Pane and Alarm Views   Also available from EcoStruxure Building Operation 1.9 and above is Alarm Decoration. This allows overriding an alarm configuration for a specific alarm or group of alarms and applying an alarm decoration rule.  An alarm decoration rule is similar to a filter and allows changing other properties in addition to the font type, font color and background color.

Issue How to generate a controller offline Event and Alarm in Security Expert for intelligent controllers. Product Line EcoStruxure Security Expert Environment Security Expert Server Cause Security Expert does not come with any programmed Events or Alarms.  This will detail how to create an Event and Alarm in Security Expert that reports a controller as being offline, but the method can be applied to other Events and Alarms as well. Resolution Navigate to Events -> Event Filter Add a new Event Filter.  In this example, it is named “Controller Offline Alarm. Click Save  Once the Event Filter is created, you will need to navigate to the Event Type option and un-check "Include All Event Types". Select Add and find the specific event.  In this example, it is called “Controller <CONTROLLER_NAME> Offline (Event Server)” and "Controller <CONTROLLER_NAME> Offline (Event Server)".  It is nested under the “All PC Events” section. Click OK, then Save Next, navigate to Events -> Alarms. Create a new Alarm. In this example, it is named “Controller Offline Alarm.” Under Configuration, select the drop-down for Event Filter and select the Event Filter that was created. (Controller Offline in this example). Save When an offline condition occurs, an acknowledgeable alarm will be displayed. It will also display an alarm when the controller returns to an online state.

Issue Is it possible to configure a Xenta 121/122 controller with an STR-150 and lock the thermostat so that the user cannot change the temperature setpoint from the STR-150 device?   Product Line TAC Vista Environment STR-150 Xenta 121 Xenta 122 STR Sensor Cause In some applications, you do not want anyone to change the setpoint from the room unit. Resolution It is possible to configure the STR150 device so that it is not possible to adjust the actual setpoint. Enter configuration mode for the STR150 by Pushing the fan and bypass buttons simultaneously for 2 seconds to enter P0. In P0, hold down the bypass button and push the fan button three times. Press the fan button until you see P7, and change the P7 value to zero. To Exit Configuration Mode, push the fan and man button for 2 seconds. The timeout will exit configuration mode if idle.

Issue How to change the STR-150 temperature display, setpoint adjustment range, etc. Product Line TAC Vista Environment STR-150 STR Sensor Cause The communication between the STR-150 and the TAC Xenta 121/122 device is one way, space temperature and setpoints are sent from the sensor to the controller. Therefore some STR-150 functions (for example, the setpoint adjustment) can not be configured though Zbuilder, but needs to be done manually in the STR 150 device. Resolution Buttons on the thermostat: Increase Button Decrease Button Bypass button Fan button Wrench symbol   Steps of changing the STR-150 configuration are listed below: Enter Configuration: Push the fan and bypass button simultaneously for 2 seconds to enter P0 In P0, hold down the bypass button and push the fan button three times to enter configuration mode. NOTE: the wrench symbol is lit when the STR-150 is in configuration mode.   In configuration mode: Press the fan button repeatedly until reaches desired parameters (refer to the configuration table below). NOTE: the two digits farthest to the left on the display show the parameters, while the two digits farthest to the right show the value Use increase button or decrease button to change the value.   Exit configuration mode: Push the fan and bypass button simultaneously for 2 seconds. Or, the timeout will exit configuration mode if idle.   Configuration Options: Parameter Function Value/Range Default value P0 Software Version - - P1 °C or °F temperature display 1=°C, 2=°F 1=°C P2 Reference temperature (Reftemp) 15-30°C / 60-90°F 22°C / 72°F P3 Setpoint or room temp. 1=Setpt, 2=Room 1=Setpt P4 Timeout 5-90 seconds 10 seconds P5 Fan Settings 0=No fan 1=On/Off fan 2=Two-speed fan 3=Three-speed fan 3=Three-speed fan P6 Room temperature and setpoint display resolution 0.1 or 0.5 °C 0.2 or 1.0 °F 0.5 °C or 0.2 °F P7 Max adjustable setpoint span above or below Reftemp (P2). +/- 0 - +/- 5°C +/- 0 - +/- 10°F +/- 3° or +/- 6°F P8 Bypass button and occupancy indication When = 2, no bypass command is sent  to the controller 1= Symbol on, off Or flashing 2=Symbol always off Default 1=on, off Or flashing P9 Setpoint as Absolute or Offset value 1=Absolute 2=Offset 1=Absolute   Click here to read STR-150 user's manual.

Issue Which communication paths are secured with encryption when Continuum network security (IPSec) is enabled? Product Line Andover Continuum Environment CyberStation NetController II - CX9680 ACX II - ACX5740, ACX5720 Cause Information required on Continuum network security. Resolution Continuum IPSec implementation secures communications between Continuum controllers and CyberStations.     The following paths are secured: CyberStation to CyberStation CyberStation to controllers Controllers to controllers. Controllers can be configured to allow communications with other controllers that do not support network security such as the CX9900. Consult the Network Security Configuration Guide for further information.   Securing the communication path between workstations running CyberStation and the DB server is outside the scope of the Continuum implementation and is left up to the site’s IT department to put in place.