More H1 RS485 registers

[canton7]

Hi,

I've found some more H1 RS485 registers:

• 11070: PV total * 10
• 11071: PV today * 10
  ... Presumably some in the range 11072-11078 are for charge / discharge, but I'm still waiting on my battery so can't test
• 11079: Feed-in total * 10
• 11080: Feed-in today * 10
• 11082: Consume total * 10 (as shown under History on the inverter. Is this grid consumption?)
• 11083: Consume today * 10 (as shown under History on the inverter)
  ... Presumably EPS is next, but I can't test
• 11085: I think this is 'Energy Generated Total' * 10. The number's about right, but I can't find anything to compare it to
• 11086: I think this is 'Energy Generated Today' * 10

[TonyM1958]

Note: these sensors are already in Nathan Marlor's code, so getting consistent naming and unique_ids when adding these might need to be considered?

11070	Solar Energy Total
11071	Solar Energy Today
11072	
11073	Battery Charge Total
11074	Battery Charge Today
11075	
11076	Battery Discharge Total
11077	Battery Discharge Today
11078	
11079	
11080	Feed In Energy Today
11081	
11082	Grid Consumption Energy Total
11083	Grid Consumption Energy Today
11084	
11085	Total Yield Total
11086	Total Yield Today

[canton7]

We suspect that the unknown registers 11072, etc, might be the higher 16 bits of some "total" sensors, but we don't currently know anyone who's transferred enough energy to test this...

[TonyM1958]

Makes complete sense. It's quite sunny today, I'll have a look later to see if its rolled over :-)).

I think I can add 11079 as Feed In Energy Total to my spread sheet from your list as well?

[TonyM1958]

Whilst we are on the subject, I vaguely recall seeing something about battery_cycle_count being available on RS485. Anyone know the register number as this would also be a useful addition?

[Daibutt]

11048 works for me for cycle count vis RS485 on an H1;

[TonyM1958]

looks right for cycle count - mine comes up at 54 for batteries installed 10th Jan and turned on 17th Jan so that's 78 days ago. Took me a couple of weeks with the batteries at min_soc before I got on a cheaper night tariff and started force charging each night.

Would be good if we could tag the higher 16-bit registers for the 32-bit totals listed above. I'll do a scan, but I have a feeling all of mine will come up as 0... For example, could Solar Energy Total be (11072 * 65536 + 11070), then 11073 / 11075, 11076 + 11078 etc

[TonyM1958]

here's what the values looks like for me:

Also so far un-named values present for 11088 and 11089?

[Daibutt]

I gave this a quick bash, will try and look in more detail over next couple of days.
11088 seems to be input energy total

Total Total yield looks like 11083 and 11085

2*65535-24193 = 106877

(slight delay between screenshots)

Will update when I find anything else

[canton7]

The -24193 is because you're interpreting a uint16 as an int16. Interpreted correctly, that's 41343. So your total yield is 65536 * 1 (register 11084) + 41343 (register 11085) = 10687.9.

Register 11083 is grid consumption today

[Daibutt]

OK cheers!

[canton7]

11088 seems to be input energy total

Would you mind clarifying what "input energy total" is exactly? Thanks!

[canton7]

Also, if anyone has an AC1 could they test these please? I've only been able to test on a H1.

[Daibutt]

11088 seems to be input energy total

Would you mind clarifying what "input energy total" is exactly? Thanks!

No idea sorry...... that's the heading title in data report from FoxCloud.......

[canton7]

11088 seems to be input energy total

Would you mind clarifying what "input energy total" is exactly? Thanks!

No idea sorry...... that's the heading title in data report from FoxCloud.......

Fair enough! They're all zero for me. I don't yet have a battery, so maybe it's something to do with that... Although we've already got registers for battery charge/discharge total.

[TonyM1958]

Just had a look at this because register pairs don't necessarily make sense when Solar Energy Total starts at 11070.

I'm getting a response from the modbus client from address 11050 through to 11089 so the modbus map is continuous from 11000 to 10089, giving us, potentially, 90 x 16 bit registers in all.

Most of 11050 - 11069 are 0 so I'm going to assume these are not used right now. Just 11060 has the value 1. My thinking here is 11069 is the upper 32 bits of Solar Energy Total meaning all the 32 bit values are stored consequetively - 11069/11070, 11072/11073 etc.

Will update my map along these lines - just needs someone with data for validation.

[canton7]

Yeah, that was my assumption as well. We just need someone who's generated more than 6600kWh of solar...

[TonyM1958]

H1 modbus map.xlsx

