Fix/century pump light

[celestinjr]

This pull request updates the logic for determining and displaying the on/off status of pumps in scripts/pumps.js. The main improvement is a more accurate status indication for different pump types, especially for Modbus-controlled pumps.

Pump status logic improvements:

• Enhanced the on/off status logic to distinguish between Modbus pumps (using rpm or speed values to determine if the pump is running) and relay-based pumps (using command or relay status). This ensures the UI accurately reflects the actual state of various pump types.
• Added a debug log for Modbus pump 1 to aid in troubleshooting and validation of the new logic.

[tagyoureit]

Can you remove the console.debug statements and what is the regalmodbus2 identifier for?

---

What it does

For regalmodbus / regalmodbus2, the indicator no longer uses command === 10 or relay > 0. It uses real motion: rpm > 0 or speed > 0. That matches how the backend documents Regal Modbus for dashPanel (RegalModbusStateMessage.ts ties “running” UI to command === 10 while also updating rpm from status/demand).

Does it fix the problem?

Yes, for the usual failure mode: command/relay “on” while the drive is not actually moving (or the inverse). Using rpm/speed is the right signal for a VFD-style pump.

Risks / edge cases

• Boot / priming — While the motor is ramping, you can have command === 10 but rpm/speed still 0. The new logic can show off briefly; that may be desired (only light when spinning) or feel like a flicker depending on update rate.
• Flow-only mental model — If any install surfaces “running” mainly via flow (GPM) and not rpm/speed in the API payload, the indicator could stay off. Worth confirming against real socket/API fields for Century.
• regalmodbus2 — Your main server repo’s NixieBoard pump map only names regalmodbus (type 200) and neptunemodbus (201); there is no regalmodbus2 string here. If that name only exists in dashPanel or another fork, the branch is harmless; if it’s a real type elsewhere, ensure it’s the same semantics.
  Style

Fits existing legacy pumps.js style (var, inline logic).

The console.debug for pump id === 1 is useful for bring-up but is noisy and arbitrary for production; I’d remove it or gate it (e.g. URL flag / localStorage) before merge.

[celestinjr]

Thanks for the catch. I don't recall what I was troubleshooting, but it's been removed.