That’s strange. What device do you use for the Modbus communication? I initially tried with SolaX own dongle (to which you can communicate Modbus TCP) but after a couple of days with more grey hair than before I gave up and bought a Modbus TCP to RTU converter instead which works much better.
Also, another thought, could it be related to firmware version? I think the VPP stuff is quite newly introduced, so if the firmware version is very old is might not have support for it. Not sure which version would be adequate though, I’m at 1.55/1.51 here.
Its an X3-Ultra. Dunno the firmware (as said I don’t own the device). Will ask but it’s brand new install so I guess up to date. And without asking SolaX themselves probably not of much use.
Have a look at section 2.2 and also read 2.3.1 of the VPP document.
That reads as if we have to set all those registers in a single write operation?
EDIT: I didn’t pay attention you had the writeMultipleEvenWithSingleRegisterOrCoil option set. I added that and made some progress. At least the mode is accepted now and can be read back via readback reg. 256.
Still that does not seem to affect the battery charge power.
Have you set values for every reg 124-138?
0x007C~0x008A is the index of Remote Control (VPP function) multi write control (function code 0x10). When using it, please select the corresponding parameter to fill and write according to the required mode. For mode 1-7, depending on the current device mechanism, it is necessary to fill values for all registers in this mode. For mode 1-3, the registers that need to be filled with values are 0x007C~0x0088. For mode 4-7, the registers that need to be filled with values are 0x007C~0x008A.
PS: possibly unrelated, but I also I noticed that PushModePower is there twice, regs 89h = 137dec (part of the multi-write range) and again A4h = 164dec (not in that range). PowerControlMode is also 7C and A0. Also it’s unclear when to use the second one…
Nope, I’m just sending to the registers that I actually use. It was a bit unclear to me if it makes any difference in which order to write them, but I ended up first writing the parameters (for example the PushModePower) and directly after that actually changing the mode.
One thing to check is ask the end user if the (R) symbol appears on the device screen, which would mean that it at least has understood that it should be in remote control mode.
But actually, your problems sound a lot like what I was experiencing when talking Modbus TCP with SolaX network dongle, I don’t think I ever succeeded in changing remote control mode. It doesn’t say so anywhere, but maybe it’s simply only working when using Modbus on the com port?
About the two PushModePower I think they were simply stupid enough to name two different things exactly the same. I have only used 0x0089 which is the one for controlling mode 4, looks like the other one (0x00A4) is meant for mode 8 and 9, which I’ve never used.
I see the readback reg 256 is always set to the mode I give with reg 124.
Did that happen during your attempts with the dongle?
While I know this type of problem from my own inverter, I don’t believe it applies here.
When that happened, it was because the dongle did accept modbus/502 but could not map it to the internal modbus so did properly reply in thd first place with a(modbus) address not found or (modbus) timeout.
But with being able to set the mode this way and even the charge power command succeeding in terms of modbus protocol, I think that would not work if the cause was that bad external to internal mapping.
Actually, I don’t know. I think I gave up on that dongle before I discovered the VPP guide, so I suspect I didn’t try any of those registers using that.
I guess you’ve tried both positive and negative values for the power? And also tried values below 255 (thinking the bytes are somehow swapped wrongly)… Maybe try some vpp mode that nees no arguments at all? I use mode 7 for when I plug my EV charger, to prevent it from draining my house battery.
In response to our support call, Solax has updated the box to latest firmware.
Partial success!
Still testing but premilinary results are that I do can force-charge the battery. Discharge, too.
However, the resulting changes in power value seem to constantly be only a fraction of what they should be because I tell it to, maybe 40% or so.
So e.g. if I tell to charge 1 kW and then 2kW, battery on 2nd command charged by 400 W or so more than after first command. A little strange.
Does that behavior sound somehow familiar to you?
Push mode 4 gets set and can be read back on the other register, PushModePower can be set and read back.
My first thought: Are you sure you got the order of the bytes right? My push mode power thing is int32_swap, I guess values would be something like you’re describing if it instead was set to int32?
I’ll attempt an A/B test with swapped bytes but I don’t believe in this.
Swapped bytes always result in vastly different values, not as reasonably close as what I see to what I expect to.
Yes, you’re right… No, then I don’t really know, looks like you’ve hit some new problem that I’ve never had. Setting it to 2222 really should discharge the battery with 2222 watts.
And it is a Number item, right? So it’s not a String getting interpreted in some weird way…
