Deye Weird Voltage Behavior When Time Of Use is Enabled

[widget4145]

Hi, I wish this topic finds you well.

I wonder if anyone observing this issue.

It seems that Deye doesn't respect the voltage parameters set from BMS nor the inverter itself (voltage mode).

For example:
Absorption or RCV in the case BMS comms:
55.2V

Actual Given By the Inverter:
54.7V

It seems obvious there is a negative offset of around 0.5v.

So here the variable that this issue is happening:

When grid is connected, there is solar, Time of Use is enabled:
This issue is existent. It always offset around negative 0.5v.

When grid is connected, there is solar, Time of Use is disabled:
This issue is non-existent, be it grid charge is enabled or disabled. Parameters are respected, be it RCV from BMS or in the case of voltage mode Absorption Voltage / Float Voltage. Not perfect, still has 0.1v offset, but atleast...

When grid is disconnected, there is solar, Time of Use is either enabled or disabled:
This one is interesting. As long as there is no grid connected, and only solar is available for charging, parameters are respected. So I assume, the firmware silently disables the TOU, I mean it makes sense, how can it respect TOU when there is no grid? Not perfect, still has 0.1v offset, but atleast...

So in summary, the issue seems related to TOU being enabled.

Why is this important?

Well, this is very important. When I ask for 55.2V, then give me 55.2V, why would you give me 54.7v when TOU is enabled and give me 55.2V when there is no grid or TOU is disabled?

It doesnt make any sense. It will just complicate our BMS parameters and balancing logic, and potentially health of the cells.

Bandaid solution? Well, increase the request voltage to offset the 0.5V. However, this is unhealthy in the long run. What if there is a loadshedding? Then I'm overshoot of +0.5v which is unhealthy for the cells.

I'm trying to talk this out with Deye, but the language barrier and they seems to ignore the issue and claim it's normal, and as always, the insinuation of it's always the user's fault.

I read another topic regarding this voltage issue, and this issue seems not isolated. I'm just curious why it seems this issue does not get enough traction for Deye to finally fix this. This should affect all Deye OEM such as Sol-Ark, Sunsynk, and the like.

This is not normal. I requested 55.2V, give me 55.2V, not just when offgrid mode or when TOU is disabled, but all the time. This is not happening on other systems such as Victron and others. This is just a firmware issue, and can be easily fixed thru firmware.

Maybe this is another variable:
Firmware Version: 5kW - 3386 / C36C

 

[DougfromdaUP]

My SolArk is wrong with no grid connected, so the symptoms are a little different, but I share your frustration.

 

[widget4145]

My SolArk is wrong with no grid connected, so the symptoms are a little different, but I share your frustration.

Oh, I guess firmware versions are at play here.

Are you on the latest?

My 5kW is on the latest 3386 / C36C.

 

[Sleeper85]

According to my analysis, except with Lithium mode and BMS communication.
Here's what's going on with Deye.

Charging voltage is Bulk or Float - 0.5V if you do not request 100% charging.

 

[widget4145]

According to my analysis, except with Lithium mode and BMS communication.
Here's what's going on with Deye.

Charging voltage is Bulk or Float - 0.5V if you do not request 100% charging.

View attachment 203104

View attachment 203105

Thanks for the clear graph.

Pardon me, I'm just a little bit confused with your wording. You said "except with lithium mode and bms communication" but then you said -0.5V if you dont request 100% charging.

I guess its not possible to request 100% with voltage mode in TOU if your float voltage setting is less than absorption voltage? Your max request voltage in TOU will depend on float voltage setting, well in the case of setting it via LCD, you can't override it. However, I guess this can be overriden in solarassistant?

I already tried this before in Lithium Mode (no float mode bms / pace bms). TOU request is 100%, still -0.5V offset, unless I disable TOU, the same with voltage mode, the offset is -0.1V.

 

[Sleeper85]

This 0.5V offset occurs only if you choose V or % battery mode (so lead). But if in your TOU schedule you request a 100% charge during a time slot like 12:00 to 16:00 then the Bulk or Float charging voltage will be respected.

In Lithium mode the voltage requested by the BMS (jk-bms-can project) is well respected for me.

That said, I still notice a small shift of 0.1V. Which I corrected with an inverter_offset_v option as you could see.

 

[widget4145]

This 0.5V offset occurs only if you choose V or % battery mode (so lead). But if in your TOU schedule you request a 100% charge during a time slot like 12:00 to 16:00 then the Bulk or Float charging voltage will be respected.

In Lithium mode the voltage requested by the BMS (jk-bms-can project) is well respected for me.

That said, I still notice a small shift of 0.1V. Which I corrected with an inverter_offset_v option as you could see.

Thanks for clarifying. So see, I tried to set the mode to % as you said setting it to 100% in TOU eliminates this problem, I can see it was set below 100%, then I set it back to V mode since I prefer it this way, % mode is very inaccurate and unreliable. So back to V mode, there is no way you can set higher than the Float Voltage settings in TOU. So I'll update later if the setting to 100% improved the problem. I'll also test % mode to see it there is any difference.

I'll also check the Lithium mode later and set 100% in TOU if this will also improve as per your variables. Because I remember in my case, pace bms, the battery info shows it is requesting 57.6v but only 57.2v is effective. Let me see today which is which. Almost full now.

Edit:
Update. Seems unlucky. All the same. Even if I set TOU to 100%, still -0.5V offset, be it voltage or % mode or lithium mode.

In lithium mode, at 100% TOU, when grid charge is enabled in battery settings and grid charge is checked in TOU, it does respect the voltage settings, however, this is counterintuitive. Pace BMS by the way. But I guess this doesn't matter. I can clearly see the requested voltage vs effective voltage, it really has -0.5V. This is frustrating.

