Delta Pro Ultra only returning data for a single battery when multiple exist

[jxlarrea]

Describe the bug
Information for onlya single battery is being retrieved when multiple batteries are actually connected to the DPU.

Expected behavior
All available battery details should be retrieved. Currently the single battery data is being returned through the Y711ZXXXXXXXXXXX_BPInfo topic. When using the HTTP API, I can see that all available battery data is being returned in the hs_yj751_pd_bp_addr.bpInfo quota json, listing them in an array, for example:

        "hs_yj751_pd_bp_addr.bpInfo": [
            {
                "bpChgSta": 0,
                "bpEnergy": 6144,
                "bpErrCode": 0,
                "bpNo": 1,
                "bpPwr": -425,
                "bpSoc": 75,
                "bpSocMax": 90,
                "bpSocMin": 10,
                "bpSunnovaBan": 0,
                "bpTemp": 39,
                "heatTime": 0,
                "remainTime": 681
            },
            {
                "bpChgSta": 0,
                "bpEnergy": 6144,
                "bpErrCode": 0,
                "bpNo": 2,
                "bpPwr": -544,
                "bpSoc": 70,
                "bpSocMax": 90,
                "bpSocMin": 10,
                "bpSunnovaBan": 0,
                "bpTemp": 36,
                "heatTime": 0,
                "remainTime": 489
            }
        ]

Versions:

• Adapter version: 1.0.4

[foxthefox]

I would guess this item relates to DPU and not SHP2, correct?

Are the values in bpinfo in iobroker are updated?
Do they change between the two batteries?

According to the structure there might be a BpinfoReport, which is an array.
But this should have another id in the telegram.

You are the first cotacting me, who owns an extra battery pack.
It would be very kind, if you could provide me some example telegrams, they appear in logs.
Therfore you have to put the adapter into debug mode, enable the debug at the device definition and activate (tick) msgUpdate and mgsGet.
Thank you

[jxlarrea]

Hello!

Yes, the multiple battery data comes from the DPU, not the SHP2.

No, the values in bpinfo never change between both batteries. The same single one is always being reported.

Here are the logs. During the logging period, the DPU batteries discharged by 2%.

iobroker.2024-11-25.zip

[foxthefox]

Thanks, I will check the log today evening. The update messages are present, but no set/get. Anyhow update messages checking need also time.

[jxlarrea]

Thanks, I will check the log today evening. The update messages are present, but no set/get. Anyhow update messages checking need also time.

@foxthefox Sorry I forgot to turn on debugging on the DPU when creating those logs. Here are new ones with debug mode on:

iobroker.2024-11-26.zip

During the logging, both batteries charged up about 3% each. I can see in the logs a single battery being updated but not the other:

2024-11-26 07:48:18.666 - debug: ecoflow-mqtt.0 (195970) [PROTOBUF decode] Y711ZAB5SG1E0405 [update] msg#0 => {"bpNo":2,"bpChgSta":1,"bpSoc":63,"bpPwr":1552,"bpEnergy":6144,"remainTime":92,"bpSocMax":90,"bpSocMin":10,"bpTemp":42}

The other battery should be identified as "bpNo":1 but is nowhere to be seen in the logs.

[foxthefox]

I checked the raw data and it contains two sets of battery data.
I was directly checking BpInfo and not BpInfoReport, which decoded only the last set.

After modification of the code and also adding the checkbox in the device tab, it will be available.

[jxlarrea]

I checked the raw data and it contains two sets of battery data. I was directly checking BpInfo and not BpInfoReport, which decoded only the last set.

After modification of the code and also adding the checkbox in the device tab, it will be available.

Awesome, thank you so much. I imagine that the next merge will contain both this and the SHP2 enhancements.

[foxthefox]

yes next version will have both enhancements.

[jxlarrea]

yes next version will have both enhancements.

@foxthefox Thank you! I would have try to contribute with the project and fix these issues myself but I still do not understand how to request more data from Ecoflow's MQTT server. I always only get partial objects.

Anyway, I still would like to support it. Is there a donation or a "buy me a coffee" link anywhere?

[foxthefox]

