K series manager 1.33 upgrade breaks integration #678
Comments
williamjeccles
changed the title
|
So @TonyM1958 confirmed that address 31039 is PV3 voltage, moving a solar string over to pv3 and I can confirm that the address is showing 0v in home assistant using tony's project so assume this manager update has broken pv3 in someway. |
|
Currently, the following are failing to respond and blocking the integration from loading cleanly. Broken left / working right rpower EPSpower Gridct ct2 loadpower With these addresses commented out the integration loads. |
|
Ok so Tony pointed me to a new v2 address register, I've tested out the new address on the pv3 voltage address which is the first failing address and it's working. I'm going to test out updating them each with the new values but it looks like more of an improvement to the address consistency than bugs introduced at this stage.
|
|
Yay, I hate it when they break things. Looks like they're bringing it into line with the H3 Pro perhaps? That's the other inverter which uses 39074. I think we're going to need to start selecting which registers to use based on the firmware version... We can't just keep breaking all KH users because one person upgrades. I'll try and find some time to implement something. |
|
thanks @canton7, do you want me to commit a PR so we can offer a beta version for those who have upgraded while you work on a switch of some kind? |
|
Sure, if you've got the time to update the register map, that would be helpful! Can you do what we did for the KH, and at least keep the old register map around? (For the KH, we did that as |
|
@canton7 versions are completely messed up also :(
I feel like this is going to need proper reengineering, maybe a switch in the config wizard or maybe we only support the latest firmware? |
|
🤦 |
|
Looks like the encoding of the versions has changed, it seems unlikely they got this wrong? Previously, they have used decimal and then hex encoding. Don't think they expected to get to version 2.55. You may need to write out the values you read in binary to see if you can make any sense it. |
|
Re the version... We're currently interpreting this as hex, which seems to be the "new" standard. That means that "31.31" is 0x3131. I can't work out any way in which that maps onto "1.33".... It seems more likely to me that they've gone and moved the version registers, particularly if they're moving to parity with the H3 Pro. @williamjeccles can you check registers:
please? |
|
ah OK. I just assumed you would have already tried that... may be not. There are other examples of versions in Modbus v2 as well, such as Protocol Version Code that is 32-bit hex byte encoded. |
|
I've started having a crack at the KH-1.33 support. See #681. I haven't put in anything which the spec says has 3 phases, as I'm not sure what the inverter reports there. @williamjeccles if you could have a poke around that would be great! I also haven't decided how best to not break everyone who's on an older KH firmware version. They've gone and moved the version registers, which is very annoying. |
|
FoxESS Modbus Protocol--20240516 (V1.05.00.00)(1).pdf @canton7 new modbus spec as I've been blessed to share it. I'll test those changes and report back |
|
So good news is that the integration loads when using commit #681, but fews things we need to fix. As you can see from the attached, grid CT even when putting grid load on is showing 0 |
|
Cool! Yep, as I said, I haven't put in anything which the latest spec says has 3 phases, as the KH is only single phase. If you can figure out how ids actually exposing that data (just using the R phase etc), I'll put them in. |
|
Could you also check the versions? The spec also claims to support force charge /discharge work modes natively, so I've enabled them and haven't enabled the remote control stuff - mins testing? |
|
@canton7 any chance you push to a beta branch so I can easily import via hac instead of having to pull the commit? |
Definitely worth testing those work modes before you commit any changes. I don't expect writing Force Discharge to work without other parameters to set fdPwr and fdSoc and time, similarly Force Charge without a time limit does not make sense. I think Fox may have added work modes that are read-only to reflect what is going on in schedules? In schedule mode, the work mode Modbus register is read-only and I think that is when you might see these new work modes being shown? |
|
I also have access to the old 1.31 so I can switch between 1.31 and 1.33 with ease. |
|
@canton7 so using that commit, the biggest issues right now that I think we need to fix is the grid ct isn't working for me. I believe the address should be 39168. If you can update that and I'll pull the change and try it out again. |
|
@williamjeccles As soon as you can have a play with modpoll and let me know what the KH exposes on the R/S/T phase registers (i.e. what register of those 3 (if any) actually contains the information we need), I can get that in |
|
@canton7 so if i've understood the ask correctly I've tested out the following: Meter1/CT1 RPhase Active Power address: 38816 appears to be the ct1 negative number for export, positive for import Meter1/CT1 SPhase Active Power address: 38818 - appears to respond but with no data Meter1/CT1 TPhase Active Power address: 38820 - appears to respond but with no data I hope that helps resolve the K series grid related registers in the next release. |
|
@williamjeccles not sure if you have looked at this, but i'm intrigued to know if the BMS registers that went missing after the 1.19 update may actually have been moved to meet the new modbus spec Could you have a poke around at these addresses and see if you get a response please - particularly the items 24 - 32 & 39, 40, 42 on this list
|
|
Looks like it @FozzieUK - 37632 is giving me data. Going to check them all and report back |
|
Yeh so mV high low, Cell temps high low, remaining kWh all working. I think it's safe to say they've moved and are all working. |
|
Thanks, that’s great - be nice to have them working again 👍 |
|
@FozzieUK are you able to push a fix for the grid side stuff and these extra battery addresses? |
|
Thanks! I'll get those in when I get the chance (I'm afraid I'm a bit swamped until the middle of next week). I'm keen not to release this until we have a way to switch between H3 Pro versions (either automatically or manually), as I don't want an update to just break our existing H3 Pro users. |
|
No problem - I'll leave it to Antony - he'll be much quicker when he gets to it 👍 (also in the middle of fixing Nathan's EM which has stopped working on 2024.10.x) |
Thanks |
|
Hi, any guidance on how to get a KH10 working again with fw Master:1.35? |
I've a brand new V2 battery and get 100(%) at the SOH address, so looks correct. |
thanks for confirming |
|
Hi, I'm new here.. but just had a KH8 inverter installed, which has firmware Master: 1.39, Slave: 1.01, Manager: 1.35, and I encountered this issue where the integration wouldn't load. To get it up and running, I forked it here, with some "quick fixes" of the addresses which have moved. I haven't fully understood how the model and version identification is working, so this very much a quick and dirty fix, but it seems to be working for me, so thought I would share here. |
|
@rand12345 I think @williamjeccles has also done a lot of work on this as well to merge. The biggest challenge is not to break the integration with earlier releases of firmware before 1.33 and @canton7 has already started work on that. |
KH inverters upgraded to manager 1.33 and now seeing the following error in HA:
Error connecting to inverter (friendly name: "KHM"). Error reading registers. Type: RegisterType.HOLDING; start: 31039; count: 10; slave: 247 from tcp://192.168.1.164:502: Exception Response(131, 3, IllegalAddress)
The text was updated successfully, but these errors were encountered: