Update KH registers

[canton7]

We have the modbus spec now:

Fault codes, min/max doc, max charge/discharge current we don't map the holding registers for.

[lamixer]

Hello! I'm another KH owner and I have just (foolishly) updated my inverter firmware to manager 1.19 and the modbus integration stopped working. I updated to the latest beta (10b6) but this has not changed anything. I still have all entities blank in HA. Let me know if you need any help with probing registers or testing a fix.

[FozzieUK]

@lamixer try dropping back to 10.0b3

[lamixer]

Thanks FozzieUK, but I still get nothing on that version.

[FozzieUK]

Ok, I can see you're getting guidance over on FB - i'll leave it to Antony & Will 👍

[williamjeccles]

@canton7 / @FozzieUK I'm not sure about all the changes made to master recently but to restore my K series to working with home assistant I had to downgrade to 1.9.0 again, then manually apply the changes in this PR https://github.com/nathanmarlor/foxess_modbus/pull/512 downgrading to 10.0b3 didn't work for me.

[FozzieUK]

@williamjeccles Thanks Will, i'd been loosely following the KH changes and it looked like they were wrapped into the 10.0b3 link but it's obviously more complex than that 😊, i'll leave it to you guys 👍

[lamixer]

Hello ... I'm probably not adding anything new to the conversation now, but after having my KH10.5 inverter updated to Manager 1.19 (etc) and losing all modbus entities, I have 'fixed' the problem with @williamjeccles help (Thank you!) by reverting to v1.90 of the integration and then manually modifying my installed version of inverter_profiles.py and entity_descriptions.py.

I did not regain all of the entities, but most of them came back. The two I need to get my Sunsynk Flow card fully working again are EPS Power (FoxESS) and Load Power (FoxESS).

I wonder if we should make a separate beta branch of the code to sort this out, or just carry on with the current beta sequence. I haven't read all of the comments but it seems something about the work to enable the new force charge capability has made it so these changes (from PR 512) which I merged in to 1.90 do not work in the 1.10b6 release.

[lamixer]

Oh, and besides the entites not working, 'battery charge total' is high by a factor of aprox 1000. Battery Discharge Total looks like it could be correct though.

Just to be thorough, the entties I don't have include: (the below show 0) Inverter Power EPS Power Battery Charge Feed In (might be zero correctly for today so not sure) Grid Consumption Grid CT

(the below show Unavailable) Battery Current Battery Voltage a bunch of BMS entries All Period 1 and Period 2 entries

[canton7]

wonder if we should make a separate beta branch of the code to sort this out, or just carry on with the current beta sequence. I haven't read all of the comments but it seems something about the work to enable the new force charge capability has made it so these changes (from PR 512) which I merged in to 1.90 do not work in the 1.10b6 release.

It's mainly that I've been working 12 hour days and haven't had a chance to finish up! Project delivery is tomorrow, so hopefully things get back to normal soon.

[lamixer]

No worries Antony. Your efforts are much appreciated and you can only do what you can do!

On 13 Feb 2024, at 22:03, Antony Male @.***> wrote:

It's mainly that I've been working 12 hour days and haven't had a chance to finish up! Project delivery is tomorrow, so hopefully things get back to normal soon.

[michalzxc]

I dont know how, but for me it is not 41XXX but all needs 31XXX

./modpoll  -m tcp -p 502 -a 247 -t 3 -0 -1 -c 16 -r 31008  10.0.0.253 
modpoll 3.10 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright (c) 2002-2021 proconX Pty Ltd
Visit https://www.modbusdriver.com for Modbus libraries and tools.

Protocol configuration: MODBUS/TCP, FC4
Slave configuration...: address = 247, start reference = 31008 (PDU), count = 16
Communication.........: 10.0.0.253, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, input register table

-- Polling slave...
[31008]: 0
[31009]: 5009
[31010]: 2494
[31011]: 9
[31012]: 0
[31013]: 4864
[31014]: 0
[31015]: 0
[31016]: 0
[31017]: 0
[31018]: 0
[31019]: 0
[31020]: 0
[31021]: 0
[31022]: 0
[31023]: 0

