Duplicate entities (_2) created on hard boot (S19j Pro boot timing issue & incomplete API data)

[Lootsi]

Version of the custom_component

v1.3.6

Configuration

# The integration itself is configured via the UI.
# However, the issue is triggered by an automation that hard-boots the miner via a smart plug (e.g., based on solar excess):

action:
  - service: switch.turn_on
    target:
      entity_id: switch.p110_mining

Description:
When the Antminer S19j Pro is hard-booted via a smart plug, the integration frequently fails to reconnect to the existing entities. Instead, it creates a completely new set of duplicate entities appended with _2 (e.g., switch.s19j_pro_active_2). The original entities remain unavailable. This breaks all existing automations and dashboards.

Steps to reproduce:

Turn off the Antminer completely (cut power via smart plug).

Turn the smart plug back on.

Wait for the Home Assistant integration to poll the device during its initial boot sequence.

Check the device registry – a second device with duplicate entities is created.

Root Cause Analysis:
This seems to be a strict timing issue during the ASIC's boot sequence combined with how the integration handles unique IDs / MAC matching:

When power is restored, the network chip of the S19j Pro boots up very fast. It is reachable on the network and broadcasts its MAC address.

However, the actual mining software / control board API takes another 1-3 minutes to fully initialize.

If hass-miner polls the device exactly in this narrow time window, the ASIC answers with incomplete data. It provides the MAC address, but the hardware model string (e.g., "S19j Pro") or manufacturer string ("AntMiner") is missing.

Result: Home Assistant sees a device with the same MAC, but since the model strings are missing (UI Device page only shows "Miner" instead of "S19j Pro by AntMiner"), the integration treats it as a completely new device and forces the creation of a duplicate profile. Once the Miner is fully booted a few minutes later, the damage is already done.

Proposed Solution:
Could we implement a short delay or a "retry logic" during the initial connection phase? If the integration reads the MAC but gets incomplete API data (like missing model strings), it should hold off on creating a new device entry and retry 60-120 seconds later, rather than immediately registering a new "empty" device.


# Standard log output shows the immediate creation of the duplicate during the boot window:
2026-04-06 11:01:35 WARNING (MainThread) [homeassistant.components.switch] Entity switch.s19j_pro_active_2 created due to new device registration.

# Note: Full debug logs for the pyasic API payload during the exact boot window are tricky to capture since it requires hitting the exact 10-second window. The core issue is the missing manufacturer/model strings in the API response during the first polling attempt.