tolwi
[SMART HOME PANEL 2] - Battery levels not updating
I installed the Ecoflow Cloud for my Smart Home Panel 2 which have a Delta Pro 3 connected to it.
I noticed the the battery level do not live update. I have to manually reload the integration in order to see the updated battery level.
I also noticed something very strange and that might be related. I have an automation that turns the Economic Mode to Self-Service at 10:30AM then turn it back to None at 17:00 and turns back on EPS mode.
After that, the Smart Home panel was continuously trying to charge the battery even if it was full. In the Ecoflow app I had logs saying "Battery charging stopped because the charge limit have been reached" every single minute starting at 17:00.
Both my App and Integration have a charge limit set at 100%. After reloading the integration, it stopped charging the battery every minute thus no more logs.
I noticed this as well. I do not use any of the Savings modes, EPS mode is always on, and the charging limit is set to 90%.
I have exactly the same issue with Delta Pro 3 see #463 @vcadieux does your DP3 is updating data has it should? My D2Max works great, values are updated but not my DP3, I tried changing keys, unbind, nothing updated except on integration reload
I've been digging into the data returned by the MQTT quota topic and the data returned from the /device/quota HTTP endpoint. For the SHP2, not much is reported via MQTT. I regularly see watts for each circuit, watts for each battery, and some charge/discharge times. No SOC, so this integration is only getting that when it first starts from the initial HTTP request. Right now, it would have to also use HTTP polling to get updated SOC periodically.
I have Delta Pro Ultra inverters, and for those, I do see MQTT returning SOC info, but in that case, each response can vary by a few percentage. For example, if the app is showing me 88%, I'll see MQTT vary between 85-88 and change pretty much between every single payload received.
Edit: The variance in SOC I'm seeing is because it's reporting SOC for each individual battery connected to the inverter.
I'm going to reach out to Ecoflow about why the SHP2 doesn't report SOC via MQTT.
Unless Ecoflow decides to publish more MQTT info for the SHP2, the options today are to either also poll HTTP (undesirable), or only rely on MQTT info directly from the batteries connected to it (and remove it from the SHP2 device).
Thanks, makes sense. Anyway if a DP3 is connected to SHP it won't update also because mine do not report battery (except when integration starts)
It's possible to get continually updated SoC using ioBroker and MQTT. That's how I get the data into Home Assistant. Works perfectly.
BTW - does anyone know how to obtain control of the AC1 switch on the SHP2? After literally days of experimenting, I'm about to give up.
@LSR19 Can you provide the key you're using to get SoC or even better, an example payload? What batteries are you using with your SHP2? I'm using Delta Pro Ultras.
Maybe it doesn't send the SoC until it actually changes? I'll collect more payloads to keep searching. All I've seen so far that relates to the batteries is something like this:
{"wattInfo":{"gridWatt":0.0,"chWatt":[-249.03333,-234.9,0.0],"allHallWatt":470.0},"backupInfo":{"energy2":{"dischargeTime":2617},"energy1":{"dischargeTime":3302},"backupDischargeTime":2598,"backupChargeTime":0,"chWatt":[-249.03333,-234.9,0.0]}}
Which gives me some power stats and discharge times, but no SoC.
Their example MQTT payload in the documentation doesn't mention anything about SoC either. I've only been able to get it from their HTTP API.
I’m not near my computer right now, so can’t answer all your questions. Here’s what I can tell you now. The issue with SoC not being updated by the HA ecoflow-cloud integration (v1.3.0) is not limited to others on this thread - it is a problem on my install, too. Because of that, I searched around for other solutions and came across ioBroker. ioBroker is based out of Germany, I believe, but the site is multi-lingual. ioBroker logs in like your EcoFlow mobile app and derives a special app-session MQTT credential set: • UserName (looks like app-…) • UserID (19-digit) • UserPassword (alphanumeric) • ClientID (starts with ANDROID_…) The adapter can obtain those using your EcoFlow account email/password; then it connects to mqtt.ecoflow.com with those values. That mirrors the mobile app’s authorized session, so the Access Control List lets it read/write authorized device topics. One of the pieces of data you can get this way is SoC, and I’ve found it reliably tracks my battery’s SoC as shown on its display and in the mobile app. My battery is a Delta Pro Ultra connected to a Smart Home Panel 2. Note that ioBroker does not use your developer AccessKey/Secret keys. So in essence, ioBroker impersonates your EcoFlow app.
However, ioBroker isn’t a panacea because it exposes very limited control functionality. I want to be able to control AC1 from HA to connect/disconnect my battery from the SHP2 so that when the battery is not needed (e.g., it’s nice out and it’s SoC is between 20-80%), AC1 is switched off so the battery slowly discharges to 20% (using SoC data) due to idle current only. Then HA would switch on AC1 to charge the battery back to 80%. I want to do this because I don’t use any of the saving features of the EcoFlow app like TOU, etc. so the SHP2 defaults to recharging the battery whenever it’s SoC drops a mere 5% below its max SoC (which I set to 80%). But AC1 is not exposed by ioBroker, so I’m still stuck (the HA integration also does not expose AC1.) If you have found a way to control AC1, please let me know.
If you want, I can explain more about setting up ioBroker when I get in front of my computer again. (I haven’t searched the threads here to learn if anyone else mentions ioBroker.)
Thanks for the explanation, that makes total sense. Good to know they keep the good stuff in their private MQTT provider instead of making all of this data available in the publicly documented one. This integration does have support for that but there's more work involved to figure out how to use what's getting published there.
BTW, ioBroker exposes literally dozens of sensors that even the EcoFlow mobile app doesn't. For instance, in addition to circuit watts ioBroker shows individual circuit amperage. This actually resolved an issue I thought the EcoFlow app was having - I knew current was flowing through a few SHP2 circuits, but the app showed 0W for each. I thought something was amiss. Turns out, the current was extremely low for the 0W circuits. So it seems the app simply rounds the watts displayed for individual circuits. It makes sense to not clutter the app with displays of, e.g., 0.05W, but it would be nice to see some indication of the circuit actually consuming power in the app.
Thanks for the explanation, that makes total sense. Good to know they keep the good stuff in their private MQTT provider instead of making all of this data available in the publicly documented one. This integration does have support for that but there's more work involved to figure out how to use what's getting published there.
I thought I'd let you know I have figured out how to toggle the AC1 switch on my SHP2 from Home Assistant by communicating directly with the EcoFlow API over MQTT, without using ioBroker, the EcoFlow-Cloud integration, or any other special EcoFlow integration. HA can communicate directly with the EcoFlow API using HA's MQTT integration and MQTT Mosquitto Add On, after getting some credentials from EcoFlow cloud and setting up MQTT and Mosquitto correctly. Now that I'm able to control AC1 on and off, I am going to figure out how to get status telemetry from the SHP2 into HA (e.g., SoC, Storm Guard, and other data) so I can create my automations. That should be easier to do, because pulling in data seems to be simpler than controlling switches. TBD. The trick to this was discovering a couple of the documents published on the Ecoflow Developer website. The way to do it is in those documents.
@LSR19 If you found iobroker adapter already usefull, you can add an issue there and I will incorporate the missing control of AC. If you now already the needed telegram it should be easy. Many things need to be discovered first and then implemented.
@LSR19 If you found iobroker adapter already useful, you can add an issue there and I will incorporate the missing control of AC. If you now already the needed telegram it should be easy. Many things need to be discovered first and then implemented.
I will do that. Let me know where to share the info - here, or in ioBroker? I have working MQTT /set payloads (telegrams) for controlling each of the SHP2’s 4 switches (AC1, EPS Mode, Charge Now, Storm Mode). Those /set commands are disclosed by EcoFlow. But EcoFlow’s Developer Documents do not explain how to use MQTT /get payloads with the SHP2 for pulling in data, and the /quota topic does not pull in SoC info. I am curious to know if the robust data you are able to pull from the SHP2 - including SoC and more - is obtained using MQTT. Are you using MQTT /get, /get-reply, or /quota topics? If so, can you explain how you do that? Is there an unofficial topic or /get command that works?
It would be good, if you could open an issue in the iobroker.ecoflow-mqtt repo. That’s the place, where it belongs. The adapter uses mqtt, /get/get_reply/set/set_reply/update and the SHP2 uses protobuf which needs de- and encoding. /get only triggers the reply, but with the /updates the data is permanently flowing in.
Will do. I have not heard of the /update topic - I have not seen that documented anywhere. I'll give it a try. Thanks.
@vcadieux There's a scheduled quota/all call every 5 minutes in the latest 1.4.0 beta3. This will update the battery levels every 5 minutes. If that's acceptable, then we can close this.