I have KH10.5 inverter 1.19 manager, 1.27 master

./modpoll  -m tcp -p 502 -a 247 -t 3 -0 -1 -c 16 -r 41008  10.0.0.253 
-- Polling slave...
Invalid frame error!

[canton7]

I know what needs to be done, don't worry. You don't need to do your own investigation.

[canton7]

Try v1.10.0b7, see if that improves anything.

I should have some time tomorrow to get this sorted.

[michalzxc]

🎉 Battery state is updating again! Thank you!!

[lamixer]

@williamjeccles Did you try the latest yet? I'm afraid to overwrite my hacked version that has most of the sensors working until I hear from you! Thanks.

[williamjeccles]

@canton7 / @lamixer v1.10.0b7 is working correctly for me I can also confirm that force discharge is working for me on b7. Still can't see any grid or feedin values, I assume you're still working on those?

[canton7]

@canton7 / @lamixer v1.10.0b7 is working correctly for me I can also confirm that force discharge is working for me on b7. Still can't see any grid or feedin values, I assume you're still working on those?

Those should be working. They moved the registers in the latest spec I've seen, but I fixed those in https://github.com/nathanmarlor/foxess_modbus/pull/535/files. I'll double check next time I'm at a computer.

[williamjeccles]

@canton7 sorry I can confirm grid and feeding have no values even on b7

[lamixer]

Hello ... thanks for the update. I installed v1.10.0b7 and it has improved the situation from v1.90 with manually-applied changes.

I'm sure this is a work in progress, but just reporting, from my above post noting missing entities I previously had, the lastest has changed the noted ones:

Just to be thorough, the entties I don't have include: (the below show 0) !! RESTORED -- Inverter Power !! RESTORED -- EPS Power Battery Charge Feed In (might be zero correctly for today so not sure) Grid Consumption !! RESTORED -- Grid CT but note, the +/- has swapped!

(the below show Unavailable) Battery Current Battery Voltage a bunch of BMS entries All Period 1 and Period 2 entries

Of course also still the "Charge Periods" setting card does not populate since the periods entities are missing.

Great step in the right direction, thank you!

[canton7]

Battery Charge

You don't mention Battery Discharge or Inverter Battery Power. Are those OK? (all 3 entities are driven by the same register).

Feed In (might be zero correctly for today so not sure) Grid Consumption !! RESTORED -- Grid CT but note, the +/- has swapped!

Those 3 values are also driven from the same register. If Grid CT has swapped sign though, that might explain it.

Can anyone else confirm whether Feed In / Grid Consumption are swapped?

Battery Current Battery Voltage a bunch of BMS entries

FoxESS removed a bunch of BMS registers. I'll check which exactly next time I'm at a computer.

All Period 1 and Period 2 entries

Those should still be there. Does HA sat that the integration had stopped providing them? Ant warnings in your log?

[lamixer]

sensor.foxess.battery.discharge looks good. sensor.foxess_invbatterypower looks good.

Actually, looking back at last night, I see sensor.foxess_battery_charge did register the overnight charging, so though I saw zero, it was a correct zero.

sensor.foxess_feed_in is showing zero but I am feeding in right now. sensor.foxess_grid_consumption is not working.

Regarding binary_sensor.foxess_time_period_1_enable_charge_from_grid and similar, I get the message "This entity is no longer being provided by the foxess_modbus integration. If the entity is no longer in use, delete it in settings."

Same for sensor.foxess_inverter_fault_code Same for sensor.foxess_bat_current

Same for sensor.foxess_batvolt and other BMS entries like voltages, temperatures, cycle count. I don't mind deleting entities if I know they are not coming back any time soon. I'm just not sure which I should delete.

There is nothing related in the logs (from a quick glace anyway) and no 'repairs' are offered.

[canton7]

Right, I'm back and at a computer again!

Actually, looking back at last night, I see sensor.foxess_battery_charge did register the overnight charging, so though I saw zero, it was a correct zero.

