Spillover Spa and Motorized Cover Lockout

[madasus]

Hello,

First off - thank you for this interface!

I have a couple of items that aren't showing up for my pool.

1. I have a spillover spa which is controlled through OmniLogic. I don't see that option in this interface.
2. I have an auto cover which has a lock out relay which prevents the spa spillover when the cover is closed. Would there be a way to read this relay from OmniLogic?

Let me know what information I can provide to help get these into the system.

Regards

M

[cryptk]

Adding spillover support isn't in yet, but it's on the list for sure. As far as the cover interlock, there isn't a way to read that sensor directly in the examples that I've seen previously, but I did have someone else use the whyOn attribute on a valve actuator that was tied to their cover interlock to be able to determine that the cover interlock was active. It looks like if their whyOn attribute of the interlocked valve actuator is 10, that means it is off because of an interlock.

[madasus]

Thanks - i'm happy to test or provide whatever information you might need for the spillover stuff.

Can you elaborate a bit on the "whyOn" example - where do I find that?

[Paulbhyo]

Each valve has a why_on state which changes with schedules and other things, but with an interlock that shuts off a valve, the why_on state in my case was 10. Check out the states of your valves or relays that get imported and verify its the same. This state is used to create a binary sensor in the configuration yaml. this was the cleanest way we found to "monitor" the EXT Input.

I have another messy way, that requires you to add an interlock to an unused relay... but its not required if your already interlocked with other equipment.

[madasus]

mine looks a bit different. For me the interlock is only tied in to the spillover pump option. Maybe thats why i don't see it yet?

[cryptk]

@madasus can you upload the diagnostic data from the integration? Then we can see if there is a bit of data we can expose

[Paulbhyo]

I wonder if that "unavailable" State is actually something else missing from the state list?

[cryptk]

The restored true indicates that the integration isn't providing that entity anymore... I won't be able to tell much else without the diagnostic data though

[madasus]

config_entry-omnilogic_local-xxx.json.txt

here it is

[cryptk]

the "unknown" is because your filter has a whyOn status of 18, which is undocumented, and it's failing to parse it into a textual representation... seems the docs I was provided are incomplete

[cryptk]

I'm not sure what these extra whyOn states for the filter mean, but for now I'm going to add them as "UNKNOWN", which will get the integration up and running, I can update the names of them in the future if we ever determine what they actually mean.

[madasus]

is that code anything i might be able to resolve through their web interface or other source?

[cryptk]

it's possible... I just pushed release 0.5.2 which adds some values to the filter whyOn enum, you should see it as "Unknown 18" now, and the switch should be available to use. If you can test some things and see what causes it to go to a whyOn of "Unknown 18", that would be awesome. Try opening and closing your cover, or maybe changing the spillover mode between pool/spa/spillover and see what combination of things makes it go to 18.

[cryptk]

I split the request for controlling spillover to #67

[madasus]

I just turned the spa on and off again and now that 18 is gone.

[Paulbhyo]

most likely the interlock is released when the spa filter pump is able to run. ?? Do you have to open your auto cover to run the spa?

I bet it is ON or OFF when the cover is open, and it goes to 18 when the cover is closed and you can't run the spa.

[madasus]

no - i can run the spa with the cover closed i'm just not able to run the spillover option on the pool pump with the cover closed.

[Paulbhyo]

I think the "why_on" can be from anything that is controlling the device, manually with the toggle, schedule, interlock etc. you just have to play with it and see if you find some correlation to the state and what is controlling it. So do you have a Valve that controls the spill over then? I would think the Why_on state of that could be indicating the Cover position.

[madasus]

i agree - i do have a valve for that but not yet visible in this integration. Once thats added I can probably debug further.

I think you might be right on the 18 - I think that might be when the schedule turns off the valve. I'll look in the morning when it goes through the next shutdown

[cryptk]

there is a Timer On option (it's 14), I wonder if 18 is Timer Off.

For what it's worth, you should be able to control things in the OmniLogic app to replicate scenarios and then observe the whyOn attribute in the integration next time the integration updates (default is every 10s)

[cryptk]

Do you by chance have a schedule set for your spillover? I wonder if 18 could mean that it tried to activate it for scheduled spillover, but it couldn't, because the pool cover interlock was active?

[madasus]

I have a schedule for the spa (no spillover) and then a schedule for the pool (full) and then a later schedule for the pool (half). I think your TImer Off guess is a good one - i'll check tomorrow morning to see if it retuns after the timer expires.

[madasus]

Confirmed. "Unknown 18" is when the spa pump is shut off as a result of the automated schedule

[cryptk]

I'll update it to say something like Timer Off for 18 then

[madasus]

tks - i'll keep an eye out for when the spillover spa valve shows up and we can try and figure out the interlock at that point. I thought the interlock was presented as a unique relay in the data pull but maybe not?

[Paulbhyo]

The interlock input is not in any data sent from the controller to the cloud. If you go onto haywards cloud website, you won't find it. Therefore it's not a sensor that can be pulled from the data that is sent. We can only see it on how it impacts other devices.

If you have a spare relay, you can set the interlock to force it on and off. The relay would come in as a switch. I have tried that and the integration does pull the new switch In to the system..

[madasus]

I thought this in the definition from the OmniLogic Portal was pointing to an available sensor in the API

<Sensor> <System-Id>38</System-Id> <Name>auto cover</Name> <Type>SENSOR_EXT_INPUT</Type> <Units>UNITS_FAHRENHEIT</Units> <Operation> PEO_GET_VALUE <Action> <Action-Function>ACT_FNC_GET_EXT_INPUT</Action-Function> <Action-Data1>21</Action-Data1> <Action-Data2>6</Action-Data2> <Action-Data3>0</Action-Data3> </Action> </Operation> </Sensor>

and also this section

<External-Interlock> 1 <External-Interlock-Enable>yes</External-Interlock-Enable> <External-Interlock-Source>ILK_SOURCE_SENSOR</External-Interlock-Source> <External-Interlock-Source-System-Id>38</External-Interlock-Source-System-Id> <External-Interlock-Compare-Type>ILK_COMPARE_LESS_THAN</External-Interlock-Compare-Type> <External-Interlock-ActiveLevel>512</External-Interlock-ActiveLevel> <External-Interlock-ActionState>4</External-Interlock-ActionState> </External-Interlock>

[Paulbhyo]

That is in the configuration from the MSP. But it's not in the regular data exchange (telemetry) that is received from a query.

[cryptk]

Going to go ahead and close this one, initial spillover support is released and unfortunately the omniologics don't return any telemetry for the current state of interlocks so I can't add that functionality to the integration