batpred Standing charge still shown in Rates chart for Today p/kWh

Describe the bug Contrary to 'What's changed' in v8.5.6 , standing charge still shows in Rates chart for Today p/kWh. This gives a big skew round about midnight. This occurs in WebUI Rates chart and in Energy rates chart from withinTemplates/example_chart.yml

Expected behaviour Standing charge disappears!

Predbat version v8.5.6 onwards

Environment details

Inverter and battery setup
Standard HAOS installer or Docker
Anything else?

Screenshots See above

Log file N/A

Nov 15 '24 09:11 SwiftRR

What version are you on now as there were fixes in 8.5.10?

Nov 16 '24 12:11 springfall2008

I'm on v8.6.0 but you can see from my screenshots that I am seeing a large peak in Today p/kWh at around midnight each day. I have copied the charts again below. I have offset the main predbat chart back 24h so that the 2 charts are comparable. I have also copied in the latest rate code from chart.yml.

If you look at the maximum in the 'template' chart, it is very much different from the WebUI. e.g. 48p against 100p! My standing charge os 53 p Does this mean that standing charge was removed from WebUI but not from template?

Rob

Nov 16 '24 13:11 SwiftRR

Can you share the YAML of our Apex charge, maybe there is something wrong with it?

Nov 16 '24 15:11 springfall2008

The values between the WebUI and Apex charts all look the same (or close to the same) except for the values at midnight.

In my apps.yaml, I have the metric_standing_charge line commented out.

This is the chart code I have been using. Copied from chart.yml. As I have no gas, I have to delete the section: '- entity: predbat.rates_gas'

###############################################
# Energy rate chart
# NOTE: Tune the value*5 in the grid_power_best part to make the power peak line up with the energy rates
# so you can see charging/discharging aligned with slots
###############################################
type: custom:apexcharts-card
header:
  show: true
  title: Energy rates
  show_states: true
  colorize_states: true
graph_span: 72h
span:
  start: day
  offset: -24h
now:
  show: true
series:
  - entity: predbat.grid_power_best
    name: power
    stroke_width: 1
    type: area
    opacity: 0.2
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value*5]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
  - entity: predbat.rates
    attribute: threshold
    name: Low threshold
    curve: stepline
    stroke_width: 2
  - entity: predbat.rates_export
    attribute: threshold
    name: High threshold
    curve: stepline
    stroke_width: 2
  - entity: predbat.rates
    stroke_width: 2
    curve: stepline
    name: import
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.rates_export
    stroke_width: 1
    type: area
    opacity: 0.2
    curve: stepline
    name: export
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.rates_gas
    stroke_width: 1
    type: area
    opacity: 0.2
    curve: stepline
    name: gas
    data_generator: >
      let res = []; for (const [key, value] of
      Object.entries(entity.attributes.results)) { res.push([new
      Date(key).getTime(), value]); } return res.sort((a, b) => { return a[0] -
      b[0]  })
    show:
      in_header: raw
  - entity: predbat.ppkwh_hour
    stroke_width: 2
    type: line
    curve: stepline
    name: Hourly p/kWh
    extend_to: false
  - entity: predbat.ppkwh_today
    stroke_width: 2
    type: line
    curve: stepline
    name: Today p/kWh
    extend_to: false

Rob

Nov 16 '24 15:11 SwiftRR

The spikes at midnight have now disappeared and WebUI and Apex charts look very similar. So this issue seems to have been fixed or has worked its way through HA..

My only niggle now is that the Apex chart shows almost identical line colours for 'hourly' and 'today'. You can see this in my earlier screenshots. I guess that there is a way to tweak colours within Apex settings – something for me to investigate.

Rob

Nov 23 '24 11:11 SwiftRR

Running version: Current version: 1.2.4 (Changelog)

Hi,

I'm also seeing high rate estiamtes at the crossover boundaries between different tariffs.

Is this the same issue as reported here?

I wondered if this was linked to the rate settings in apps.yaml