:+1:

sensor.foxess_feed_in is showing zero but I am feeding in right now. sensor.foxess_grid_consumption is not working.

Ah yes, I have failed to map those, looking at it again. Will fix!

Regarding binary_sensor.foxess_time_period_1_enable_charge_from_grid and similar, I get the message "This entity is no longer being provided by the foxess_modbus integration. If the entity is no longer in use, delete it in settings."

They're not actually listed in the latest spec I have for the KH. Can you check whether they're readable?

Go to Developer Tools -> Services, and read 3 input registers with a start address of 41001:

[lamixer]

No response from those registers. Any other locations we think it might be?

[canton7]

Trying reading them as holding registers, just to be sure?

That's where they are for the H1, and where they used to be for the KH. I can't see them anywhere in the latest spec I have, and so far that spec's been accurate.

[lamixer]

I tried input and holding- no response from either.

I don’t mind going fishing. My setting for period 1 is force charge off, start time 23:30 end time 00:00 so what values should I look for and where do you suggest there is a contiguous set of registers it might be? Should I try input or holding when I poke it?

[canton7]

They'll be holding registers most likely. 23:30 is 5918. Make sure the charge period is actually enabled.

I've only ever seen them at 41001-41006.

[lamixer]

Can I see the register documentation that you have for KH and K series to give me a clue where to look?

I have seen one before but it sounds like you have an updated one.

[canton7]

KH_KA系列储能逆变器Modbus协议 V1.01.00 2023070801 for EMS.pdf

[lamixer]

Thanks, that's a pretty nice document! Here's some probing:

31008 returns 0 31012 returns 0 31014-16 return 0 31054 returns 544 (this is aprox my house load right now) 31055-31059 no response 31060 - 31090 probing ten at a time produced no response (not sure best way to probe a big range) We have 31055 to 31999 as possible locations to find charge period registers. Ditto 32024 to 39999. 40006 returns 3 40007 returns 0 40008 returns 1 40009 returns 0 40010 returns 1 40011 rerturns 2 40012 returns 247 40013 returns 0 40014 - 40020 no response (read individually) 40100, 40200, 40300, 40400 no response 41001 - 41006 no response (read individually) 41012 returns 9000 41019 - 41030 no response (read individually) 42000 no response 43000 no response 44004 no response 44010 no repsonse 44100 no response 44200, 44300, 44400, 44500, 44600, 44700, 44800, 44900 no response 45005 no response.

Clearly, 40006 - 40013 could be interesting. For 40012 does 247 mean anything to you?

As noted, I only probed registers that were TBD or unmentioned in the document, so there are a few things showing up that may be not documented yet.

[lamixer]

9000 is my current (no pun intended) setting for Export Limited Power (range 0 - 30000) in W. Maybe 247 refers to the modbus address.

[canton7]

For 40012 does 247 mean anything to you?

Yep, Slave ID.

[lamixer]

Ok.. I reset the two charge periods to be both on and times in the 1am hour a few minutes apart. Now probing I get:

41014 = 1 41015 = 3 then no response going up a few more registers.

I can't find any other changes resulting from this.

I don't have any strategy periods (or whatever those are called now) set, maybe will try and see if that pops up any new registers.

Maybe @williamjeccles can enquire with FoxEss why they took away the working (but undocumented) charge period registers for KH in 1.19 manager!

[lamixer]

Setting something up in "mode scheduler" did not show up any new register data (that I could find anyway).

[canton7]

Yeah the mode scheduler isn't exposed over modbus currently (we know the "registers" it uses, there's a discussion on that, but they can't be read over modbus).

[lamixer]

@canton7 When you have a chance, can you please check sensor.foxess_battery_charge_total ? I think it's missing a k and I'm seeing watts instead of kWh. I'm not sure that explains it though, it seems it should be about the same as sensor.foxess_battery_discharge_total which is 2581.3 kWh whereas the charge total is showing 147,274,746.4 kWh.

[williamjeccles]

