Issue How can logging configuration be removed from a controller in Sigma release 4.04? Product Line Satchwell BAS & Sigma Environment Sigma Release 4.04 Cause Sigma 4.04 does not provide a direct method to download an empty logging configuration file to a controller. This limitation requires a manual workaround to effectively remove logging configurations. Resolution There are two recommended methods to delete logging configurations from a controller: Method 1: Manual File Deletion via Explorer Open Sigma and navigate to the Logging Configuration section. Delete the unwanted logging data set from the configuration. Using Windows Explorer, go to the controller’s folder location. Locate and delete the logging configuration file. Example filename: T0025400.100 T00254 = Server 00.100 = Controller In Sigma System Diagnostics, re-download the logging configuration to the controller to apply the changes. Method 2: Minimal Logging Configuration In Sigma, go to Logging Configuration. Open the required log data set. Delete all objects in the data set except one. Set the remaining object to log very infrequently. Save and download the configuration as usual. Optionally, delete the log data set entirely. This will result in the controller logging only one object at a minimal rate. Upon the next download of controller files, logging will be effectively removed.

Issue In Sigma System Manager, the object associated with the first entry in the Gateway.txt file of an S-IC3-SNP integration controller consistently displays its default value, rather than the expected mapped value. Product Line Satchwell BAS & Sigma Environment Sigma IC3-SNP Cause This issue arises due to the way the S-IC3-SNP controller processes the object mapping file ( Gateway.txt ). Specifically, the first line in the file is not correctly interpreted, causing the first object to revert to its default value. Note: This behavior does not affect earlier versions such as S-IC-SNP. Resolution Steps to Resolve: Edit the Gateway.txt file. Insert a dummy line at the beginning of the file. This placeholder prevents misinterpretation of the first actual object. Example Original Gateway.txt : 51,13,R,114,2,0,0,3,1 ;Room temperature 52,13,R,114,28,0,0,3,1 ;PIR Status 53,13,R,160,6,0,0,3,1 ;Heating Valve Open Revised Gateway.txt with Dummy Line: 51,13,R,114,2,0,0,3,1 ;Dummy text entry 51,13,R,114,2,0,0,3,1 ;Room temperature 52,13,R,114,28,0,0,3,1 ;PIR Status 53,13,R,160,6,0,0,3,1 ;Heating Valve Open Save and reload the configuration in Sigma System Manager. ✅ The first object should now display its correct mapped value.

Issue Can Sigma operate in a network environment using Layer 3 switches? Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Layer 3 switches Cause The site is transitioning from Layer 2 switches to Layer 3 switches, prompting a need to understand Sigma’s compatibility with Layer 3 networking. Resolution Yes, Sigma products support IPv4 Layer 3 networking. Routing Protocol: Sigma uses RIP version 1 (Routing Information Protocol) for message routing. IP Communication: Sigma devices communicate using 32-bit IPv4 addresses with various subnet masks. Ensure that the Layer 3 switches are configured to support RIP v1 to maintain proper routing between Sigma devices. Additional Notes RIP v1 is a classful routing protocol, which may limit subnet flexibility. Consider network design implications when planning your Layer 3 migration. If your infrastructure requires more advanced routing protocols (e.g., RIP v2, OSPF), Sigma may not be compatible without additional configuration or hardware.

Issue Recipients are receiving inactivated alarm messages from the Sigma Remote Alarm Manager (RAM). These messages typically resemble the example shown below. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Remote Alarm Manager Cause These messages are not nuisance alarms. They occur because the original Sigma alarms have not been acknowledged in the Sigma Alarm Manager. By default, if an alarm remains unacknowledged for 3 days, it is removed from the RAM active alarm list and an inactivation message is sent to recipients. Resolution While you cannot prevent the inactivation message from being sent, you can extend the time before the alarm is removed from the active list. To adjust this setting: Open the Sigma R4 interface configuration. Locate the “Days before inactivation” setting. Modify the value to the desired number of days. Additional Notes These messages serve as a reminder that alarms require acknowledgment. Adjusting the inactivation period can help reduce message frequency but does not eliminate the need for proper alarm management.