Anything else is the same as original post.

I dont like to compensate via BMS nor inverter voltage settings. Because when grid is down, I'm overshoot of +0.5v, which is I'm not comfortable with.

If you would be so kind, can you share your TOU, battery settings screen please? Only if you are free to do so. Thank you.

 

[Sleeper85]

Unfortunately I'm away from home for a very long period (3 months). I only have access to my Deye from Solar Assistant.

I'm in Lithium 00 mode with the PYLON 1.2 protocol.
My TOU is set to 90% during the day and I no longer have this 0.5V offset problem with Lithium mode.

It is clear that you should not compensate by 0.5V.

 

[widget4145]

Unfortunately I'm away from home for a very long period (3 months). I only have access to my Deye from Solar Assistant.

I'm in Lithium 00 mode with the PYLON 1.2 protocol. My TOU is set to 90% during the day and I no longer have this 0.5V offset problem with Lithium mode.

It is clear that you should not compensate by 0.5V.

Understood. No problem.

Thank you for helping.

I'm just hoping this wont mess up my incoming JK Inverter BMS. Imagine the mess when JK BMS is requesting 55.2V but Deye just gives 54.7V, how can JK BMS reach my balance target then proceed to float mode if it never hits Absorption stage?

But since you said that your protocol is Pylon V1.2 (I believe PaceBMS as well? Im not sure) and I can see that the JK Inverter BMS has it, just hope I'll get the same result as yours, but I recall we still have 0.1V offset, still an issue nonetheless.



Thats why I'm hoping for your future development for this particular BMS, because your project has an outstanding logic that every bms should implement, I mean it's already 2024 and we are still stuck with BMSs floating LiFePO4 at charging voltage, jeez... And the offset setting in your project is very useful in Deye's case.

Why do we always have to do this right ourselves?

 

[Sleeper85]

Correction !

If TOU<100% the charging voltage requested via CAN bus will be reduced by 0.5V, therefore the same behavior as in % mode (lead acid).

TOU must be = 100% to charge with the full charge voltage.

 

[widget4145]

Correction !

If TOU<100% the charging voltage requested via CAN bus will be reduced by 0.5V, therefore the same behavior as in % mode (lead acid).

TOU must be = 100% to charge with the full charge voltage.

Thank you for the update.

Unfortunately, this is not the case for me as I have updated my post previously. What firmware version are you? Im on the latest, as in just this month, 3386 / C36C.

No matter how I set the TOU to 100%, there is still 0.5V offset, be it via CAN bus (Lithium Mode) or % Mode (lead acid), and V Mode (lead acid).

I confirmed this awhile ago while there was still solar. Unless I disable TOU altogether, then no matter what mode it is, it then respects the charging parameters, no more offset... well... still there is 0.1V offset, but not 0.5V.

One thing that respects charging voltage for me even when TOU is enabled in Lithium Mode is when I set 100% TOU and check grid charge and enable grid charge in battery settings.

And they said to me that this behavior is normal. Sigh... So do they mean to say, disabling TOU or when offgrid mode is a dangerous feature then? Normal behavior is to offset 0.5V?

 

[Brightside]

I'm going from memory, but what you describe all sounds very familiar. As it depends on how your running the system. It would just be nice for it to do what you tell it to do. The manufacturer should be able to program it to work properly.

For me the 0.5V discrepancy only happens when grid is available, and PV power is in excess of loads. In this case the voltage will drive above the set point.

If I Grid sell all excess power so that PV does not exceed the load then setpoints and actual are correct.

It does not matter if TOU is enabled or not, I still have the issue, as TOU is used with the grid, and the grid tie seems to be where the issues comes from.

Battery BMS communications also do the same thing and drive 0.5V higer than setpoint.

FW does not matter, As I have FW from 2022 and upgraded to the latest this year. The problem was still there along with new ones, so I down graded back to the 2022 FW.

If I disconnect from the grid, the Actual and Setpoints are correct.

So it seems that the issue is a combination of PV input, loads, and grid. As long as the grid is off, or loads are in excess of PV input when Grid tied, Then actual and setpoints will be the same.

 

[widget4145]

Hmm. As the title says "weird".

Im very sure of my findings. But yeah, our issues have correlation nonetheless. The main issue is, there is that magic 0.5v offset be it above or below, and yes, seems related to being grid is connected. In my case, its very obvious TOU is affecting it. However, we have some common similarity, as long as there is no grid, everything is respected (well there is still 0.1V offset no matter what).

Our firmware might not be related but I can confidently say this can be fixed thru firmware. Im quite sure they have put some offset there, 0.5v seems the magic value and has been an issue since 2021 based on reading some old posts. As to why 0.5V offset, I dont know.

I just hope they'll finally fix this.

 

[DougfromdaUP]

Just to clarify, I have the problem whether I’m connected to the grid or not. It’s Never off as much as .5 volts, usually just .2 or .3

I updated the firmware yesterday, and saw no change.

The gentleman I talked to said that they’re all off some and not to worry about it.

 

[widget4145]

Just to clarify, I have the problem whether I’m connected to the grid or not. It’s Never off as much as .5 volts, usually just .2 or .3

I updated the firmware yesterday, and saw no change.

The gentleman I talked to said that they’re all off some and not to worry about it.

I beg to differ. It's not normal.

Other systems dont do this. They give the voltage what you ask for.

For an LFP battery, 16s to be specific, 0.2-0.5v offset is a big difference. 55.2v vs 54.7v, full vs not full. And this confuses the BMS, in the case of JK Inverter BMS, wont go into float mode since it never reach absorption voltage. For the other BMSes, well, it wont reach balancing mode. Usually, balancing starts at 3.45vpc.