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