With version 1.1.0 it shoudl be visible now.

Unfortunately I have no donating option so far.
I am happy when you star me and I get sample data to improve the work.

[jxlarrea]

With version 1.1.0 it shoudl be visible now.

Unfortunately I have no donating option so far. I am happy when you star me and I get sample data to improve the work.

Happy new year @foxthefox! I am currently testing the new release. Now the second battery info is being sent to the local MQTT server into BPInfo2 but unfortunately only remainTime and bpPwr are being populated. BPInfo has a few more details. Also, bpPwr is showing a negative value.

The logs do show all details from all batteries, including bpTemp which is what I am more interested in.

2024-11-26 07:48:18.666 - debug: ecoflow-mqtt.0 (195970) [PROTOBUF decode] Y711ZAB5SG1E0405 [update] msg#0 => {"bpNo":2,"bpChgSta":1,"bpSoc":63,"bpPwr":1552,"bpEnergy":6144,"remainTime":92,"bpSocMax":90,"bpSocMin":10,"bpTemp":42}

[foxthefox]

I whish also a Happy New Year @jxlarrea!
I am not sure what it is, since I have correct values derved from your previous captured log.

where more values are shown in the object tree of iobroker.
The ones with null are not processed right now, will come later.

Maybe you can post some raw messages from the debug log?

[jxlarrea]

@foxthefox This is very strange. The iobroker object tree doesnt even show BPInfo2 for me. I verified that version 1.1.0 is installed and running and even rebooted the host.

[jxlarrea]

@foxthefox I think i know what's going on. The other values are only being populated as they change and not when the instance is restarted, as it happens with all other values. I already got 2 more values populated in BPInfo2.

Here are the logs:

iobroker.2025-01-02.zip

Regardless, I still cannot see the BPInfo2 object in the iobroker object tree.

[foxthefox]

Thanks, I will look at the data.

Did you tick the checkbox 'slave1' in the config for the DPU?
That is needed to create the object tree.

BTW.
a negative value vor bpPwr does not look strange to me.
If there is a balancing or beeing in offgrid I would expect negative values.

[jxlarrea]

Thanks, I will look at the data.

Did you tick the checkbox 'slave1' in the config for the DPU? That is needed to create the object tree.

BTW. a negative value vor bpPwr does not look strange to me. If there is a balancing or beeing in offgrid I would expect negative values.

Thank you, I was missing the Slave 1 checkbox. It shows up now.

You are correct about the negative value. BPInfo sometimes show negative values too.

So yeah, the only issue now is that the BPInfo2 data is not being loaded when the adapter instance starts. Other than that, everything looks fine!

[foxthefox]

What do you mean with "BPInfo2 data is not being loaded when the adapter instance starts"?

[jxlarrea]

What do you mean with "BPInfo2 data is not being loaded when the adapter instance starts"?

When the ioBroker.ecoflow-mqtt instance starts, it pulls all quotas from Ecoflow's MQTT server and pushes that information to the local MQTT server. This is not happening BPInfo2, as it is only pushing bpPower and remainTime initially and the remaining values are only being pushed to the local MQTT server once an update happens in those - even though all values exist in the iobroker BPInfo2 object tree.

[foxthefox]

I got it.
I have created 1.1.1 in github, it should also inlcude BPInfo2 now.

Please update via expert mode and octocat and git.

[jxlarrea]

I got it. I have created 1.1.1 in github, it should also inlcude BPInfo2 now.

Please update via expert mode and octocat and git.

Unfortunately it did not work. Version 1.1.1 has the same behavior as .1.1.0. Only bpPower and remainTime in BP2Info2 are being pushed on instance start.

[jxlarrea]

Both BPInfo and BPInfo2 should show the same amount of values, but only bpPower and remainTime are being pushed in BP2Info2 to the local MQTT Server when the instance starts.

[foxthefox]

Thanks for the test. May be I was too fast and did not see a further constraint, which prevents it.
I have to dig a little bit in the code.

Edit: something strange happened, the pull request shows my changes, but the file in main branch not. That is most likely the reason. I have to push it again to the file. I am away for some days, so it will be Tuesday.