Solar temperature differential setting?

[CodeSlinger69]

Hey folks, I'm still here, just been away from my house and pool for 6 months. @FlaMike, glad to see you are getting your cannibalized Nixie built and your questions answered!

We are now in solar heating season in AZ, and I noticed that when my pool hits the setpoint, the solar turns off as expected. However, the precision on the temperature probe via REM is such that the temperature will fluctuate by several hundredths of a degree, which triggers the solar to reengage. For exmaple, my setpoint is 83, and REM will report a temp of 82.96.

njsPC is smart enough to detect this short cycling situation and will not restart the solar for 60 seconds, to allow time for valves to rotate to where they need to be. It does this for gas heating as well, BTW, to avoid damaging the furnace. But what happens then is that the solar will turn on every minute or so for 10 seconds, as it appears that njsPC does not have temperature differential logic. I could very well be missing something of course.

As an example of what I mean: Your thermostat for your home furnace has a setpoint, say 72 degrees, and when that setpoint is reached, it will turn the furnace off. But the thermostat also has a temperature differential (3 degrees or 1 degree are typical, some are also programmable). If your differential is say 3 degrees, then the thermostat will not call for heat until the house temperature drops to 69. This is so the furnace is not engaged when the temperature drops to 71.9.

I have attached a replay which shows this behavior. You can see when the water temperature drops 0.04 degrees, njsPC starts thinking about turning the solar back on, but does wait 60 seconds to avoid short cycling.

So the question: Does njsPC have a temperature differential setting, and if not, should it?

replay.zip

[rstrouse]

Double check to ensure you have your start and stop temp deltas set up.

[CodeSlinger69]

I think we've lost our way on this discussion a bit. Let me roll things back. In this post I defined stop/start deltas that are very much in line with the last quote from the manual. Extracting the relevant bits from Pentair's blurb:

The solar roof sensor must be 6° higher than the water temperature.
When the roof sensor and the water temperature are within 3° of each other, solar heat will switch off.

The good thing is that the original logic, before we started farting around in this thread, was in line with Pentair's wording:

if (body.temp < cfgBody.heatSetpoint &&
    state.temps.solar > body.temp + (hstate.isOn ? heater.stopTempDelta : heater.startTempDelta)) {

However, IMHO, the code as of this commit does not reflect that Pentair intent.

Now to bring this back, my original reason for this thread was to only handle the situation when the setpoint was hit. I had no complaints about how start/stop deltas were working. If clouds rolled in, the existing logic in concert with the short cycling logic worked fine.

For hitting a setpoint however, it should be similar to how home thermostats work: When the setpoint is hit, do not reengage the furnace until the temperature drops by the specified differential. For njsPC, I've leveraged the prevHeaterOffTemp class member that you've added, and built some logic to use it as a latching mechanism. In the below code, prevHeaterOffTemp is only set when the setpoint is reached, and is unset when the differential is met. That differential is hardcoded to 1 degree in the below code. It is also unset when clearPrevHeaterOffTemp() is called per your logic in NixieBoard.ts, which is fine.

Here is the code I am testing right now. I'll run it tomorrow once the sun gets hot again and see what happens. Or I might mess with manually posting REM temps tonight if I have energy. Most likely tomorrow though.

case 'solar':
    if (mode === 'solar' || mode === 'solarpref') {
        let hState: HeaterState = state.heaters.getItemById(heater.id);
        if (body.temp < cfgBody.heatSetpoint &&
            state.temps.solar > body.temp + (hstate.isOn ? heater.stopTempDelta : heater.startTempDelta) &&
            typeof hState.prevHeaterOffTemp === 'undefined'
        ) {
            isOn = true;
            body.heatStatus = sys.board.valueMaps.heatStatus.getValue('solar');
            isHeating = true;
        }

        /// snipped out the solar cooling code as I'm not worried about that until the heating code is locked in ///

        if (typeof hState.prevHeaterOffTemp === 'undefined') {
            if (body.temp >= cfgBody.heatSetpoint) hState.prevHeaterOffTemp = body.temp; 
        }
        else {
            if (hState.prevHeaterOffTemp - body.temp > 1) hState.prevHeaterOffTemp === undefined;
        }
    }
    break;

[rstrouse]

Realistically, I believe it hangs on to the solar temp setpoint + 1 so it shouldn't cycle on you. This is how IntelliCenter actually handles this. To drop a full degree in temperature over 20kgal of water is hard to do that is unless the temperature probe is after the heater. Why are you fluctuating so much?

[tagyoureit]

Our prev code didn't take into account any start/stop temp deltas. So the solar would cycle with 0.03 degrees difference (83 -> 82.97). I'm not even sure the "acceptable range" through any of the OCP UI's allows <3 degrees of start differential so having a minimum safety net at 1 degree makes sense.

[CodeSlinger69]

Testing underway. Solar did not turn on automatically this morning due to the old assignment vs. evaluation bug. I can't tell you how many times I've done this in my life.

This line:
if (hState.prevHeaterOffTemp - body.temp > 1) hState.prevHeaterOffTemp === undefined;

Should be:
if (hState.prevHeaterOffTemp - body.temp > 1) hState.prevHeaterOffTemp = undefined;

This needs to be fixed in the current committed code base as well. Controller/Boards/SystemBoard.ts, line 4164.

I'll watch carefully today and see what happens when the setpoint is hit.

[tagyoureit]

due to the old assignment vs. evaluation bug

Pushed up the fix. Thx.

[johnny2678]

Great to see the discussion on this. I can't be certain, but guessing this has something to do with my pump frequently switching back and forth to/from the solar circuit.

Also, not to hijack - but these settings still don't work on ET4 setup. This was just trying to change the start delta from 6 to 7. Results in a stacktrace:

ApiError: Message aborted after 3 attempt(s): 165,32,16,33,162,3,7,0,194,2,100 
    at RS485Port.writeMessage (/home/pi/nodejs-poolController/controller/comms/Comms.ts:1010:31)
    at RS485Port.processWaitPacket (/home/pi/nodejs-poolController/controller/comms/Comms.ts:946:22)
    at RS485Port.processOutboundPackets (/home/pi/nodejs-poolController/controller/comms/Comms.ts:954:19)
    at RS485Port.processPackets (/home/pi/nodejs-poolController/controller/comms/Comms.ts:936:14)
    at Timeout. (/home/pi/nodejs-poolController/controller/comms/Comms.ts:989:52)
    at listOnTimeout (node:internal/timers:569:17)
    at processTimers (node:internal/timers:512:7)

Replay of the action:
replay (5).zip

[tagyoureit]

@johnny2678 The problem is this line out.setPayloadByte(2, ((obj.startTempDelta || 6) - 3 << 6) | ((obj.stopTempDelta || 3) - 2 << 1)); EasyTouchBoard.ts#2797. The values startTempDelta=7 and stopTempDelta=3 result in an invalid value of 258.

Do you have another way of setting this and capturing the right packets from another device (Screenlogic or indoor control panel?). I need to see what the correct logic is. If you do, and can run through and capture all the start/stop temp deltas we should be able to figure it out.

[johnny2678]

Do you have another way of setting this and capturing the right packets from another device (Screenlogic or indoor control panel?).

Hey @tagyoureit, I think this is where we ended up when I reported it previously. Unfortunately, I don't have an indoor control panel and I don't see those settings exposed in ScreenLogic?

I suppose we could make a plea to the ET users in the broader njspc community...🤓😜

[CodeSlinger69]

Creating a new reply to my O.P. so it shows up on the bottom.

Status update: All good so far. Yesterday my water temp hit the setpoint of 83, the solar heating turned off, and the latching mechanism worked as expected to prevent the pump from cycling. Overnight my water temperature dropped to 79.8, which cleared the latch. When the solar energy was strong enough this morning, the solar heating turned back on and is currently warming the water as I type this.

The code I'm using is pasted below, and I would ask that this be commited to the repository. It is a very small change to the code that existed prior to this thread in that it only adds the latching (temperature differential) logic. The code that handled start delta and stop delta was working just fine before this thread, so I suggest we keep that original logic.

A couple of additional thoughts:

• I did not add the latch for nocturnal cooling, and I don't think its needed. I'm happy to debate this.
• I might suggest that the temperature differential that is currently hardcoded as "1" in the code be exposed as a setting next to start and stop delta. Many home termostats have this as a programmable setting.
• Does this kind of latching logic need to be added for gas heaters/heat pumps? I think so for the same reason as solar - this is just standard practice with home furnace thermostats, so why not with pool furnaces?

Thanks again for the support and discussion on this.

case 'solar':
    if (mode === 'solar' || mode === 'solarpref') {
        let hState: HeaterState = state.heaters.getItemById(heater.id);

        // solar heating
        if (body.temp < cfgBody.heatSetpoint &&
            state.temps.solar > body.temp + (hstate.isOn ? heater.stopTempDelta : heater.startTempDelta) &&
            typeof hState.prevHeaterOffTemp === 'undefined'
        ) {
            isOn = true;
            body.heatStatus = sys.board.valueMaps.heatStatus.getValue('solar');
            isHeating = true;
        }

        // nocturnal cooling
        else if (heater.coolingEnabled &&
             body.temp > cfgBody.coolSetpoint && 
             state.temps.solar < body.temp - (hstate.isOn ? heater.stopTempDelta : heater.startTempDelta) &&
             state.heliotrope.isNight
        ) {
            isOn = true;
            body.heatStatus = sys.board.valueMaps.heatStatus.getValue('cooling');
            isHeating = true;
            isCooling = true;
        }

        // solar heating temperature diffential latch
        if (typeof hState.prevHeaterOffTemp === 'undefined') {
            if (body.temp >= cfgBody.heatSetpoint) hState.prevHeaterOffTemp = body.temp;
        }
        else {
            if (hState.prevHeaterOffTemp - body.temp > 1) hState.prevHeaterOffTemp = undefined;
        }
    }
    break;

[tagyoureit]

I asked ChatGPT to help here...
The first approach is what is in the repo, 2nd is what you have above. Read below and then try to change my mind. :) https://chat.openai.com/share/d2b62b68-6238-45da-9ffa-8de004ff5e9d (I removed the nocturnal cooling to keep the conversation more focused.)