Issue A customer needs a small number of I/O points at the location of the Integration Controller and wants to know if Sigma Integration Controllers support onboard I/O. Product Line Satchwell BAS & Sigma Environment Sigma Integration Controllers Cause The customer is evaluating the feasibility of using an Integration Controller (IC) to handle limited I/O requirements locally, without deploying additional hardware. Resolution The IC3 Integration Controller does not have any onboard I/O capabilities. Therefore, it cannot be used in applications where direct I/O is required at the controller location.

Issue Alarms generated by Sigma controllers are sometimes delayed in appearing at the Sigma server. This behavior is inconsistent—manual alarm tests display correctly, but real-time alarms may not appear until other activities are performed. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause There are two recommended solutions depending on your network setup: Option 1: Disable Windows Firewall If the Sigma server is not connected to the Internet, you can safely disable the Windows Firewall to allow uninterrupted alarm communication. ⚠️ Note: The method to disable the firewall varies by operating system. Use the system's Help feature for guidance. Option 2: Add a Firewall Exception If disabling the firewall is not viable, configure a firewall exception for Sigma: Open Windows Firewall. Navigate to the Exceptions tab. Select Add Port. Enter the following details: Name: Sigma UDP Port Port Number: 49152 Protocol: UDP ✅ This allows Sigma alarm messages to pass through even when the firewall is active. Additional Notes Port 49152 is specific to Sigma and must be configured as a UDP port.

Issue How to configure the new surface mount Analogue Output boards to provide a 0–20 mA control signal instead of the default 0–10 V output. Product Line Satchwell BAS & Sigma Environment Sigma UNCX96 Outstations New style surface mount Analogue Output boards Cause Some connected field devices require a 0–20 mA signal for proper operation. The new AO boards support both 0–10 V and 0–20 mA outputs but require manual configuration to switch between these modes. Resolution To configure the AO board for 0–20 mA output: Identify Channels: Only Channels 15 and 16 on the new surface mount AO board support 0–20 mA output. Locate Link LK1: On the AO board, find the LK1 jumper associated with each channel. Set Output Mode: To enable 0–20 mA output, move the LK1 jumper to the 0–20 mA position. To revert to 0–10 V output, place the jumper back to the 0–10 V position. ⚠️ Important: Ensure power is turned off before adjusting the jumper settings to avoid damage or incorrect configuration.

Issue The Analogue Input (AI) Objects were functioning correctly but suddenly failed. Instead of displaying the expected default value of 20.0, they now show their last recorded value. Upon testing, the inputs return different values, and temperature detectors consistently read 150°C, while heat flow rates show 0 m³/hr. Product Line Satchwell BAS & Sigma Environment Sigma UNCX96 Analogue Input (AI) card Cause The issue stems from incorrect controller slot allocation. The slot is mistakenly configured as empty, which prevents the AI card from functioning properly. Resolution To resolve the issue: Access the controller configuration. Verify the slot allocation. Ensure the slot is correctly assigned as an Analogue Input (AI). Download the updated configuration to the controller.

Issue Users may encounter a situation where object information is not visible in the SSM display window within the Sigma interface. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause This issue typically occurs when: The SSM display area is full, and additional data is requested. The display area does not support scrolling, so newly requested data is not shown. The font type or size used in the display window may contribute to the visibility problem. Resolution   To resolve the issue, try the following steps: Maximize or Resize the Display Window Enlarging the window may allow more data to be shown within the visible area. Change the Font Type or Size Adjusting the font settings can help fit more information into the display area: Navigate to the Display Settings. Select a smaller font size or a different font type that optimizes space usage.  

Issue You need to restrict access to specific graphics in Sigma WebClient so that only designated users can view them. Product Line Satchwell BAS & Sigma Environment Sigma WebClient Cause Sigma WebClient allows users to access graphics based on their account configuration. Without proper setup, users may inadvertently access graphics not intended for them, including the main site or other user-specific areas. Resolution To restrict a graphic to a specific user in Sigma WebClient, follow these steps: Create a User Account In Sigma, create a new user account. Assign a startup graphic to this user. This graphic should represent the specific area (e.g., building or plant) the user is authorized to view. Design the Graphic Create the graphic with a unique startup number (e.g., a building index page). Ensure no “Chain” command or reference links point back to the main site or other shared graphics. Prevent Navigation to Unauthorized Areas If the graphic links to other pages, ensure those pages also do not contain “Chain” commands back to the main site. If other users need access to the main site, consider duplicating the graphic set for the restricted user and removing the “Chain” command from this version only. User Experience When the user logs into WebClient, they will be directed to their assigned startup graphic. Navigation will be limited to the graphics explicitly linked within their assigned set.

