Quick question about the BMS Watthours sensor;

[Daibutt]

          Quick question about the BMS Watthours sensor;

Should this be the same as the kWh (x1000) value that is available in the Foxcloud data report?
If so then I think I have a problem;
Foxcloud reports my throughput as roughly 9947kWh or 9,947,000 Wh.
The sensor I am pullling in from register 11049 is giving me odd values in HA;

It peaked at 32,731 then dropped to -32749 (more or less 2^15 to -2^15) so is this a stack overflow issue?

In modbus config for this sensor I tried adding data_type: xxxxx (int16, int32, int64, uint16, uint32, uint64) but none of these worked either!

Originally posted by @Daibutt in #92 (comment)

[rand12345]

It’s a 32-bit value and the config needs updating.

I’ll put in a PR this evening.

[Daibutt]

Thanks 👍

[rand12345]

Just to note, I have to make some assumptions here about the values.

It would help if someone could implement this on their HA and report back. These two uint16 values can then be turned into a uint32.

    - name: "BMS Watthours Total high16"
      address: 11048
      scan_interval: 60
      slave: 247
      input_type: input
      unit_of_measurement: "Ah"
      device_class: power

    - name: "BMS Watthours Total low16"
      address: 11049
      scan_interval: 60
      slave: 247
      input_type: input
      unit_of_measurement: "Ah"
      device_class: power

[Daibutt]

I'll give this a go now. Will let you know what happens.

[Daibutt]

OK, so I get this;

Foxcloud gives my throughput currently as 9983.055 (kWh I assume? that would make sense for my typical throughput and length of service).
I notice you have Ah for these values. Should this be Ah or Wh?
If it's Ah do I then multiply by my nominal battery voltage (410 - 430 ish) to get Wh?
Apols for all the questions.

[rand12345]

Based on those values (0x00EC544F) that should be 15,488,079

Have a play with that and I'll check back in later.

[Daibutt]

OK. So my (Foxcloud) total throughput was 9983055 or 0x0098544F, so it looks like the low bytes are correct, but hi bytes (236 or 0x00EC) are not.
Not really sure this is correct approach but for 0x0098 I would need 152 (dec).
I tried modpoll from 11000 to 11080 odd and couldn't find a register with 152.

[StealthChesnut]

If you're reading a 32bit value across 2 sensors then is HA getting it right?

If you use data_type: unit32 then HA's modbus implementation should calculate the register count correctly, but perhaps it isn't?

This is working for me in that it's not throwing an error, and it appears to have read a value on restarting HA, but can someone else try this:
- name: "BMS Watthours Total"
address: 11048
scan_interval: 60
slave: 247
data_type: uint32
count: 2
input_type: input
unit_of_measurement: "Ah"
device_class: power

[rand12345]

Hey @StealthChesnut

I'm looking at raw can logs to decipher this register. What I see is an energy counter, uint32 little endian.

The specific can frame shows [.., 0x79, 0x43, 0x00, 0x00, ..] = 17273, and that rising in line with energy in and out of the BMS over time.

This value may reset at midnight, or some arbitrary time. I noticed that the can logs I have show this decoded value starting at exactly 10,000Wh which seems a little suspect for a lifetime counter. That probably means a name and unit (Ah ->Wh) change is in order once confirmed.

[Daibutt]

Hi Chris, I just tried uint32 count: 2, I do get a value from this sensor which is pretty much the same as @rand12345 calculated earlier from the hi/lo byte sum;

