Wintertime Net Metering Credit Management

[imcintyr]

Hi all, I am sharing out a mad scientist scheme to help me control our power usage over the wintertime. I started out wanting to create an automation that controlled the heat pump based on the luminance measurements from the weather station during the day (obviously). We have solar panels and I want to control the 50 kWh usage days when the day is overcast and it is cold. I have since shifted to controlling the use of kWh credits beginning in October and going through March since that is what I am actually trying to spread out.

I have lots of blind spots and would love to see any corrections, additions, etc. Basically, there is a variable I will update every month that is the average credits remaining between now() and the beginning of the next April. Once the usage less the production is greater than that number it will change the low balance temp to 45. It will reset that back to 25 at midnight when the calc resets.

I am very new here so let me know what you think and how to make it better. Also, I am trying to paste my YAML code in using the code toggle at the top of this editor and it's not looking as fancy as everyone else's. Grr.

`alias: Thermostat - Balance Point - Over Credit Allowance
description: Set high balance point due to energy usage.
trigger:

• platform: time_pattern
  hours: /1
  condition:
• condition: template
  value_template: "{{ now().month >= 10 or now().month <= 3 }}"
  action:
• choose:
  • conditions:

    • condition: template
      value_template: >-
      {{states('sensor.envoy_202334085385_energy_consumption_today') |
      float -

      states('sensor.envoy_202334085385_energy_production_today') |
      float < states('input_number.daily_credit_limit')|int}}

    • condition: numeric_state
      entity_id: number.harmony_par_low_balance_point
      above: 25
      sequence:

    • service: script.turn_on
      metadata: {}
      data: {}
      target:
      entity_id: script.set_lo_bal_25

  • conditions:

    • condition: template
      value_template: >-
      {{states('sensor.envoy_202334085385_energy_consumption_today') |
      float -

      states('sensor.envoy_202334085385_energy_production_today') |
      float > states('input_number.daily_credit_limit')|int}}

    • condition: numeric_state
      entity_id: number.harmony_par_low_balance_point
      below: 45
      sequence:

    • service: script.turn_on
      metadata: {}
      data: {}
      target:
      entity_id: script.1707665901740
      mode: single
      `

[PeteRager]

Thanks for the note, yeah the code block in GitHub has never worked for me. Try to surround it with 3 backquotes. That'll make it a lot easier to read.

It's definitely cool what you are doing, making sure you use the credits.

I tend to break these things into two parts.

First, have a template sensor that calculates the desired balance point. Overtime you may refine the logic to return more values than 25 and 45. Perhaps 25 uses too much power for too little gain. So this template may become fairly involved over time.

Second, have an automation the runs periodically (once an hour), or whenever that template sensor changes, that transfers the value to the number entity.

As an unrelated example, I use the fan on my Lennox system to move hot air from the Woodstove through the duct work to decrease heating cost (it's an AC only unit). Based on the temperature delta between rooms I control the fan CFM. I did find that when the outdoor temperature is below 20, this strategy causes more heat usage since the ductwork goes through unheated attic space. I use a similar pattern as describe above, a template sensor to calc the optimal CFM and a once and hour automation to set it.

[imcintyr]

Thanks for the reply, Pete. The system is brand new to us as of last Oct and the solar panels went in last Nov. I will have a much better understanding of any balance of credits at the end of September this year. I am still working through how to deal with the TOU delineation but I am less concerned about that right now. What are you looking at to calc the balance point? I have seen some massive power usage on cold days. The rabbit hole I could not find the end of was comparing kWh to Therm/BTU. I think it will come down to measuring the furnace runtime by tracking the ignition sensor. Looking at an Aug bill to get a baseline for the water heater and range, those therms can be carved out of a cold month bill and the remainder will be the furnace for the most part. I can look at cost comparison more intelligently at that point. Outside of that, I am at a loss to understand the comparison. Thanks again! Ian

…

On Mon, May 6, 2024 at 5:47 AM Pete Sage ***@***.***> wrote: Thanks for the note, yeah the code block in GitHub has never worked for me. Try to surround it with 3 backquotes. That'll make it a lot easier to read. It's definitely cool what you are doing, making sure you use the credits. I tend to break these things into two parts. First, have a template sensor that calculates the desired balance point. Overtime you may refine the logic to return more values than 25 and 45. Perhaps 25 uses too much power for too little gain. So this template may become fairly involved over time. Second, have an automation the runs periodically (once an hour), or whenever that template sensor changes, that transfers the value to the number entity. As an unrelated example, I use the fan on my Lennox system to move hot air from the Woodstove through the duct work to decrease heating cost (it's an AC only unit). Based on the temperature delta between rooms I control the fan CFM. I did find that when the outdoor temperature is below 20, this strategy causes more heat usage since the ductwork goes through unheated attic space. I use a similar pattern as describe above, a template sensor to calc the optimal CFM and a once and hour automation to set it. — Reply to this email directly, view it on GitHub <#323 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFQIC3QOOIYEDFLB3UINNDDZA5UV3AVCNFSM6AAAAABHIGUSH2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGMRYGI3TA> . You are receiving this because you authored the thread.Message ID: ***@***.***>