Sigenergy DC Charger Bug: TypeError Causes Connection Storm

Introduction to the Sigenergy DC Charger Issue

We're diving deep into a critical bug affecting the Sigenergy DC charger integration, specifically when it comes to the DC charger switch entity (switch.sigen_inverter_dc_charger_dc_charging). This issue, identified as a TypeError, has a cascading effect, leading to connection storms and rendering all Sigenergy sensors unavailable. The problem originates within the switch.py file, specifically at line 116, where an attempt to compare NoneType with an int occurs. This happens because the dc_charger_output_power function, which is crucial for determining the charger's status, unexpectedly returns None instead of a numerical value. This unexpected None value breaks the logic that checks if the charger is currently on or off, triggering a chain reaction that can bring your entire Sigenergy system to a standstill. The integration's attempt to recover from this error only exacerbates the problem, leading to a loop of failed connections and overwhelming the Sigenergy inverter. This makes troubleshooting and resolving the issue paramount for users relying on seamless integration with their smart home systems.

Understanding the TypeError in Sigenergy DC Charger Switch

Let's break down the core of the problem: the TypeError in the Sigenergy DC charger switch. At its heart, this is a classic programming error where you're trying to perform an operation on a variable that isn't the expected data type. In this case, the code is expecting a number (an integer, specifically) to compare against zero to determine if the DC charger is active. However, due to an issue in how the dc_charger_output_power is being reported, it's sometimes returning None. Imagine you're trying to ask, "Is this apple greater than zero?" but instead of getting a count of apples, you get "nothing" or None. You can't logically compare "nothing" to a number like zero. This is precisely what's happening within the integration's logic. The switch.py file, at line 116, contains a lambda function designed to check the charger's status: lambda data, identifier: data.get("dc_chargers", {}).get(identifier, {}).get("dc_charger_output_power", 0) > 0. This line tries to fetch the dc_charger_output_power and, if it's greater than 0, considers the charger is_on. The problem is when dc_charger_output_power returns None. The .get("dc_charger_output_power", 0) part is meant to provide a default value of 0 if the key is missing, but it doesn't handle the case where the key exists but its value is None. So, the comparison None > 0 is attempted, which is mathematically undefined and thus throws a TypeError. This fundamental type mismatch is the ignition point for the subsequent system instability.

The Cascading Effects: From TypeError to System Unavailability

Once the TypeError occurs, it doesn't just sit there; it kicks off a domino effect that can cripple your Sigenergy integration. The first consequence is that the integration, upon encountering this error, tries desperately to recover. This often involves repeatedly attempting to re-establish a connection with the Sigenergy inverter. However, instead of successfully reconnecting, each attempt adds to the strain. This continuous cycle of trying and failing to connect leads to a connection storm. Essentially, your Home Assistant instance and the Sigenergy inverter get caught in a loop of establishing, dropping, and re-establishing Modbus TCP connections. We’ve observed instances where over 54 Modbus TCP connections get stuck in the SYN_SENT state. This is like leaving countless doors open and half-ajar, overwhelming the communication pathways. As these connections pile up and the system struggles to manage them, the Sigenergy inverter itself becomes overwhelmed. It's working overtime trying to process these malformed requests and broken connections, eventually becoming unresponsive. When the inverter stops responding, it means it can no longer provide the necessary data to Home Assistant. Consequently, all Sigenergy sensors become unavailable. This includes energy production, consumption, battery status, and any other sensor data you rely on. The system effectively goes dark from a data perspective. The only way to break this deadlock and restore communication is typically a full restart of the Home Assistant system. This restart clears out the stuck connections and allows the integration to attempt a fresh connection, hopefully without encountering the same TypeError.

Diagnosing the Connection Errors and Log Analysis

