feat: add chlorinator diagnostics

[kmbulebu]

Adds requests for salt cell chlorinator measurements and relay polarity.

Parse cell voltage, current, cell and board temperatures, and instant and average salt levels while preserving the raw controller values.

Tested against my pool setup.

measurement = await api.async_get_chlorinator_measurement(
      pool_id=7,
      chlorinator_id=8,
  )

  print(f"Cell voltage: {measurement.voltage:.2f} V")
  print(f"Cell current: {measurement.current:.2f} A")
  print(f"Cell temperature: {measurement.cell_temperature_f:.1f} °F")
  print(f"Board temperature: {measurement.board_temperature_f:.1f} °F")
  print(f"Instant salt: {measurement.instant_salt_level} ppm")
  print(f"Average salt: {measurement.average_salt_level} ppm")

  polarity = await api.async_get_chlorinator_relay_polarity(
      pool_id=7,
      chlorinator_id=8,
  )

  print(f"Relay polarity: {polarity.relay_setting}")

Sample with chlorinator on:

  Cell voltage: 31.64 V
  Cell current: 0.36 A
  Cell temperature: 85.4 °F
  Board temperature: 119.5 °F
  Instant salt: 2869 ppm
  Average salt: 2936 ppm
  Relay polarity: 1

Sample with chlorinator off:

  Cell voltage: 0.00 V
  Cell current: 0.00 A
  Cell temperature: 0.0 °F
  Board temperature: 0.0 °F
  Instant salt: 0 ppm
  Average salt: 2900 ppm

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[cryptk]

I don't understand what the point of all of this work to set and verify response names is? Are you concerned that it might send a request and somehow get a response intended for a different request? That doesn't happen. The way the protocol works, every request sent to the Omni via the async_send_and_receive method creates it's own datagram endpoint (so it's own local port), so responses sent from the omni will be sent to a port specific to that request.

There are other (likely more efficient) ways to do this that I plan to look into in the future (involving using a single local port for sending and receiving responses, and matching responses with the transmitted message based on message IDs, etc), but for now, the fact that ever message sent uses a different local port disambiguates the responses.

Was there some other reason for this response_name matching that I'm just not seeing?

[cryptk]

How were these values determined?

[cryptk]

Internally, the Omni refers to message type 386 as UI_GET_FILTER_DIAGNOSTIC, which is why I have it named GET_FILTER_DIAGNOSTIC here. Where possible, I attempt to align the names of things in the library to match the names used internally by the OmniLogic system. It helps me to keep things straight when I am cross referencing documentation and such.