Do SolarEdge Inverters suffer from wear issues on the flash memory?

[cyberkryten]

Describe the bug

There have been changes made to Predbat for GivEnergy inverters because register writes are causing premature wear of the on-board flash memory.

There are many parameters being changed when using this integration to control the inverter, so an understanding of whether this is something we need to be concerned about would be good.

Has anyone got an answer or asked SE about this?

I note that there is a warning about this in one of the more recent SolarEdge TerraMax Inverter technical notes, though I can't find any reference in others :

https://knowledge-center.solaredge.com/sites/kc/files/se-modbus-interface-for-solaredge-terramax-inverter-technical-note.pdf

At the bottom of Page 19:

The adjustable parameters in Modbus registers are intended for long-term storage.
Periodic changes in this parameter may damage the flash memory.

Due to the way the SE inverters reset daily and also have a default command timeout of 1 hour, it is necessary to write the status to the inverter regularly, so this is a concern if it does affect SE Inverters - without knowing the MTBF and wear details, it is hard to know if current writes are within limits or likely to cause major problems.

Expected behavior

Change settings without causing premature failure.

Screenshots

No response

Diagnostic File

None

Debug logs

No response

Home Assistant Version

All

solaredge-modbus-multi Version

All

Installation Type

HAOS

Read the Instructions

• My configuration follows https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Configuration
• I have read the Known Issues https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Known-Issues
• This issue is not about a template error (do not report template errors, read https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Template-Design-Notes)

Additional Context

No response

[jrviz]

@cyberkryten I know you have been deeply involved in at the conversation on Predbat where a single start charge command from predbat can then result in charging stopped if the inverter times out or resets. Predbat now has the always keyword to repeat a command on each cycle which gets round that part of the problem. However, the concern now becomes a large number of redundant inverter writes and leaves a "wear" concern on the flash memory here.

I'm experimenting with a script that is called from the Predbat service API which checks current status before issuing another write. This replaces the SE Multi entity select calls and only calls them if the current value is different from the provided one. The script also sets the timeouts to extend those out whilst charging is take place

I end up with this sort of service call in the Predbat apps.yaml

   charge_start_service:
    service: script.se_inverter_command_change
    command: "Charge from Solar Power and Grid"
    timeout: 7200
    always: True

   charge_stop_service:
    service: script.se_inverter_command_change
    command: "Maximize Self Consumption"
    timeout: 3600

[WillCodeForCats]

I can add a warning in the write enable screen that frequent writes may cause flash wear.

I would assume all models are affected to some level, but the flash used is unknown and could even change between different internal revisions if supplier availability for parts like flash chips (or whatever SE is using for storage internally) changes.

[WillCodeForCats]

PR #736

[DragonQ]

I always do a check of whether the battery is already in the desired mode before changing it, which obviously helps a bit. But sometimes, particularly in summer, I need to change the battery mode multiple times per day. Even in winter it needs to change at least twice a day. Not really much you can do about it.

[cyberkryten]

Yeah, I'm struggling to figure out what is written where and the consequences. It seems likely that anything that persists between restarts/resets (ie the 'Default' mode) must be written to flash, otherwise it couldn't restart in the same state. So, anyone using those values as the target for Predbat is almost certainly causing flash writes on a regular basis.

It also seems possible that transient items (ie the current mode) may not be written to flash as things like the status of the inverter will probably be RAM only. Of course, it could be that all mode changes are written out (that would be the simplest option from a coding perspective) - if anyone has a contact within SE Dev team I'm happy to engage but front line support won't understand the questions.

I'm a bit wary of putting logic probes into the inverter and running it with extra wires on the board to test, given the significant DC/AC voltages involved, though as has been mentioned, the effect and MTBF of flash will vary between inverters anyway.

Of course, in theory a failure should be covered under warranty...

[RobinXe]

I think caution is wise, and I have already been modifying my automations in order to check whether a change is necessary before executing it, which is probably good practice regardless. This could be implemented at an integration level, but I suspect it may be a significant PITA!

However, having digested the document that initially raised these concerns, I think we may concerned unnecessarily. I suspect that the only registers written to flash would be those in the the non-volatile category. Those that reset on inverter reboot are likely stored in volatile memory; though I concede that they may be reset to defaults by the inverter's startup routine, I'm not sure why they would be, if they were stored in non-volatile flash.

The supposition that the inverter employs volatile (less-wearing) memory for volatile registers is supported by the read-only registers that it writes itself with significant frequency, such as the instantaneous power, voltage, etc. If it is writing these into flash then the frequency of our writes would pale in comparison!

Of the registers listed as non-volatile in that document (assuming commonality between SE inverter architectures) the only one that we consumer-grade users are likely to be changing with any regularity is the command timeout.

[DragonQ]

Storage Default Mode is the one I use all the time because it has more options than the Storage Control Mode. I think I've only changed Storage Control Mode 3 or 4 times (to set it back to Remote Control after it mysteriously changes sometimes).

[RobinXe]

There are three mode selectors, with similar names, which can be a little confusing.

Storage control mode is effectively where the commands come from, and remote control is indeed what you need.

Storage default mode and storage command mode both work together. At the end of the command timeout, the mode will switch from the selected command mode to the default mode. While changing the default mode overcomes the need to concern oneself with the timeout, or handling restarts, it is likely to be a register that is written to non-volatile memory, and thus raises concerns with flash wear.

[DragonQ]

I see. Since we change our storage mode at least twice a day (to charge at night), could we set the Storage Command Timeout to 18 hours and then use the Storage Command Mode instead of Storage Default Mode?

EDIT: Just read that the Storage Command Timeout also reverts to 1 hour after it runs down. What a silly system! So either we need to change the Storage Default Mode like we do now and risk flash failure, or send TWO commands each time we want to change modes, i.e. change Storage Command Timeout to whatever we need (24 hours if we don't know), THEN Storage Command Mode. Ugh.

Does writing Storage Command Timeout not risk wear?

[RobinXe]

Does Storage Command Timeout risk wear? This is unknown. The document for the inverter that raised concerns list 'Command Timeout' as non-volatile, suggesting it is stored in flash, however that property, for that inverter, does not refer to storage, but to other power conditioning parameters. Anecdotally, it appears that Storage Command Timeout does not persist across a reboot, therefore is less likely to be stored in non-volatile memory.

[cyberkryten]

I see. Since we change our storage mode at least twice a day (to charge at night), could we set the Storage Command Timeout to 18 hours and then use the Storage Command Mode instead of Storage Default Mode?

In theory that may be useful but in practice the SE Inverters reset regularly. Mine does it twice a day (up from once per day until the FW update last September). This is why some people use SDM, but of course that must be stored into Flash.

Those of us using SCM deal with the resets somehow. The common ways are using Predbat to control it (with a new option to send the command every run) or having an Automation that detects when the SCM changes back to Maximise Self Consumption and then reverts to the intended mode - everyone's approach/system is different and there's no simple solution for everyone.

[s-bauer]

This is only an issue when writing state, isn't it? Just reading energy, power and battery stats without modifying any setting should not cause any flash wear, right?

[cyberkryten]

This is only an issue when writing state, isn't it? Just reading energy, power and battery stats without modifying any setting should not cause any flash wear, right?

Yes, flash wear is only a concern with writes, so just reading data shouldn't cause anything to be written.