To truly understand the severity and scope of this bug, examining the logs is crucial. The provided logs paint a clear picture of the chaos that ensues after the initial TypeError. Following the stack trace, which clearly indicates the TypeError: '>' not supported between instances of 'NoneType' and 'int' originating from line 116 in switch.py, we see a barrage of WARNING messages related to Modbus connection errors. These warnings, timestamped just moments after the TypeError, show Connection error: Modbus Error: [Connection] Not connected originating from AsyncModbusTcpClient 192.168.50.177:502. This specific IP address and port are typical for Modbus TCP communication with an inverter. The errors persist, with ConnectionException/Timeout during read messages appearing for various Modbus addresses. These messages signify that Home Assistant is failing to communicate with the inverter over Modbus TCP. The inverter is either not responding at all, or the communication is timing out repeatedly. The logs indicate that the connection is being marked as closed by the integration, but the underlying issue is the inability to establish and maintain a stable connection. This pattern of repeated connection failures and timeouts is the hallmark of a connection storm, where the system is constantly fighting to establish communication but failing due to the underlying instability caused by the initial TypeError. The sheer volume and frequency of these warnings underscore the critical nature of the problem, as it effectively paralyzes the data flow from the Sigenergy inverter to Home Assistant, rendering all sensors useless and potentially impacting any automations that rely on this data.

The dc_charger_output_power Anomaly

The root cause of this entire debacle, as highlighted in the logs and the bug description, lies with the dc_charger_output_power value. This specific data point is critical because it's used by the Sigenergy integration to determine whether the DC charger is actively delivering power, and thus, whether the switch.sigen_inverter_dc_charger_dc_charging entity should be reported as on. The problem arises when this value, instead of returning a numerical representation of power (like 0, 100, 500, etc.), returns None. This None value signifies the absence of data or an inability to retrieve the data at that particular moment. However, the current implementation in switch.py line 116 isn't equipped to handle None gracefully. It directly attempts a comparison: data.get("dc_chargers", {}).get(identifier, {}).get("dc_charger_output_power", 0) > 0. While the .get(..., 0) provides a default of 0 if dc_charger_output_power key is entirely missing, it does not safeguard against the key existing but having a None value. When None is encountered, the comparison None > 0 is executed, which is an invalid operation in Python and results in the TypeError. This suggests that either the Sigenergy inverter is sometimes failing to report this specific parameter, or there's an issue within the integration's Modbus reading logic that results in None being passed instead of a valid number or a proper default when data is unavailable. Understanding why dc_charger_output_power returns None is key to a permanent fix, whether it involves better error handling in the integration or a firmware update for the inverter to ensure consistent data reporting.

Reproducing and Verifying the Bug

To confirm that this is indeed a reproducible bug and not an isolated incident, a systematic approach is necessary. The trigger for this TypeError appears to be related to the state of the DC charger and how its output power is reported. A key step in reproducing the bug would be to monitor the switch.sigen_inverter_dc_charger_dc_charging entity and the dc_charger_output_power attribute. When the dc_charger_output_power attribute returns None, the TypeError is likely to occur. Users experiencing this issue might notice it happens during specific charging scenarios, perhaps when the charger is first activated, when it stops charging unexpectedly, or during periods of low power output. The critical action is the is_on state check performed by Home Assistant, which is implemented via the is_on_fn in the switch.py file. This function directly relies on dc_charger_output_power. To actively reproduce it, one might try to manually toggle the DC charger switch in Home Assistant or ensure charging is active under conditions where the inverter might be under heavy load or experiencing network fluctuations, which could potentially lead to intermittent None values for dc_charger_output_power. Observing the Home Assistant logs immediately after such an action is crucial. If the TypeError traceback appears, followed by the cascade of Modbus connection warnings, then the bug has been successfully reproduced. The fact that a Home Assistant restart clears the issue temporarily also aids in verification; the problem reappears after a subsequent TypeError event, confirming its ongoing nature within the integration's logic.

Proposed Solutions and Future Fixes

Addressing this critical TypeError bug requires a two-pronged approach: immediate mitigation and a more robust long-term solution. For immediate mitigation, the primary focus should be on enhancing the error handling within the switch.py file, specifically around line 116. The is_on_fn lambda function needs to be modified to gracefully handle cases where dc_charger_output_power returns None. Instead of directly comparing None with 0, the code should check if the value is None first. If it is None, it should be treated as the charger being off (returning False for is_on) or an appropriate default should be applied consistently. A safer implementation might look like: `is_on_fn=lambda data, identifier: (power := data.get(