SMA is enhancing the SunSpec profile 2.0 to fullfill IEEE1547:2018 (see Sunspec Modbus protocol P.9 )
That means that the SunSpec 100-series are soon be deprecated. They will be replaced by the 700-series.
Just want to let you know that we are enhancing the OpenEMS PV-Inverter SMA Sunny Tripower bundle to also support the new 700-series. After test and review it will be uploaded to the git repository.
How did we find out?
A new inverter just returned the following SunSpec models:
1 - Common
123 - Immediate Control
It was missing the SunSpec model 101 or 103 for AC power data. The problem was that the new inverter was running on an old firmware.
Just to be sure: to generate the code for SunSpec, I had been downloading the XML files from here:
ā¦and used the [SunSpecCodeGenerator.java](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.bridge.modbus/src/io/openems/edge/bridge/modbus/sunspec/SunSpecCodeGenerator.java) to generate the internal Java Enum.
Are you using the same approach or do you need support?
@c.lehne Today there appeared an interesting new PR that uses JSON instead of XML for the SunSpecCodeGenerator. It sounds like a useful improvement - maybe before starting the new integration:
Could you (or @tsicking) pleas have a look? The implementation looks good on first sight, even though I would prefer switching to GSON or JsonUtils as we use it everywhere else.
The topic is not new, but Iām just going to jump in here. In the past few days, I have been working with SunSpec 160 and integrated 2 blocks (because of 2 MPPTs) into the DefaultModel. This works quite well.
However, we also have an inverter with 12 trackers. Since it is a repeating block, the length is variable, and itās difficult to add 12 trackers.
Are there any further considerations regarding repeating blocks, or do you have any other ideas on how I can implement this? Of course, manually reading the corresponding registers via Modbus is always an optionā¦