foxthefox / ioBroker.ecoflow-mqtt

EcoFlow, power stream, power station, delta, delta2, river, river2, wave2, glacier, delta pro ultra, generator, smart home panel, homeassistant gateway, powerkit, powerhub
MIT License
44 stars 2 forks source link

'Backup reserve' option missing on D2M #137

Closed walderston closed 1 month ago

walderston commented 1 month ago

Using ecoflow-mqtt via HA and noticed the 'Backup reserve' switch / option is not shown. If I use the hassio-ecoflow-cloud via HACS the option is there.

What do you need from me to look at getting this added?

foxthefox commented 1 month ago

I am not sure what is the data point behind "backup reserve" Do you mean pd.newAcAutoOnCfg or pd.bpPowerSoc ? Both are available and can be found in the iobroker object tree and should also be shown in HA.

If you refer to something else, I need more information.

walderston commented 1 month ago

Its a switch not a slider/number. In HACS, its shows as Backup Reserve Enabled (pd.watchIsConfig -> {"moduleType": 1, "operateType": "watthConfig", "params": {"bpPowerSoc": -3333300, "minChgSoc": 0, "isConfig": "VALUE", "minDsgSoc": 0}})

https://github.com/tolwi/hassio-ecoflow-cloud/blob/9ead9d054c688fce3781d3c694f8fde29b4d522f/docs/devices/DELTA_2_Max-Public.md?plain=1#L75

foxthefox commented 1 month ago

pd.watchIsConfig is available in the adapter as "diagnostic" data. I did not know that this is a switching datapoint.

Can you please enable the debug mode in the adapter and additionally

After debug mode is working, please perform this command in the APP and post the log file with some pre- and following lines.

walderston commented 1 month ago

Sure 2 separate logs files for turning the switch on vs off: [backup on.log] [backup off.log]

foxthefox commented 1 month ago

Unfortunately the log does not show the command from the APP. it only shows some unidentified values, which might come from a newer FW. I think before of repeating the test, please check the enable status of the device and and general debug settings. I have some exemplary screenshots:

Bildschirmfoto 2024-09-01 um 18 40 46

Bildschirmfoto 2024-09-01 um 18 41 52

Bildschirmfoto 2024-09-02 um 08 03 06

If these checkmarks are set, then the log should have more info inside (and will also report the missing datapoints) and should also have the command given by the APP

walderston commented 1 month ago

ah sorry, didn't realise I had to enable debug in the device config too.

Hopefully I timed that right as its very chatty - I filtered on 0077 being the last digits of the serial number to reduce the amount of chatter.

[off.log]() [on.log]()

foxthefox commented 1 month ago

Thanks for the log. There are new data structures inside, which fail to be processed. This is handled, but some important data updates are not visible. I will prepare a quick fix for that tomorrow. After upgrade unfortunately the test needs to becrepeated. I’ll keep you informed when I am ready.

ps. There are a lot of new datapoints inside the telegram, which need to be defined. That comes later.

foxthefox commented 1 month ago

I have not finished the next version 1.0.3, but the branch is uploaded. You can already try to create a new on.log and off.log with that version.

You need to go to adapters-> octacat ->custum and type the url as in the screenshot

Bildschirmfoto 2024-09-03 um 07 02 24

walderston commented 1 month ago

updated and attached: [backup off.log]() [backup on.log]()

foxthefox commented 1 month ago

Thanks a lot, now it is clear how it is arranged. I will update accordingly.

foxthefox commented 1 month ago

You could have a try, once again with the "tree" version (still 1.0.3) You have to delete the datapoint pd.watchIsConfig and pd.bpPowerSoc or the whole pd-tree and restart the adapter. That creates the new datapoints including their new behaviour.

pd.watchIsConfig is disabling/anabling the backup mode pd.bpPowerSoc is changing the value and when changing the value it is enabling the mode (not sure if the APP does it in the same way)

walderston commented 1 month ago

seems to be working as expected. thanks very much!

foxthefox commented 1 month ago

OK, I will make it official.

Can you check if the issue with SlowChangeWatt is still there, it might be a result of the not expected telegrams.

walderston commented 1 month ago

yup thats not updating in HA when I update the value in HA. It does update the value within the app itself.

walderston commented 1 month ago

hopefully this has the right debugging on.

SlowChangeWatt.txt

Basically, change the SlowChgWatts value in HA to 1800, that value it sent to EF however nothing is sent back to HA to set the new value to 1800

So when I refresh the HA page, it contains the old value.

foxthefox commented 1 month ago

Very good, you discovered the tick for HA debugging. What I am missing in this log is the [set_reply] message.

Maybe there is some behaviour which I do not anticipate. It could be the case that the HA always needs a response to the changed value and therefore it is not memorizing the given command. In iobroker a msg could contain the Ack=false and true to distinguish between command and feedback, but a given command is stored and not artificially reset (due to missing acknowledge).

I am so far not aware of a bit in HA to give feedback/acknowledgment or the necessity of such.

The adapter is only sending updated values to HA if there is a change to the current value or a complete update after adapter start.

foxthefox commented 1 month ago

I could also see it at my implementation, after the page refresh the value is back to the previous one.

walderston commented 1 month ago

going to assume its the same thing as permanentWatts that I mentioned on the last comment of #143

not tested the other values but I'd imagine its the same behaviour that HA keeps the old value rather than the newly set value so when you refresh in HA, its now out of sync until either ioBroker adapter is restarted or some other unknown event.

foxthefox commented 1 month ago

I would assume it in the same way. But still it is strange for me that a command is not persistent stored. At least it is processed as such and was going through the different processes. 🤔

foxthefox commented 1 month ago

Maybe we should continue in the other issue, hence this one is solved.