Something funny going on here. I have two SolarEdge inverters. I use the Modbus binding and the SunSpec binding to read values from both. Everything has been working, and still is, except for one reading from one inverter, Total Exported Energy. A few months ago, it jumped from its normal value of about 2.8GWh to -1.1GWh. It is still counting upwards (towards 0), but this is obviously wrong.
I tried everything to refresh it properly, including recreating things and items with no profiles or transformations, or anything that might be polluting the reading.
If I create a separate, stand-alone Modbus Poller and Modbus Data, I get what looks like the correct reading of 3.19GWh.
Any ideas?
Seems like something is going on in the Modbus/Sunspec stuff. But very strange that it’s only happening on one and not both inverters…
If I was to guess, sounds like you have used a wrong data type that rolls over at 2^31 - 1.
You need to use the larger one, so go from probably 32bit to the 64bit data type.
It does feel like something like that. But these SolarEdge Meters are connected via the SunSpec thing, so there is no way to access or modify the channels, they’re preset. I think that’s kind of the point of this SunSpec thing.
Looking at the Sunspec binding, the value is defined as regular int32 and not as uint32. Hence, when exceeding a certain value, suddenly the minus sign is added.
See the openhab repository at Github
bundles/org.openhab.binding.modbus.sunspec/src/main/java/org/openhab/binding/modbus/sunspec/internal/parser/AbstractBaseParser.java
and
bundles/org.openhab.binding.modbus.sunspec/src/main/java/org/openhab/binding/modbus/sunspec/internal/parser/MeterModelParser.java
So I think you found a programming bug in the sunspec binding.
But the value is less than other similar channels, and less than it’s counterpart on the other inverter. I typos GWh in my original post. It’s true reading is only at 3.2MWh now. Other similar channels have 6+MWh
Also then, why does the manual Modbus Poller and Modbus thing give the correct reading?
Like you wrote earlier, when you use the manual modbus poller, you tell it to read a uint32, wheras the sunspec modbus extension seems to be preprogrammed to use int32 for this register.
That other channels with larger quantities seem to report correctly, can be a matter of the scale factor that is being applied by the inverter/meter.
Yes, i think this is it. I just did a test of changing my manual Modbus Data to read as int32 and the number i get is the same as the erroneous number from the sunpec binding: -1097791 instead of the expected 3,197,176,000.
My other inverter is at 1.96MWh on the same register. Google says max integer in 32bit is 2,147,483,647. So it seems correct until the scale factor needs to change
There doesn’t appear to be a roll over to 64bit.
There is another register ‘Real Energy Scale Factor’, which I’m guessing is how the value is changed to different ranges.
lines 82 to 91 in
openhab-addons/bundles/org.openhab.binding.modbus.sunspec/src/main/java/org/openhab/binding/modbus/sunspec/internal/parser
/AbstractBaseParser.java
Extract an optional acc32 value
*
* @param raw the register array to extract from
* @param index the address of the field
* @return the parsed value or empty if the field is not implemented
*/
protected Optional<Long> extractOptionalAcc32(ModbusRegisterArray raw, int index) {
return ModbusBitUtilities.extractStateFromRegisters(raw, index, ValueType.INT32).map(DecimalType::longValue)
.filter(value -> value != 0);
}
To be honest: these lines are correct. They define the acc32 type which is int32 and this type is used for one datablock of the InverterModelParser.
This file is missing a uint32 type (optional and mandatory). The MeterModelParser then needs to be adapted to use uint32 i.s.o. acc32.
Are you familiar with filing issues on github? Or even making pull requests?
Edit 2025-01-18: @MartOs, I created a kar addon including the original modbus binding and only the sunspec extension. The sunspec extension has the addition of the UINT32 data type. You can find the add-on here on github. You could do a test with it by removing the modbus binding from your system and installing this kar into your add-ons folder. I’m not able to test this myself due to lack of a meter (only an inverter available in my system). If test is succesfull, we can try to push this updated binding.
I did test it in my openhab test server and it functioned such that I could read my Solaredge inverter without issues, but the inverter does not use UINT32 data types.
So in my case it was safe to use. But for the meter new/additional code lines are used. Testing on a test server where you cannot harm your productive system is of course advised. On top of that you were showing an openhab graph with retained data. This snapshot binding will likely affect new data being logged (different, but supposedly correct values). So please always keep in mind that an untested modified binding could have implications on a production system/environment.
Thanks again. Understood.
I don’t have any long term stats to protect so it’s not the end of the world if I get it wrong first time. I was aware of that possibility, and I was going to create some test items first to see if I get the expected numbers.