snip from my apps.yaml are as follows: (Note: I'm not using any Octopus 'suto' data pulling, as I am with BGas)

            # Or set your actual rates across time for import and export
              # If start/end is missing it's assumed to be a fixed rate
              # Gaps are filled with zero rate
              rates_import:
                -  start: "00:00:01"
                   end: "05:00:00"
                   rate: 7.9
                -  start: "05:00:01"
                   end: "00:00:00"
                   rate: 27.002
              #
              rates_export:
                -  rate: 15.0

So I adjusted these to ensure no gap / overlap, but this made no difference.

I've also added here a chart that shows the time periods of the 'steps' where the calculation improves over time

Feb 25 '25 07:02 trevordowling

Running version: Current version: 1.2.4 (Changelog)

Hi,

I'm also seeing high rate estiamtes at the crossover boundaries between different tariffs.

Is this the same issue as reported here?

I wondered if this was linked to the rate settings in apps.yaml

snip from my apps.yaml are as follows: (Note: I'm not using any Octopus 'suto' data pulling, as I am with BGas)
            # Or set your actual rates across time for import and export
              # If start/end is missing it's assumed to be a fixed rate
              # Gaps are filled with zero rate
              rates_import:
                -  start: "00:00:01"
                   end: "05:00:00"
                   rate: 7.9
                -  start: "05:00:01"
                   end: "00:00:00"
                   rate: 27.002
              #
              rates_export:
                -  rate: 15.0
So I adjusted these to ensure no gap / overlap, but this made no difference.

I've also added here a chart that shows the time periods of the 'steps' where the calculation improves over time

Per the documentation, start and end time should align to 30 minute boundaries https://springfall2008.github.io/batpred/energy-rates/#rate-bands-to-manually-configure-energy-rates

So don't put 00:00:01, put 00:00:00 as the start time is the correct way to configure predbat

Feb 25 '25 09:02 gcoan

Brilliant, and thanks, I did have them compliant but I also had a 2 minute clock skew, which possibly broke the adherence to 30 min boundaries... I'll update (I've also removed the clock skew) and check this fixes it.

Thanks

Trevor

On Tue, 25 Feb 2025, 09:39 Geoffrey Coan, @.***> wrote:

Running version: Current version: 1.2.4 (Changelog)

Hi,

I'm also seeing high rate estiamtes at the crossover boundaries between different tariffs.

image.png (view on web) https://github.com/user-attachments/assets/5cf8ac2a-32f9-4114-8505-e26ac5677487

Is this the same issue as reported here?

I wondered if this was linked to the rate settings in apps.yaml

snip from my apps.yaml are as follows: (Note: I'm not using any Octopus 'suto' data pulling, as I am with BGas)
        # Or set your actual rates across time for import and export
          # If start/end is missing it's assumed to be a fixed rate
          # Gaps are filled with zero rate
          rates_import:
            -  start: "00:00:01"
               end: "05:00:00"
               rate: 7.9
            -  start: "05:00:01"
               end: "00:00:00"
               rate: 27.002
          #
          rates_export:
            -  rate: 15.0
So I adjusted these to ensure no gap / overlap, but this made no difference.

I've also added here a chart that shows the time periods of the 'steps' where the calculation improves over time

image.png (view on web) https://github.com/user-attachments/assets/b5ce7f74-031e-452f-a2c8-e04a5e8851d9

Per the documentation, start and end time should align to 30 minute boundaries https://springfall2008.github.io/batpred/energy-rates/#rate-bands-to-manually-configure-energy-rates

So don't put 00:00:01, put 00:00:00 as the start time is the correct way to configure predbat

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2681339799, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMLR5THFG4TTU7WNCYD2RQ235AVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGMZTSNZZHE . You are receiving this because you commented.Message ID: @.***> [image: gcoan]gcoan left a comment (springfall2008/batpred#1624) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2681339799

Running version: Current version: 1.2.4 (Changelog)

Hi,

I'm also seeing high rate estiamtes at the crossover boundaries between different tariffs.

image.png (view on web) https://github.com/user-attachments/assets/5cf8ac2a-32f9-4114-8505-e26ac5677487

Is this the same issue as reported here?

I wondered if this was linked to the rate settings in apps.yaml

snip from my apps.yaml are as follows: (Note: I'm not using any Octopus 'suto' data pulling, as I am with BGas)
        # Or set your actual rates across time for import and export
          # If start/end is missing it's assumed to be a fixed rate
          # Gaps are filled with zero rate
          rates_import:
            -  start: "00:00:01"
               end: "05:00:00"
               rate: 7.9
            -  start: "05:00:01"
               end: "00:00:00"
               rate: 27.002
          #
          rates_export:
            -  rate: 15.0
So I adjusted these to ensure no gap / overlap, but this made no difference.

I've also added here a chart that shows the time periods of the 'steps' where the calculation improves over time

image.png (view on web) https://github.com/user-attachments/assets/b5ce7f74-031e-452f-a2c8-e04a5e8851d9

Per the documentation, start and end time should align to 30 minute boundaries https://springfall2008.github.io/batpred/energy-rates/#rate-bands-to-manually-configure-energy-rates

So don't put 00:00:01, put 00:00:00 as the start time is the correct way to configure predbat

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2681339799, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMLR5THFG4TTU7WNCYD2RQ235AVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGMZTSNZZHE . You are receiving this because you commented.Message ID: @.***>

Feb 25 '25 10:02 trevordowling

Hi,

I let the system run overnight and I still see these high values on the boundaries of the rate changes

Settings from apps.yaml

Rates

   rates_import:
    -  start: "00:00:00"
       end: "05:00:00"
       rate: 7.9
    -  start: "05:00:00"
       end: "00:00:00"
       rate: 27.002

Skew settings

  inverter_clock_skew_start: 0
  inverter_clock_skew_end: 0
  inverter_clock_skew_discharge_start: 0
  inverter_clock_skew_discharge_end: 0

Any ideas?

Please shout if you need any additional data or tests run. (low priority from my side, as it doesn't impact operation)

Thanks

Trevor

Feb 26 '25 06:02 trevordowling

Do you have a standing charge defined in apps.yaml and are you on the latest verison of predbat ?

I'm thinking its this that's corrupting the chart because at midnight, cost today and kwh today is reset to zero, but standing charge applied and after a tiny but of energy consumed you'll get a spike of cost/kWh if standing charge is included in the calculation

Feb 27 '25 00:02 gcoan

Hi,

Yes, I do have a standing charge defined [image: image.png]

I'm running version [image: image.png] I've changed settings around the rates and standing changes to see if I could confirm if the standing charge is the issue, but it looks like the charts are only generated once, as I don't see any changes to the data that appears in the past (data to the left of the NOW line).

[image: image.png]

Hope this helps

Trevor

On Thu, Feb 27, 2025 at 12:53 AM Geoffrey Coan @.***> wrote:

Do you have a standing charge defined in apps.yaml and are you on the latest verison of predbat ?

I'm thinking its this that's corrupting the chart because at midnight, cost today and kwh today is reset to zero, but standing charge applied and after a tiny but of energy consumed you'll get a spike of cost/kWh if standing charge is included in the calculation

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2686537336, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMO76YDNUX27QXKXULD2RZOX5AVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBWGUZTOMZTGY . You are receiving this because you commented.Message ID: @.***> [image: gcoan]gcoan left a comment (springfall2008/batpred#1624) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2686537336

Do you have a standing charge defined in apps.yaml and are you on the latest verison of predbat ?

I'm thinking its this that's corrupting the chart because at midnight, cost today and kwh today is reset to zero, but standing charge applied and after a tiny but of energy consumed you'll get a spike of cost/kWh if standing charge is included in the calculation

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2686537336, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMO76YDNUX27QXKXULD2RZOX5AVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBWGUZTOMZTGY . You are receiving this because you commented.Message ID: @.***>

Feb 27 '25 06:02 trevordowling

just as a debug, could you comment the standing charge line out of apps.yaml and let the comparison run as normal through midnight to see if this resolves the problem please

and to confirm,you are on the latest predbat version (not the addon version, the predbat version) - it'll be displayed at the top of your HTML predbat plan

Feb 27 '25 10:02 gcoan

Will do.

Version is v8.15.1 (apologies for grabbing the wrong version ID)

I'm also looking at significant register writes (hundreds a day, which is not good), which needs attention. There are a significant number of writes to set Eco mode every 5 minutes... I don't know if this is normal, but if nothing else it is polluting my logs while I'm trying to track down why forced export is not working correctly. I've been through the documentation notes on items to set to minimise the flash writes, not sure if flash writes and register writes are the same.

[image: image.png]

2025-02-27 06:22:15,368 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:25:08,804 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:29:52,669 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:30:46,212 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:32:20,035 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:35:04,446 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:40:07,537 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:45:03,291 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:50:07,511 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 06:55:03,582 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 07:00:04,160 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 07:05:04,924 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 07:10:04,555 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 07:15:04,354 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 07:20:05,064 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-27 07:25:04,407 - GivTCP - write - [INFO ] - Setting Eco mode was a success

I have checked the Inverter logs and it doesn't look like these end up being actual writes to the flash, which is good, but I'm still not sure why the GivTCP logs are showing this many entries for this. Possible, this is normal behaviour, but I need to look a bit more before opening a new entry.

While I've got this to look at, I've suspended the system by setting the ' Read Only mode' but I assume the rate calculations will be fine and so hopefully we can see if this 'fixes' things overnight.

Thanks

Trevor

On Thu, Feb 27, 2025 at 10:48 AM Geoffrey Coan @.***> wrote:

just as a debug, could you comment the standing charge line out of apps.yaml and let the comparison run as normal through midnight to see if this resolves the problem please

and to confirm,you are on the latest predbat version (not the addon version, the predbat version) - it'll be displayed at the top of your HTML predbat plan

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2687578003, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMLXH3DIA26SIMLMD3T2R3UOLAVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBXGU3TQMBQGM . You are receiving this because you commented.Message ID: @.***> [image: gcoan]gcoan left a comment (springfall2008/batpred#1624) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2687578003

just as a debug, could you comment the standing charge line out of apps.yaml and let the comparison run as normal through midnight to see if this resolves the problem please

and to confirm,you are on the latest predbat version (not the addon version, the predbat version) - it'll be displayed at the top of your HTML predbat plan

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2687578003, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMLXH3DIA26SIMLMD3T2R3UOLAVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBXGU3TQMBQGM . You are receiving this because you commented.Message ID: @.***>

Feb 27 '25 11:02 trevordowling

I'm also looking at significant register writes (hundreds a day, which is not good), which needs attention. There are a significant number of writes to set Eco mode every 5 minutes... I don't know if this is normal, but if nothing else it is polluting my logs while I'm trying to track down why forced export is not working correctly

No that's not right, it shouldn't be doing that, certainly not every 5 minutes. Looks like its trying to make the change but the change isn't working. That looks like its in the GivTCP log? Do check that inverter_mode in apps.yaml is set correctly, and maybe restart givtcp and/or your inverter if its not responding to the command. If necessary create a new issue.

Feb 27 '25 12:02 gcoan

Hi,

Yep good to hear that this isn't correct behaviour. I'll continue to dig a bit before formally raising the issue.

The three phase system has a few differences and even the GivEnergy app doesn't work correctly in all areas.

Thanks

Trevor

On Thu, 27 Feb 2025, 12:45 Geoffrey Coan, @.***> wrote:

I'm also looking at significant register writes (hundreds a day, which is not good), which needs attention. There are a significant number of writes to set Eco mode every 5 minutes... I don't know if this is normal, but if nothing else it is polluting my logs while I'm trying to track down why forced export is not working correctly

No that's not right, it shouldn't be doing that, certainly not every 5 minutes. Looks like its trying to make the change but the change isn't working. That looks like its in the GivTCP log? Do check that inverter_mode in apps.yaml is set correctly, and maybe restart givtcp and/or your inverter if its not responding to the command. If necessary create a new issue.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2687858753, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMMTCB2Q2E2UKMNBRCD2R4CFZAVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBXHA2TQNZVGM . You are receiving this because you commented.Message ID: @.***> [image: gcoan]gcoan left a comment (springfall2008/batpred#1624) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2687858753

I'm also looking at significant register writes (hundreds a day, which is not good), which needs attention. There are a significant number of writes to set Eco mode every 5 minutes... I don't know if this is normal, but if nothing else it is polluting my logs while I'm trying to track down why forced export is not working correctly

No that's not right, it shouldn't be doing that, certainly not every 5 minutes. Looks like its trying to make the change but the change isn't working. That looks like its in the GivTCP log? Do check that inverter_mode in apps.yaml is set correctly, and maybe restart givtcp and/or your inverter if its not responding to the command. If necessary create a new issue.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2687858753, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMMTCB2Q2E2UKMNBRCD2R4CFZAVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBXHA2TQNZVGM . You are receiving this because you commented.Message ID: @.***>

Feb 27 '25 14:02 trevordowling

The three phase system has a few differences and even the GivEnergy app doesn't work correctly in all areas. Thanks Trevor

ah, you have a 3 phase inverter. There are still some teething problems with that inverter and givtcp/predbat. There's other givtcp threads on getting it working, I think you need to be on the dev version of givtcp for maximum compatibility, but do look at the other threads

Feb 27 '25 16:02 gcoan

Will do, yes, I've seen a few of us on the 3 phase, many comments like 'there aren't many of us'

Everyone's been great and helpful. Many wanting help from us to make their code support the 3 phase systems... I'm really inspired by the community approach...

I'm probably too rusty to add new code, but very happy to test and debug as needed.

Trevor

On Thu, 27 Feb 2025, 16:21 Geoffrey Coan, @.***> wrote:

The three phase system has a few differences and even the GivEnergy app doesn't work correctly in all areas. Thanks Trevor

ah, you have a 3 phase inverter. There are still some teething problems with that inverter and givtcp/predbat. There's other givtcp threads on getting it working, I think you need to be on the dev version of givtcp for maximum compatibility, but do look at the other threads

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2688462446, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMNSOY5DXBR3GJY34YL2R43R5AVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGQ3DENBUGY . You are receiving this because you commented.Message ID: @.***> [image: gcoan]gcoan left a comment (springfall2008/batpred#1624) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2688462446

The three phase system has a few differences and even the GivEnergy app doesn't work correctly in all areas. Thanks Trevor

ah, you have a 3 phase inverter. There are still some teething problems with that inverter and givtcp/predbat. There's other givtcp threads on getting it working, I think you need to be on the dev version of givtcp for maximum compatibility, but do look at the other threads

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2688462446, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMNSOY5DXBR3GJY34YL2R43R5AVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGQ3DENBUGY . You are receiving this because you commented.Message ID: @.***>

Feb 27 '25 17:02 trevordowling

@gcoan asked

'just as a debug, could you comment the standing charge line out of apps.yaml and let the comparison run as normal through midnight to see if this resolves the problem please'

Line commented out in apps.yaml

  #metric_standing_charge: 0.487

Let is run a couple of days, sadly it still shows the peaks (but as before, low priority on this one)

Mar 01 '25 22:03 trevordowling

Been looking at the charts you posted here and earlier https://github.com/springfall2008/batpred/issues/1624#issuecomment-2680973540

In the earlier ones the spikes were to 200p, this most recent one its to about 75p?

My own chart which has never had standing charge include in the plan doesn't show big positive spikes as you have, but instead has a smaller negative one on the today figure, and some massive negative on the hourly figure

Are you charging at midnight?

I am on Cosy so predbat stops charging at midnight and goes into Eco/Demand mode.

Am wondering if the problem is down to one of the sensors not being updated as quickly as the other one, so the cost/energy figure gets some wacky numbers, and me discharging at that time and you (possibly) charging at that time explains why the sign is different

Mar 01 '25 22:03 gcoan

Yes, my charge window is 00:00:00 - 05:00:00

On Sat, 1 Mar 2025, 22:55 Geoffrey Coan, @.***> wrote:

Been looking at the charts you posted here and earlier #1624 (comment) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2680973540

In the earlier ones the spikes were to 200p, this most recent one its to about 75p?

My own chart which has never had standing charge include in the plan doesn't show big positive spikes as you have, but instead has a smaller negative one on the today figure, and some massive negative on the hourly figure F30047D8-F6C8-4E9A-8C2E-73320A7BA099.png (view on web) https://github.com/user-attachments/assets/eecd0e1c-c1dc-4e3a-828a-603d415c526a

Are you charging at midnight?

I am on Cosy so predbat stops charging at midnight and goes into Eco/Demand mode.

Am wondering if the problem is down to one of the sensors not being updated as quickly as the other one, so the cost/energy figure gets some wacky numbers, and me discharging at that time and you (possibly) charging at that time explains why the sign is different

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2692457358, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMNL3PTMHAGOVYDDWCD2SI3GNAVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJSGQ2TOMZVHA . You are receiving this because you commented.Message ID: @.***> [image: gcoan]gcoan left a comment (springfall2008/batpred#1624) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2692457358

Been looking at the charts you posted here and earlier #1624 (comment) https://github.com/springfall2008/batpred/issues/1624#issuecomment-2680973540

In the earlier ones the spikes were to 200p, this most recent one its to about 75p?

My own chart which has never had standing charge include in the plan doesn't show big positive spikes as you have, but instead has a smaller negative one on the today figure, and some massive negative on the hourly figure F30047D8-F6C8-4E9A-8C2E-73320A7BA099.png (view on web) https://github.com/user-attachments/assets/eecd0e1c-c1dc-4e3a-828a-603d415c526a

Are you charging at midnight?

I am on Cosy so predbat stops charging at midnight and goes into Eco/Demand mode.

Am wondering if the problem is down to one of the sensors not being updated as quickly as the other one, so the cost/energy figure gets some wacky numbers, and me discharging at that time and you (possibly) charging at that time explains why the sign is different

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1624#issuecomment-2692457358, or unsubscribe https://github.com/notifications/unsubscribe-auth/BOLDBMNL3PTMHAGOVYDDWCD2SI3GNAVCNFSM6AAAAABR2XJ2T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJSGQ2TOMZVHA . You are receiving this because you commented.Message ID: @.***>

Mar 01 '25 22:03 trevordowling