Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add KH version 1.33 (thanks to @ocl80) #740

Merged
merged 3 commits into from
Jan 26, 2025

Conversation

canton7
Copy link
Collaborator

@canton7 canton7 commented Jan 22, 2025

Hi @ocl80,

Thanks for carrying the torch on the KH v1.33 while I got version selection sorted out.

I've done a squash-merge of your fork into this MR (with you as the author), then a couple of fixup commits on top to avoid breaking other inverter types. I hope that's OK. Can you just check that it looks sensible please?

Thanks!

@canton7 canton7 changed the title Add KH version 1.33 (thanks to @ocl80 Add KH version 1.33 (thanks to @ocl80) Jan 22, 2025
@ocl80
Copy link
Contributor

ocl80 commented Jan 22, 2025

Thanks @canton7 - for spotting I had failed to revert my earlier (crude) fix which included changing the pv current scale factor.
I had not understood how the post_process lambda function to switch the grid_ct polarity was applying only to the KH... now I see it wasn't and there was simply a negative scale factor that I had missed, and which is not needed now for KH133.
All good for me thank you!

@WyndStryke
Copy link

This is awesome, thank you both :-)

Any chance of getting the BMS cell low temp into KH133, if it isn't already? It seems to work when I read register 37618. I think that'd allow predbat to use the temperature charge curve functionality on the KH (although right now it still seems to be a bit buggy on the predbat side).

@canton7
Copy link
Collaborator Author

canton7 commented Jan 22, 2025

@ocl80 Thank you, and thanks for polishing the KH support! Yep, the snapshot tests came into their own there.

@WyndStryke That's #735 right? That needs a little update to support the version-selector stuff I got in today. I'll take a look on Sunday unless @FozzieUK gets there first.

@WyndStryke
Copy link

WyndStryke commented Jan 22, 2025

... That's #735 right? That needs a little update to support the version-selector stuff I got in today. I'll take a look on Sunday unless @FozzieUK gets there first.

Ah looks like the registers are the same, so yes (I had assumed they'd be different).

I'll go through and test each of them to confirm. This is on an EC4300-H4 (usable capacity 15kWh) and a KH7, manager 1.37, master 1.41, slave 1.01.

#712 (comment)

  • BMS1 MaxTemp 37617 147
  • BMS1 MinTemp 37618 105 (Fox app 10.5)
  • BMS1 MaxCellVolts 37619 32 (not sure how to check this, SoC is 63%, 37609 BMS1 voltage is 2352)
  • BMS1 MinCellVolts 37620 32
  • BMS1 SOH 37624 100 (fox app 100%)
  • BMS1 RemainEnergy 37632 1658 (nominal capacity 16590Wh)
  • BMS1 FCC Capacity 37633 0
  • BMS1 DesignEnergy 37635 0

So the last two don't seem to be populated.

Could 'FCC Capacity' be related to 'Number of full equivalent charge-discharge cycles' in the fox app?

I didn't get anything from the last 2, but the others look plausible.

A few other random observations while I was poking around with registers:

  • 49203 work mode - returns 1 which is self-use (& what I have set during the day). What I've noticed is that this doesn't change in the integration despite swapping to force charge overnight on the inverter via the mode scheduler. I'll have to re-query this overnight to see if it picks up the force charge. Looking at the source I'm not sure where it is coming from at the moment for the KH133 profile.
  • 49222 (6) Year / month / day / hour / minute / second 2025/1/22/22/27/33 Perhaps could be used to detect if the inverter time is drifting. I notice it seems to be a minute fast ...
  • 49079 Grid standard code 3 (G99_UK). Just in case anybody forgets where in the world they live.

--- Edit: 49203 (work mode) does not update when force charging is active, it stays at 1 (I was expecting 6 for force-charge). Interestingly the Fox app also shows self-use despite also showing the battery being charged from grid (via the mode scheduler). So I'm not sure what's going on there, maybe a firmware bug reporting the wrong workmode, or perhaps it's actually a write-only field? Is there another way to retrieve the workmode?

@williamjeccles
Copy link
Collaborator

--- Edit: 49203 (work mode) does not update when force charging is active, it stays at 1 (I was expecting 6 for force-charge). Interestingly the Fox app also shows self-use despite also showing the battery being charged from grid (via the mode scheduler). So I'm not sure what's going on there, maybe a firmware bug reporting the wrong workmode, or perhaps it's actually a write-only field? Is there another way to retrieve the workmode?

I believe I came across the force charge issue, the reason for it and a solution here #661

@WyndStryke
Copy link

Just ploughing through that thread, thank you :-) It's going to take a while because it's a bit beyond my current knowledge.

