Improve Hayward HWVS pump reliability with comm failure tracking and …

[camaro4life18]

…exponential backoff

• Implement requestPumpStatusAsync() to actively poll Hayward pump status instead of no-op
• Add consecutive communication failure tracking with exponential backoff in polling (2s to max 30s after 5 failures)
• Add pollEquipmentAsync() override to include status polling after each state update
• Add updateCommStatus() to set pump status to warning/error based on failure count
• Preserve last known pump state on comm failure instead of zeroing rpm/watts
• Fix silent error swallow in setPumpToRemoteControlAsync (was missing logger.error)
• Increase retries from 1 to 3 and add 2500ms timeout on outbound messages
• Update package-lock.json license identifier to AGPL-3.0-only

[tagyoureit]

Thanks for this. There are a couple of changes in here that I'd accept, including:

• chemistry mixing changes
• catch/try in the string expression error

However, there's a few that give me pause.

• Needing to implement a rewind safety valve is a solution to a problem that shouldn't exist. If you have that many comms failures you should look to your wiring, equipment, etc. I've never seen this many consecutive backoff/retries and this isn't something that should be fixed by software
• Some of the pump logic mixes togethr comms failures and status updates
• The heap protection is another symptom of poor comms on the bus, not in the software
• I'm not a fan of preserving the last known state during a comms failure. It might be true that the last state is still valid, or it might not be. But I'd rather err on the side of not showing invalid data and zeroing out the rpm/watts.