---

User
compare the two different approaches. and ask me any clarifying questions that you may need to help.

ChatGPT
Certainly! Let's compare the two approaches:

1. Approach 1:

• Activation Logic:
  • Considers multiple conditions for activation, including solar temperature, water temperature, temperature differentials, and previous heater off temperature.
  • Activates the heater if all conditions are met, ensuring efficient heating.
• Temperature Differential Handling:
  • Employs separate start and stop temperature differentials to control when the heating starts and stops.
  • Utilizes both start and stop temperature deltas to determine heating behavior.
• Previous Heater Off Temperature Management:
  • Tracks the previous heater off temperature to avoid frequent cycling of the heater.
  • Updates the previous heater off temperature when the heater turns off.

2. Approach 2:

• Activation Logic:
  • Simplifies the activation logic by considering fewer conditions, mainly focusing on the temperature differentials and the presence of a previous heater off temperature.
  • Activates the heater based on a temperature differential between the water and solar temperatures and the absence of a previous heater off temperature.
• Temperature Differential Handling:
  • Adjusts the temperature differential based on whether the heater is already on or off, potentially providing more flexibility in heating control.
• Previous Heater Off Temperature Management:
  • Sets the previous heater off temperature when the water temperature is above the set point, simplifying the management of this parameter.
  • Clears the previous heater off temperature if the temperature differential exceeds a certain threshold, possibly to prevent unnecessary delays in heater activation.

Clarifying Questions:

1. Are there any specific performance metrics or goals (e.g., energy efficiency, temperature stability) that the system aims to achieve?
2. How critical is it to avoid frequent cycling of the heater?
3. Is there any specific reason for the differences in temperature differential handling between the two approaches?
   Understanding these aspects will help provide a more nuanced comparison and determine which approach better suits the requirements of the system.

User
Answers:

1. The only goal is to heat the pool to the desired temperature
2. It is of utmost criticality that frequent cycling is avoided.
3. The differences are because two developers are each trying to make their case for the best approach.

ChatGPT
Thank you for the clarification. Given the goal of heating the pool to the desired temperature while minimizing frequent cycling of the heater, let's analyze how each approach aligns with these requirements:

1. Approach 1:

• Advantages:
  • Rigorous activation logic with multiple conditions may result in more precise control over heater activation, potentially leading to better temperature regulation.
  • Tracking the previous heater off temperature helps prevent frequent cycling by ensuring that the heater remains off until the temperature conditions are suitable.
• Considerations:
  • The complex activation logic may introduce more opportunities for bugs or unintended behavior if not thoroughly tested.
  • The management of start and stop temperature differentials adds flexibility but also complexity to the system.

2. Approach 2:

• Advantages:
  • Simplified activation logic may reduce the risk of bugs and make the code easier to understand and maintain.
  • Adjusting the temperature differential based on the current state of the heater could provide more adaptive control, potentially leading to smoother operation.
• Considerations:
  • Simplifying the logic may sacrifice some precision in heater activation, which could affect temperature regulation.
  • Clearing the previous heater off temperature based on a threshold may introduce the risk of premature activation if the threshold is not carefully chosen.

Given the criticality of avoiding frequent cycling, Approach 1 seems more robust in ensuring that the heater remains off until the temperature conditions are suitable. However, Approach 2 offers simplicity and potentially more adaptive control.

To determine the best approach, it might be beneficial to conduct thorough testing, including simulations or real-world trials, to evaluate each approach's performance in achieving the desired temperature while minimizing frequent cycling. Additionally, considering factors such as code maintainability and ease of understanding could also inform the decision.

Do you need further analysis or assistance in evaluating these approaches?

User
which one would you use?

ChatGPT
Given the criticality of avoiding frequent cycling while efficiently heating the pool to the desired temperature, I would lean towards Approach 1. Here's why:

1. Robust Activation Logic: Approach 1 employs a comprehensive set of conditions to determine when to activate the heater, considering factors such as temperature differentials and the previous heater off temperature. This robust logic helps ensure that the heater remains off until the temperature conditions are suitable, minimizing the risk of frequent cycling.
2. Prioritizing Temperature Stability: The tracking of the previous heater off temperature in Approach 1 indicates a deliberate effort to prioritize temperature stability and avoid unnecessary heater cycling. By waiting until the temperature conditions are sufficiently favorable, this approach aims to maintain a more stable pool temperature.
3. Potential for Precise Control: While Approach 2 offers simplicity, Approach 1's more detailed activation logic may provide more precise control over heater activation, potentially resulting in better temperature regulation and energy efficiency.
4. Maintainability and Extensibility: Despite its complexity, Approach 1's logic is well-documented and structured, making it easier to understand and maintain over time. Additionally, the use of separate start and stop temperature differentials adds flexibility and extensibility to the system, allowing for fine-tuning of heating parameters as needed.

Overall, while Approach 1 may be more complex than Approach 2, its emphasis on temperature stability and precise control aligns better with the goal of avoiding frequent cycling while efficiently heating the pool. However, thorough testing and validation in real-world conditions would be essential to confirm its effectiveness in meeting the system requirements.

Would you like to explore any other aspects or considerations before making a decision?

[CodeSlinger69]

Can't argue with ChatGPT! If you are not interested in my logic, no hard feelings, I'll just maintain a fork for myself. My logic works for me, but I understand that you are building something for a community that is larger than just me, so additional considerations are required.

[CodeSlinger69]

As my final update on this, I'd like to acknowledge how well the solar logic worked yesterday. We had "Simpsons" clouds all day (big fluffy white things intermixed with blue skies), which allowed me to observe the start/stop delta functionality. As a reminder, there were two main scenarios discussed in this thread:

1. Temperature differential latching on hitting setpoint - as previously reported, this works great with the addition of the new latching code.
2. Drop in solar energy, such as by cloud passing in front of sun - subject of this post.

I am running the original code prior to this thread; the relevant line looks like this:
state.temps.solar > body.temp + (hstate.isOn ? heater.stopTempDelta : heater.startTempDelta) &&

My start delta is 7 and my stop delta is 4. Yesterday the setpoint was never reached, so the latching mechanism was never engaged. The solar was able to cycle on and off as the clouds passed in front of the sun. IMHO, the line of code above perfectly captures the intent as described in Pentair's documentation, and I can confirm it works (in my situation) to cycle solar on and off as the available solar energy fluctuates.

Thanks again for the help in understanding this logic and helping me tune the code to my needs.