I had seen it a while ago, but I had assumed it just related to parallel setups and ignored it.

Regarding

As I recall there may be a problem with reading the Remote Take effect register as the KH did not expose registers above 44003 - it would be useful to know if this is still the case and needs to be re-checked on a KH

I seem to be able to read registers such as 49222, 49079 OK (KH > 1.33)

Regarding reading the current work mode via 49203, I guess that firstly the mode scheduler doesn't use that mechanism, and instead uses remote control? So presumably I'd need to read the 44xxx registers instead to see if the inverter had remote control turned on, and what it had been asked to do?

Right now, with self-use active, they read:

  • 44000 1
  • 44001 900
  • 44002 0

Which does actually correspond with the final force charge segment in my schedule (6:45-6:59, 10% min soc, 80% max soc) which is basically there just to hold the charge steady in case of time drift. I don't have any force discharges configured because I don't have an export MPAN / MCS yet (still in the paperwork stage).

@FozzieUK
Copy link
Contributor

I'll go through and test each of them to confirm. This is on an EC4300-H4 (usable capacity 15kWh) and a KH7, manager 1.37, master 1.41, slave 1.01.

  • BMS1 MaxTemp 37617 147
  • BMS1 MinTemp 37618 105 (Fox app 10.5)
  • BMS1 MaxCellVolts 37619 32 (not sure how to check this, SoC is 63%, 37609 BMS1 voltage is 2352)
  • BMS1 MinCellVolts 37620 32
  • BMS1 SOH 37624 100 (fox app 100%)
  • BMS1 RemainEnergy 37632 1658 (nominal capacity 16590Wh)
  • BMS1 FCC Capacity 37633 0
  • BMS1 DesignEnergy 37635 0

Ok thanks, those bms temp and cell registers are all working as per the latest modbus spec - I'll look at modifying my PR for the G2 and add KH BMS support.

Could 'FCC Capacity' be related to 'Number of full equivalent charge-discharge cycles' in the fox app?

These don't seem to be populated yet in any tests we've done, it appears to be future development scope.

A few other random observations while I was poking around with registers:

  • 49203 work mode - returns 1 which is self-use (& what I have set during the day). What I've noticed is that this doesn't change in the integration despite swapping to force charge overnight on the inverter via the mode scheduler. I'll have to re-query this overnight to see if it picks up the force charge. Looking at the source I'm not sure where it is coming from at the moment for the KH133 profile.
    --- Edit: 49203 (work mode) does not update when force charging is active, it stays at 1 (I was expecting 6 for force-charge). Interestingly the Fox app also shows self-use despite also showing the battery being charged from grid (via the mode scheduler). So I'm not sure what's going on there, maybe a firmware bug reporting the wrong workmode, or perhaps it's actually a write-only field? Is there another way to retrieve the workmode?

You won't see the inverters work mode register change when you force charge (or discharge) - these modes are created internally by the integration using the remote power registers (the inverter work mode is unchanged and will be in whatever work mode it was left in)

If you want to know the integration work mode you will have to test the state of select.work_mode which will report the text Self Use, Feed-in First, Backup, Force Discharge, Force Charge etc..

@WyndStryke
Copy link

You won't see the inverters work mode register change when you force charge (or discharge) - these modes are created internally by the integration using the remote power registers (the inverter work mode is unchanged and will be in whatever work mode it was left in)

I'm not yet at the stage of controlling the inverter yet, currently I'm still figuring things out, getting everything ready, and predbat is in read-only mode, storing the load data. Once I'm allowed to export, then I'll be looking to enable the control side of things (hopefully soon, the MCS came through today so I've just requested the MPAN).

The force-charge I mentioned earlier was commanded by the Fox app, not the integration. Originally I thought that the inverter's work mode status would pick it up. But the app is using the remote control registers too, hence presumably to know what the inverter is doing while the app is controlling it, I'd need to be watching those registers.

However, given that the plan is for predbat to be doing the work once export is enabled, that's not actually what I should be focussing on. It's force charging and discharging via Will's automations that will be needed, and also I need to figure out how to wire that into predbat.

@canton7
Copy link
Collaborator Author

canton7 commented Jan 24, 2025

This PR is going to be closed shortly. Please don't use it for general conversation: that will be lost. I suggest an issue / discussion instead!

@canton7 canton7 merged commit 094fcfe into nathanmarlor:main Jan 26, 2025
3 checks passed
@canton7 canton7 deleted the feature/new-kh branch January 26, 2025 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants