v3.2.0 introduces static values values for DCx Current, DCx Voltage, and DCx Power about ha-abb-powerone-pvi-sunspec

[jumpinf00l]

@alexdelprete Perfect, that seems to have sorted it! Thanks very much for looking at it

home-assistant_abb_powerone_pvi_sunspec_2023-11-27T09-45-29.697Z.log

Here's the screenshot from qmodmaster if it helps for future (I hope I've set it up right)

Cheers for the quick reply and fix!

[jumpinf00l]

Sure thing, I’ll monitor and let you know

[jumpinf00l]

so I guess nothing to worry about.

It hasn’t been more than 20W difference since I’ve been monitoring, very negligible and not breaking anything

[alexdelprete]

The root cause is this: https://community.home-assistant.io/t/custom-component-abb-power-one-fimer-pv-inverters-sunspec-modbus-tcp/316363/345?u=alexdelprete

The other strange thing is that the MPPT Count in your case is 303, and that's not a consistent value, you should have 2 there.

Unfortunately some inverter models have a different register map, and in order to resolve this I would need to add some exception code to manage these differences. I was not very inclined to do that...but probably I'll have to address these cases.

Can you use qmodmaster to show the contents of the registers?

I'll tag @ivanfmartinez because he has a monophase inverter like you with 2 MPPTs.

[alexdelprete]

@jumpinf00l I found the specific offset for Model 160 (UNO-DM-PLUS and REACT2 inverters only), can you please install the master version in HACS and let me know if it works? A debug log and screenshot would be perfect, thanks.

In case you don't know how to install the master branch version: go to HACS, open my integration, hit the 3-dots on the upper right and click Redownload, then choose master:

[alexdelprete]

Perfect, here you can see the fix in action:

(read_rt_160) Model not 160 try another offset - multi_mppt_id: 120
(read_rt_160) Slave ID: 254
(read_rt_160) Base Address: 40000
(read_rt_160) Model is 160 (UNO-DM/REACT2) - multi_mppt_id: 160
(read_rt_160) mppt_nr 2
(read_rt_160) Completed

I'll close the issue if it's ok for you and release a new version.

Thanks for the help.

[alexdelprete]

Cheers for the quick reply and fix!

I noticed a strange thing from yous screenshot: DC Power is not the sum of DC1 Power + DC2 Power. Can you please monitor that when you have time and let me know if that's always the case? On my inverter it is the sum of the the DCx Power of the MPPTs.

Please let me know, thanks.

[ivanfmartinez]

Cheers for the quick reply and fix!

I noticed a strange thing from yous screenshot: DC Power is not the sum of DC1 Power + DC2 Power. Can you please monitor that when you have time and let me know if that's always the case? On my inverter it is the sum of the the DCx Power of the MPPTs.

Please let me know, thanks.

In my case DC power also is not the exactly the sum of DC1 and DC2, but are near. Probably this is related to different timings for the register updates.

[alexdelprete]

In my case DC power also is not the exactly the sum of DC1 and DC2, but are near. Probably this is related to different timings for the register updates.

Not with the integration, because it reads everything in page mode, in 0.1s.

This was the main reason I started developing it.

[ivanfmartinez]

In my case DC power also is not the exactly the sum of DC1 and DC2, but are near. Probably this is related to different timings for the register updates.

Not with the integration, because it reads everything in page mode, in 0.1s.

This was the main reason I started developing it.

The difference can be already inside the inverter if the MPPTs are independent and they put an separate process to calculate total this will happen, and many other possibilities.

[alexdelprete]

That's not how the datalogger (VSN300/VSN700/etc.) works: it gathers all data via internal Aurora protocol, and it provides new modbus data every 60s (if I remember correctly, might be even longer). And I wasn't able to change the default period. It's a protocol gateway (Aurora to Sunspec Modbus TCP) plus a buffer for internal data.

So there's no discrepancy.

[ivanfmartinez]

For me since beginning there was this difference most of the time. Maybe my model works differently than yours.

…

On Mon, Nov 27, 2023 at 12:48 PM Alessandro Del Prete < ***@***.***> wrote: That's not how the data logger works: it gathers all data via internal Aurora protocol, and it provides new modbus data every 60s (if I remember correctly, might be even longer). And I wasn't able to change the default period. So there's no discrepancy. — Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFFJCP3F3UMD7IZPZH3VEDYGSY3BAVCNFSM6AAAAAA72RSKA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRYGA4TINJQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alexdelprete]

For me since beginning there was this difference most of the time. Maybe my model works differently than yours.

The VSN cards work all the same. I think it might be something specific to some models, or firmware of those models, maybe the DC Power takes into account power factor or something else, I don't know. The difference is minimal I guess. How much in your case?

[ivanfmartinez]

To check the exact difference I have exported data (one of the inverters) from 17/november to today using history explorer card.

Putting data on spreadsheet and calculating I found in that the difference appear in around 50% of the data with value 1, all other lines have no difference between dc_power and (dc1_power + dc2_power)

It's really a minimal difference.

[alexdelprete]

It's really a minimal difference.

so I guess nothing to worry about. If you notice wide gaps, please let me know. I know we can't do much about it, since that's what the inverter is reporting, but if some users report this, at least we know about it.

Thanks for the help.

[alexdelprete]

Thank you for the feedbacks gentlemen. Another improvement in the integration, happy about that.

Now next big step will be to pull data from VSNx00 card via HTTP and parse json. This will allow the integration to have ALL data, including battery, meters, etc. without worrying about registers, address maps differences among models, etc.

@ivanfmartinez are you a developer? would you be interested in helping with that? I already managed to implement (starting from an old existing script I found) a python script that authenticates with VSN300 and VSN700 (they have different auth schemes) and gathers all JSON.

[alexdelprete]

OMG, @ivanfmartinez, I just found out checking my repo here that you were a contributor in 2016 to the script I started from for the VSN300. We really live in a small world...😄

Anyway, in that repo you'll find a script that is tested on 3 inverter types, one is mine with the VSN300 and then other 2 people tested it and they have VSN700 cards. I put sample data in folder data-samples, if you want to take a look at it.

It would be fantastic to have an integration that works both with Modbus TCP and HTTP/JSON, and the user can configure it as they like.

Let me know what you think about it...thanks.

[ivanfmartinez]

OMG, @ivanfmartinez, I just found out checking my repo here that you were a contributor in 2016 to the script I started from for the VSN300. We really live in a small world...😄

Anyway, in that repo you'll find a script that is tested on 3 inverter types, one is mine with the VSN300 and then other 2 people tested it and they have VSN700 cards. I put sample data in folder data-samples, if you want to take a look at it.

It would be fantastic to have an integration that works both with Modbus TCP and HTTP/JSON, and the user can configure it as they like.

Let me know what you think about it...thanks.

I'm a developer, but don´t have much time available, but I can help.

When I installed my system in 2016 I have looked many options to integrate with my openhab and pvoutput. The world becomes smaller with this public repositories.

I have tested your script in my inverter and committed a new file in my fork, my json is different from the other two files already in repository.

[alexdelprete]

don´t have much time available, but I can help.

I'm not a dev, but I have some time. Glad you can help. What I would need is a class with functions that reads the data and puts it in a "dynamic" structure (since not all inverters provide same output). From that point on I can take care of the rest basically, reading the structure and putting everything in sensors.

How do you want to follow up? Meanwhile I gave you dev access to the vsnx00 repo. I'll open a discussion on this repo, will give you dev access to this too.

Thanks for the help you can give.