The value is increasing too at what seems like a sensible rate (based on short period it's been running)

But is not really close to what Foxcloud data report shows (9.9 e6 Wh)

[rand12345]

Not particularly happy with this sensor, there appears to be some sort of arbitrary offset which I can't test for. Might be better to yank it @StealthChesnut

[Daibutt]

I'm not really 'au fait' with hex conversions and that sort of stuff, but with your comment about there being an offset I made a template sensor to subtract the 84 (dec) (00EC-0098 hex) I was missing from the hi 16 part. 84*16^4= 5,505,024. Sort of brute force stuff ....
- name: "BMS throughput kWh"
unit_of_measurement: "kWh"
device_class: energy
state: "{{ ((states('sensor.bms_watthours_total') | float(default=0) - 5505024) / 1000) | round(3) }}"

Comparing with Foxcloud data it looks OK so far, but we will see....!

Will take a look tomorrow and update on the comparative values.

[Daibutt]

Still looking good this morning;

I guess one concern is why the 84 offset (in my case) in the 16bit word at 11048? Is this particular to my setup and will others have different offsets? Will the offset change in the future?

[Daibutt]

OK so now I'm confusing myself even more....!
Tried modpoll again around 11048 and spotted that 11048 happens to be exactly the same as my battery cycles from the Foxcloud report.... coincidence?!

[rand12345]

Probably not a coincidence given it’s a 1 in 65335 chance! Submit that sensor as a PR.

[StealthChesnut]

@rand12345 @Daibutt

Is the outcome that the bms watt hours sensor needs to come out for now, and x48 go in as battery cycles?

[Daibutt]

@StealthChesnut @rand12345 I'm not 100% sure! 48 does look like cycle count, but I can also get throughput to match up by taking the 32 bit 48+49 and subtracting 84*16^4.... confused.
Also, sorry guys I'm not sure how to do a PR.

[StealthChesnut]

ok - lets see what happens over the next day or two with these, see if we can work out what they are for definite before making more changes.

[Daibutt]

OK, quick update.
So reading x48+49 was working OK for throughput with the "84" * 16^4 offset until my battery cycles increased from 236>237.
Then it was 65536 too high, i.e. 1*16^4 so I don't think x48 is helping with throughput but looks like it is def bat cycles.

So if the x49 register is giving me the "tail end" of my throughput value I guesss I need to find another register to make up the front end?
Currently x49 is reading -5376 (hex signed 2 EB00) which if i put x0098 in front of I get my throughput value pretty much spot on (x0098EB00 = 10021632 and throughput is ~ 10,021.something) But why lol?

[Daibutt]

Hmmm, this is strange.
I left my throughput sensor template as was (x48+x49 minus an offset of 84x16^4) even though it WAS reading 65536 too high after my cycles went from 236 to 237.

However, this morning throughput is reading spot on again (!?) even though cycles are at 237 still, after it took a step change back down of 65536;

Rather than keep bunging up this thread with more random screenshots (!), I'll set up HA with a load of other registers and spend some time seeing if I can spot which one(s) may be impacting this number.

[StealthChesnut]

Rather than keep bunging up this thread with more random screenshots

Please never think they're unwelcome! Sharing your datapoints gives extra info to anyone else looking at this, and saves us all duplicating work. Keep the info coming!

[TonyM1958]

No data to support this, but looking at some other 32 bit values, they seem to be in pairs but skipping one address each time, as I understand it?

So, is BMS KwH Total something like 11047 + 11049 with BMS Cycle Count in the middle at 11048?

Kind of like Battery Charge Today at 11074 with Battery Charge Total at 11073 and 11075?

[canton7]

@FozzieUK has done a bunch of work on this sensor: nathanmarlor/foxess_modbus#110

[TonyM1958]

Thanks @canton7, good info. I think this is now taken forward in #112

[canton7]

Kind of like Battery Charge Today at 11074 with Battery Charge Total at 11073 and 11075?

Battery charge total is at 11073 and 11072? Battery Discharge Total is at 11076 and 11075, and battery_charge_today at 11074.

[TonyM1958]

This thread got a bit out of date, there's more discussion and example code in #112 and explanation of what Input Energy Total / Today seems to be. Here's the latest spreadsheet with the entity data I try to keep up to date. H1 modbus map.xlsx

I've also backed up my current running code with these counters working here: https://github.com/TonyM1958/HA-FoxESS-Modbus. You are welcome to take anything from there that's useful.