@lamixer I have already questioned the changes in 1.19 and they said it is what it is basically.

[lamixer]

Weird. I wonder why they don't support KH as well as H series (modbus anyway). Hopefully something good is coming down the pipeline (like full modbus control of Schedules / Strategy Periods. Would be great if there was an override the inverter would respond to (over modbus) that just says 'do this now' like charge at 10A or discharge to grid at 12A or stop doing either of those things and revert to stored settings. Then HA could easily trigger those things.

[canton7]

Would be great if there was an override the inverter would respond to (over modbus) that just says 'do this now' like charge at 10A or discharge to grid at 12A or stop doing either of those things and revert to stored settings. Then HA could easily trigger those things.

It does! That's what I implemented the new force charge / force discharge work modes on top of.

[lamixer]

What I great idea I had (YOU HAD -- LOL)! Is it supposed to work on KH series?

When I put it in Backup mode it (within a second or two) reverts to Self-Use. When I put it in either Force Charge or Force Discharge it starts discharging to the grid.

Whatever I can do to help it work on KH, please let me know. Maybe it has to do with the backward CT measurements and the other things you are working to fix for KH? (note, I have changed the polarity in my sunsynk flow card I use to monitor these things so I do know correctly which way the power is flowing to/from the grid. There's an invert grid sensor switch in that card.

[canton7]

Interesting. It works with the H1 and H3 currently. I wonder how the KH is different...

Can you enable debug logging, turn on force charge and force discharge, and send me the logs?

[canton7]

When you have a chance, can you please check sensor.foxess_battery_charge_total

Yep that was a bad definition thanks!

[canton7]

I'll release those fixes when we've figured out what's going on with the force charge / force discharge.

[lamixer]

I'm not sure how to change log levels. With my default settings, I get these results:

Self Use > Feed-In First May have worked (battery is at 95% so not sure)

Self Use > Backup Switched itself right back to Self Use

Self Use > Force Charge Stays set to FC but I see nothing change (my battery is 95% though)

Self Use > Force Discharge Works

No log entries in whatever default logging mode I'm in.

[canton7]

Switched itself right back to Self Use

I think I've identified that as a separate issue. Leave it for a poll period (10 seconds by default), and it should start showing the new work mode.

[canton7]

Use this button to enable debug logging:

[lamixer]

Thank you... Again then with dub logging on:

Self Use > Feed-In First May have worked (battery is at 95% so not sure) No log entries generated.

Self Use > Backup Switched itself right back to Self Use No log entries generated.

Self Use > Force Charge Begins to force discharge (battery was at 92%, I raised my Max SoC to 96% then it started discharging) No log entries generated.

Self Use > Force Discharge Begins to force discharge No log entries generated.

However, I then downloaded the full log file from HA and there are entries. Attached!

lamxer-21Feb2024.log

[lamixer]

I'm seeing mention of 12000 watts there. My inverter will do 10500 as per spec, though I have some limits set at 9000 I believe. Is it trying to do 12kW and failing?

[lamixer]

But when the force discharge was working there, it was respecting some setting I have somewhere of about 5kW.

[canton7]

That all seems to be fine. It's writing 53536 (-12000) to trigger a force charge. If the inverter actually starts to export at that point, I can only think that's a problem with the inverter. That's fun, more things to work around.

I'm seeing mention of 12000 watts there. My inverter will do 10500 as per spec, though I have some limits set at 9000 I believe. Is it trying to do 12kW and failing?

It shouldn't -- that's not how the other inverters work. (I can't actually tell the inverter capacity for the KH, so I have to default to the largest capacity).

But when the force discharge was working there, it was respecting some setting I have somewhere of about 5kW.

Yes, it'll be limited by the max discharge current, and your export limit.

[lamixer]

Ok...

The force charge is interesting, because it doens't start if the battery is already at the Max SoC. If I raise that setting then the inverter says, 'ok, I'll start charging then' except is actually DISCHARGES!

If you push a new beta with the other fixes maybe @williamjeccles and I can hop on that and double check things. Thanks!