Issue What happens to an alarm message when local time shifts due to daylight saving changes (e.g., clocks moving back or forward)? Product Line Satchwell BAS & Sigma, Satchwell MicroNet, TAC Vista Environment Remote Alarm Manager Cause This issue relates to how RAM handles time changes on the host PC. If an alarm is triggered before the time change and cleared after the system clock has shifted (e.g., moved back one hour), it may result in inconsistencies in how the alarm timestamps are displayed. Scenario Example An alarm is triggered at 15:46 local time. The system clock is manually adjusted back by one hour (e.g., due to daylight saving ending). The alarm is cleared at 14:52 (which is technically before the original alarm time). RAM logs show the alarm raised at 15:46 and cleared at 14:52. However, in the alarm properties, the cleared time may incorrectly display as 15:52, due to how the system reconciles time changes. Resolution Testing confirms that RAM handles this scenario without functional issues. Although timestamp discrepancies may appear temporarily in the alarm properties, the system normalizes once the time progresses past the original alarm time. This ensures accurate historical logging and alarm status.

Issue The Sigma IC-Lon Plugin crashes when multiple function blocks use identical SNVT (Standard Network Variable Type) names. Product Line Satchwell BAS & Sigma Environment Sigma IC-Lon Plugin Cause In LonMaker, if a controller contains multiple function blocks and each block uses the same SNVT name, the IC-Lon Plugin fails to handle this duplication and crashes. Resolution To prevent the plugin from crashing, SNVT names must be manually modified to be unique across all function blocks before using the IC-Lon Plugin. Steps to Resolve: Open the controller configuration in LonMaker. Identify function blocks with duplicate SNVT names. Rename each SNVT to ensure uniqueness across all blocks. Save the configuration and re-import into the Sigma IC-Lon Plugin. Example: Original SNVT Name: SNVT_temp Modified SNVT Name: SNVT_temp_01 , SNVT_temp_02 , etc. This ensures the plugin can correctly parse and manage the SNVTs without conflict.

Issue What is the behavior of Sigma controllers using global communications when the network fails? Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause A site is preparing for a planned network shutdown or has experienced an unexpected network failure. Understanding how Sigma controllers respond is critical for maintaining operational continuity, especially for systems controlling critical plant equipment. Resolution When the network fails: Sigma controllers continue to operate using the last known value of the global variable. No updates or changes to global values will be received or processed during the outage. Controllers will not respond to changes in global variables until communication is restored. Best Practice Recommendations Design with resilience in mind: If a controller manages critical systems, ensure fallback logic or local overrides are programmed. Document expected behavior during outages for operational teams. Test failover scenarios to validate controller responses and ensure safety.

Issue When configuring BACnet alarms in EcoStruxure Building Operation (EBO), users may encounter a potentially misleading message in the Monitored Variable description: Monitored variable: Choose the method for referencing the property that you want to monitor. Select System reference to define a path-based reference to an object or property that is currently located on the EcoStruxure BMS server. While technically correct, this statement may cause confusion. It suggests that any object or property on the EBO server can be used as a monitored variable for BACnet alarms. However, only specific BACnet objects and properties are supported for each alarm type. Product Line EcoStruxure Building Operation Environment EcoStruxture Building Workstation Bacnet Alarms Cause The ambiguity arises from the assumption that all BACnet objects and properties are valid for alarm monitoring. In reality, only a subset is supported depending on the alarm type. Misconfiguration can lead to unexpected behavior or non-functional alarms. Resolution To ensure proper configuration, refer to the table below for supported combinations of BACnet objects and properties for each alarm type: Alarm Type Monitored Variable Object Monitored Variable Property Change of State BACnet Digital Input Value BACnet Digital Output Value BACnet Digital Value Value BACnet Multistate Input Value BACnet Multistate Output Value BACnet Multistate Value Value Change of Value BACnet Analog Input Value BACnet Analog Output Value BACnet Analog Value Value Floating Limit BACnet Analog Input Value BACnet Analog Output Value BACnet Analog Value Value Floating Limit Setpoint Reference BACnet Analog Input Value BACnet Analog Output Value BACnet Analog Value Value BACnet Loop Setpoint Out of Range BACnet Analog Input Value BACnet Analog Output Value BACnet Analog Value Value BACnet Digital Input Value BACnet Digital Output Value BACnet Digital Value Value BACnet Multistate Input Value BACnet Multistate Output Value BACnet Multistate Value Value Buffer Ready BACnet Trend Log (Any) — Additional Reference For more details, see: 🔗 BACnet Alarm Types and Monitored Variables Table

