You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
False error in handling START_MINING with Home Assistant #6
During the execution of a policy, the system logs an error when trying to enable the Home Assistant miner switch, even though the operation actually succeeds.
Stacktrace
Policy 'Advanced Solar Mining Policy': Evaluating state for miner status OFF
2025-09-16 12:16:06 | INFO | Optimization unit 'Test Energy Optimization', Miner 02bb802e-1f42-4e4f-b1a5-7d48ecfcc926: Status=OFF, Policy='Advanced Solar Mining Policy', Decision=START_MINING
2025-09-16 12:16:06 | INFO | Executing START for miner 02bb802e-1f42-4e4f-b1a5-7d48ecfcc926 via GenericSocketHomeAssistantAPIMinerController
2025-09-16 12:16:08 | ERROR | Failed to set Home Assistant entity 'switch.active_antminer' to state 'true'. Current state is 'False'.
2025-09-16 12:16:08 | ERROR | Command START_MINING for miner 02bb802e-1f42-4e4f-b1a5-7d48ecfcc926 failed using controller GenericSocketHomeAssistantAPIMinerController.
2025-09-16 12:16:08 | INFO | Finished processing for optimization unit 'Test Energy Optimization'. 1 miners controlled.
2025-09-16 12:16:08 | INFO | Optimization run for all units finished. 1 units processed.
Checking through the Home Assistant interface, the entity switch.active_antminer is indeed set to true.
I wonder if this error is coming from home assistant not recognizing that the device has had its state changed. Stock FW antminers tend to take a long time to respond when the configuration endpoint is called, so when putting them into sleep mode it can take ~10 seconds to know if they accepted the command.
I’d like to add some clarification regarding the switch state issue.
Even though the service call to turn the switch on/off was executed successfully in Home Assistant, the application was not reflecting the updated state during the following cycles. Essentially, the entity states were not being refreshed at each cycle, but instead were being read from a cached state. Current states were only updated once the application was restarted.
For example:
The miner was actually OFF.
The decision logic returned START_MINING.
The switch was correctly toggled ON in Home Assistant.
However, within the application the switch state remained OFF
Proposed solution:
Disable the client session cache when initializing the Home Assistant client
Explicitly refresh the state from the API when reading entity states
defget_entity_state(self, entity_id: Optional[str]) ->Tuple[Optional[str], Optional[str]]:
# [...]state=entity.get_state().state# The actual value as a string
With this approach, the entity state is now updated on every cycle, and the ON/OFF status of the switch is correctly reflected in the application. After applying this change, I no longer encounter errors when starting or stopping the miner via the switch.
That said, I’m not entirely sure whether this solution is the “right” one long-term — disabling caching might have unintended side effects in other parts of the codebase that rely on cached states for performance reasons. It fixes the immediate issue, but I’m not certain if it could potentially break other parts of the integration where caching is useful.
Activity
b-rowan commentedon Sep 17, 2025
I wonder if this error is coming from home assistant not recognizing that the device has had its state changed. Stock FW antminers tend to take a long time to respond when the configuration endpoint is called, so when putting them into sleep mode it can take ~10 seconds to know if they accepted the command.
Pipperix commentedon Sep 25, 2025
I’d like to add some clarification regarding the switch state issue.
Even though the service call to turn the switch on/off was executed successfully in Home Assistant, the application was not reflecting the updated state during the following cycles. Essentially, the entity states were not being refreshed at each cycle, but instead were being read from a cached state. Current states were only updated once the application was restarted.
For example:
Proposed solution:
With this approach, the entity state is now updated on every cycle, and the ON/OFF status of the switch is correctly reflected in the application. After applying this change, I no longer encounter errors when starting or stopping the miner via the switch.
That said, I’m not entirely sure whether this solution is the “right” one long-term — disabling caching might have unintended side effects in other parts of the codebase that rely on cached states for performance reasons. It fixes the immediate issue, but I’m not certain if it could potentially break other parts of the integration where caching is useful.