Sending commands causes SWG cell type to change

[firstone]

My system is normally configured for CELL-T9. Once I've installed this integration and sent some commands, cell type changed to CELL-T15 (resulting in salt level being read about half). I thought my cell had gone bad and tried replacing it. But same thing kept happening. I'd set it up, it would run until next morning when it would just change back from 9 to 15. I've disabled my schedules in HA and turned Hayward back on and it worked fine a few days. Decided to try again, send my normal schedule and right away type went to 15. This is really frustrating since 1. It affects actual chlorine generation. 2. It requires a trip to the unit to run config wizard to fix.

This is what I've sent:

alias: Pool On
description: ""
trigger:
  - platform: state
    entity_id:
      - schedule.pool
    to: "on"
    from: "off"
condition: []
action:
  - type: turn_on
    device_id: e077706027761dc67414d38299c34720
    entity_id: 576d4b91b6b51237b5b5a985e12a8f56
    domain: switch
  - type: turn_on
    device_id: e077706027761dc67414d38299c34720
    entity_id: 9baf058415690a7557180754bbe6bd25
    domain: switch
  - device_id: e077706027761dc67414d38299c34720
    domain: number
    entity_id: f81af93f3e207883c6be463c835cda96
    type: set_value
    value: 60
mode: single

config_entry-omnilogic_local-dc856474eb5cda5df85993e521593e46.json

[firstone]

This is definitely caused by changing chlorination percentage. As soon as change it to any value, my cell type changes.

[firstone]

It defaults here to 4, which is prob type 15. This probably needs to be passed from upstream to have correct type:

https://github.com/cryptk/python-omnilogic-local/blob/main/pyomnilogic_local/api.py#L442

[firstone]

Verified that setting cell_type = 3 in integration call sets correct cell type. I find this API design pretty bizarre - it accept config level value that, otherwise, requires physical device access to be set. Possibly you can skip the field from the call altogether.

[cryptk]

Their API is definitely a bit odd... it's also not publicly documented at all... It does look like I'll need to pull that value from the MSP config data and make sure to pass the appropriate value with the API call.

I don't have a salt system to be able to test with, but if you download the diagnostic data from the addon and attach it here, that can help a lot

EDIT: I see that you already attached the diagnostics to the initial comment. I'll try and find some time to take a look