Issue What is the maximum density of people that the Insight sensor (SXWREISBLE10001) can detect? Product Line Field Devices, EcoStruxure Building Operation Environment Insight sensor. Cause There is no official specification available that defines the exact density of people the Insight sensor can detect. This limitation makes it difficult to provide a precise number for maximum detection density. Resolution The maximum raw count for the people counter is 32 individuals within the detection area. Accuracy of detection is up to 90%, but it decreases as the number of people increases within the detection zone. The detection area is influenced by the mounting height of the sensor. A higher mounting position typically results in a larger detection area but may reduce accuracy in crowded conditions. Additional Notes For optimal performance, ensure the sensor is mounted according to published guidelines. Consider environmental factors such as lighting, movement patterns, and obstructions that may affect detection accuracy. If higher accuracy or density detection is required, consider deploying multiple sensors.

Issue After commissioning HID Signo OSDP readers in Security Expert, they do not log card events. Readers cannot be brought online in Security Expert. Product Line EcoStruxure Security Expert Environment Security Expert HID Signo Smart Card readers HID Reader Manager App Warning Hazard of Electric Shock: Remove all power from all devices before removing any covers or doors of the system. Disconnect power at the device and at the power source. 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 Both sides of the commissioning process require proper installation steps: HID Signo reader configuration using the HID Reader Manager App Security Expert configuration Resolution Confirm Cards Work with Reader Before starting OSDP commissioning: Set the HID Signo reader to Wiegand mode. Connect it to the Security Expert SP-C Reader Expander port. Configure the Reader Expander and Door records for the correct format and credential. Badge a card at the reader and check events in Security Expert to confirm the reader is reading the correct format. Once confirmed, proceed to Commissioning HID Signo OSDP readers.   Commissioning HID Signo OSDP readers involves two main steps: Reader configuration in the HID Reader Manager App Security Expert configuration Step 1: Configure Reader in HID App for OSDP Install Mode Open the HID Reader Manager App. Navigate to: Inspection Report → Detailed Configuration → Communication Protocol Inspect Reader Enable Install Mode:  Scroll down and select Add to Template. Select Apply Selected Items. Enable OSDP Wait for the reader update to complete, then exit the menus. Writing changes Step 2: Configure Reader Expander in Security Expert In Security Expert, go to: Reader Expander → General tab Set Port Network Type to OSDP.  Saving changes creates two new Smart Reader records. Configure the Smart Reader:  Set the Address correctly (1 + the address value set in the HID Reader App). Under the Reader tab, set:  Reader One Format to the correct format. Reader One Door to the correct Door record. Activate OSDP Install Mode:  Right-click the Reader Expander record → Activate OSDP Install Mode. Expected Events Install Mode Activation by <operator> on Module <module> Module <module> Registered With Serial No (####) These indicate the command was processed and the expander attempted to register. Important: These events appear whether the OSDP handshake succeeds or fails. The only way to confirm success is to badge a card and check for events. OSDP Install Mode may need multiple attempts for successful handshaking. When successful, the HID Reader Manager App will automatically disable Install Mode, which can be confirmed in the App. Key Notes Always verify card functionality before starting OSDP commissioning. Multiple attempts may be required for OSDP handshake. Successful commissioning is confirmed by card events in Security Expert.  

Issue When viewing an optimiser point, the value for “Minutes to Next Switch” appears unusually large. Product Line Satchwell BAS & Sigma Environment Satchwell BAS Satchwell Sigma Cause The optimiser is unable to accurately calculate the time to the next switch due to one or more of the following reasons: The associated time schedule is in a “Manual” condition. The optimiser point is correctly cross-referenced to a time schedule, but that schedule is further cross-referenced to another point (e.g., a programmable point) via: Low Action (LA) High Action (HA) Holiday point that is not correctly configured as a holiday schedule. This misconfiguration prevents the optimiser from determining the next switch time, resulting in a default large value. Resolution To resolve this issue, review and adjust the hierarchy of overrides and actions in the software. The goal is to ensure the optimiser can directly interpret the time schedule without unnecessary layers of overrides. Recommended Configuration Examples Example 1 Instead of: Holiday > Overrides (e.g., Programmable Points) > Time Schedule > Optimiser > Plant Level Use: Holiday > Time Schedule > Optimiser > Overrides (e.g., Programmable Points) > Plant Level Example 2 Instead of: Overrides (e.g., Programmable Points) > HA or LA xref > Time Schedule > Optimiser > Plant Level Use: Time Schedule > Optimiser > Overrides (e.g., Programmable Points) > Plant Level Additional Notes Ensure that holiday schedules are correctly defined as holiday points. Avoid placing overrides or programmable actions above the optimiser in the control hierarchy.

Issue A Longtext number appears when a DI Object is displayed in System Manager, even though no alarm is configured on the object. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause This issue occurs when a DI object previously had an alarm configured with a Longtext number. Even after the alarm is removed, the Longtext number may still be retained and displayed. Note: This behavior does not occur with AI (Analog Input) objects. Resolution To remove the Longtext number from the DI object display: Re-enable the alarm on the DI object. In the Alarm tab, set the Longtext number to "0" . Disable the alarm again. Download the object to the controller to apply the changes.

Issue You need to create a programmable object in Sigma that: Monitors an existing object (Object 1). Uses a time schedule (Object 2) to determine when to hold and output the value from Object 1. Maintains the output until the next time schedule "off" period, at which point the value is reviewed again. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause Assistance is required to implement a programmable object that dynamically responds to both an object’s state and a time schedule. Resolution The following logic fulfills the requirement. Ensure you use the correct controller and object numbers for your specific setup. Object Definitions Object 1: The existing object whose value is to be monitored. Object 2: The time schedule controlling when the value is held and reviewed. Programming Logic 10 IF P (2) ON THEN XINT = 1 ELSE XINT = 0 20 IF XINT DOWN THEN GOTO 40 30 GOTO 50 40 IF P (1) ON THEN YINT = 1 ELSE YINT = 0 50 IF YINT = 1 THEN RETURN TRUE "HW" 60 RETURN FALSE "CW" Explanation Line 10: Checks if the time schedule (Object 2) is ON. Line 20: If the time schedule transitions from ON to OFF, proceed to line 40. Line 40: Evaluates the state of Object 1 and sets YINT accordingly. Line 50–60: Returns TRUE or FALSE based on YINT, outputting either "HW" or "CW". Additional Notes This logic ensures the value from Object 1 is captured and held when the time schedule turns OFF. The value is only updated during subsequent OFF transitions of the time schedule.

Issue When a specific user logs off the Sigma system, another user is automatically logged on without manual intervention. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause This behavior is typically caused by corruption in the GenCNF.rec file and user configuration files. These corrupted files can result in unexpected user session behavior, including automatic logins. Resolution You have two options to resolve this issue: Option 1: Restore from Backup Locate a backup of the system files taken prior to the corruption. Shutdown the Sigma server and all connected clients. Copy the following from the backup: GenCNF.rec file Entire User folder Paste the copied files into the Sigma Data folder. Restart the Sigma server and all clients. Test user access to confirm resolution. Option 2: Rename and Replace the Corrupted User Note: System users cannot be deleted, only renamed. In Sigma SSM > Users, highlight the affected username. Select Rename and assign a new, appropriate name. Create a new user to replace the old one. Assign the correct access levels to the new user. Test user access to ensure proper login/logout behavior.