Updated spread sheet with uint32 registers / values. Entity names are now postfixed H / L. I assume these will require templates to combine them.

Update BMS kwh Total, register 11049 based on nathanmarlor/foxess_modbus#121

[canton7]

We've discovered that the following registers are unsigned also: 11070, 11073, 11076, 11079, 11082, 11085, 11049

[spmaid]

Yeah, that was my assumption as well. We just need someone who's generated more than 6600kWh of solar...

I have, what are you needing?

[TonyM1958]

Yeah, that was my assumption as well. We just need someone who's generated more than 6600kWh of solar...

I have, what are you needing?

Assuming you have a H1 inverter - don't know if other models have the same registers...

Can you install and run the Modbus Master from this tool against your inverter RS485 from a PC: https://github.com/ClassicDIY/ModbusTool

Let me know if you need any help setting up or configuring. Or use any other modbus tool you are happy with.

Scan a block of 21 Input Registers starting at 11069 (to 11089) and record the 16 bit values returned. We also need your totals from Fox ESS cloud, just after the scan to compare with the register values read. I'm not sure exactly where to get the cloud values, maybe others can advise on that?

Let us know if that sounds ok / not ok?

[TonyM1958]

We've discovered that the following registers are unsigned also: 11070, 11073, 11076, 11079, 11082, 11085, 11049

I've updated the spread sheet attached to the comment above, rather than upload yet another copy. The 16 bit and 32 bit totals are now uint16 / uint32. Going to get into version control issues if I spray too may copies around... :-)

[TonyM1958]

Added the following to my modbusUSB.yaml configuration:

    - name: "Solar Energy Total"
      address: 11069
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint32
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Solar Energy Today"
      address: 11071
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint16
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Battery Charge Total"
      address: 11072
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint32
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Battery Charge Today"
      address: 11074
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint16
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Battery Discharge Total"
      address: 11075
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint32
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Battery Discharge Today"
      address: 11077
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint16
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Feed In Energy Total"
      address: 11078
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint32
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Feed In Energy Today"
      address: 11080
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint16
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Grid Consumption Energy Total"
      address: 11081
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint32
      scale: 0.1
      precision: 2
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Grid Consumption Energy Today"
      address: 11083
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint16
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Total Yield Total"
      address: 11084
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint32
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Total Yield Today"
      address: 11086
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint16
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Input Energy Total"
      address: 11087
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint32
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"
    - name: "Input Energy Today"
      address: 11089
      scan_interval: !secret scan_interval_low
      slave: 247
      input_type: input
      data_type: uint16
      scale: 0.1
      precision: 1
      device_class: energy
      state_class: measurement
      unit_of_measurement: "kWh"

This produces the following sensor values:

My values don't currently go above 16 bits, so it's hard to tell, but it appears modbus is picking up values with data type uint16 and unint32. Can anyone else verify this is working correctly?

H1 modbus map.xlsx

[Daibutt]

Nice work! 👍
Yes as far as I can tell these all seem to match up with my data (~22 month's worth).
The daily ones virtually spot on compared to accumulated values in HA, "total" ones within a few % I reckon, but that may be my records and Foxcloud rounding (also the cloud doesn't have my battery discharge totals prior to spring 2022 for some reason).
Still don't know what "Input Energy" is, but the total value matches with the Foxcloud data report, not sure where the daily value for that is reported, so can't comment on that one specifically.

Thanks for tracking these down :)

[TonyM1958]

Early days, but here's a plot of Input Energy Today from last night. If I had to guess, I would say this is the energy consumed by the inverter when force charging. The difference between this and battery charge gives an efficiency of around 93%.

I think Battery Charge Today includes solar but Input Energy Today doesn't so expect them to diverge with solar production through the day?

[Daibutt]

Ah.... nice one!
That sort of makes sense with my limited data too.
I did 2x 30min force charges yesterday on a 5kW inverter (so you'd assume this should be 5kWh input energy).
Sure enough, Input Energy daily was 5.0kWh, but I added it to HA later in the day so couldn't see it increasing while force charging.
Battery charge showed 4.79kWh, so efficiency ~ 96%

[TonyM1958]

once we get a few days data, I think it should be clear, If Input Energy only rises during force charging, then I think we have a plausible rationale for what it is measuring.

Update: from the data I am seeing, it looks like HA slightly over estimates the daily amounts compared to the inverter with the gap growing through the day. My guess is that this comes from HA getting samples of the power values and performing Riemann sums to arrive at the daily totals where, hopefully, the inverter is better at doing the integration? Just need to decide at some point whether I replace the HA values with the inverter values for tracking energy and calculating inverter efficiency...