Integration Broken Delta Pro afer Firmware Update // Ideas for solution
nuppls opened this issue · 50 comments
Thank you for your nice work with this integration!
As mentioned in other issues #57 #54 #53 i have just updated firmware of my Delta Pro EU Version to Firmware 0.1.0.0 and integration isn´t working anymore. Support also informed about this bad decision. I was a bit blind before updating and not looking into the other issues...
I have integrated my Delta Pro to my local network via Wifi. Then no ports are open from 1 - 65535. But when i am in IoT Mode with Wifi of the Delta Pro i have scanned ports again and there was port 80/tcp http and 80555/tcp senomix04 open. Because for updating firmware they maybe need something... ;)
I have added a Raspberry Pi with Wifi to Delta Pro Wifi and via LAN integrated it to my local network something like a bridge. After installing haproxy and adding this to the configuration and restart haproxy, i can use the integration again.
/etc/haproxy/haproxy.cfg
frontend ecoflow
bind *:8055
mode tcp
use_backend ecoflowdeltapro
backend ecoflowdeltapro
mode tcp
server deltapro 192.168.4.1:8055 check
With the IP of Raspberry Pi in local Network i can add the Delta Pro again with this nice integration (including changing options). Only issue right now is, i need a running android application to be able getting information. When i close the android app, information stopped and home assistant is telling me entries are not available.
I will investigate this in next days further and keep you informed. Hopefully i can send just a dummy request from raspberry pi to delta pro to update information.
Good idea!
I am running Delta Max, can you set a passphrase on Delta Pro Wifi, or can everybody nearby connect on DP Hotspot when he runs EcoFlow App?
Does DP hotspot start at boot or do you have to press the IOT button?
Thx in advance.
Hi @fogfon
i havn´t seen any setting to set a passphrase to this "maintenance" Wifi. The wifi is only available when you press the IOT reset button. For around 5 minutes if you havn´t open mobile app. I will investigate this later this weekend to find out which requests the app sends to the ecoflow to keep the wifi available by raspberry pi.
For me it´s just a workaround until ecoflow hopefully reenable the local API. My ecoflow is in the basement and the wifi isn´t strong enough to get to the outside world. I also plan to run ecoflow 24/7/365. Therefor it´s hopefully okay for me when i press it one time and then it stays active.
Hi @nuppls,
thank you for informative response and research.
Your setup might be a good solution for controlling EcoFlow units without internet.
We started some weeks before this project:
https://github.com/fogfon/Research-home-assistant-with-EcoFlow-powerstation-s-
Next days we will test your setup, but we assume Delta Max battery drain in standby is too high for 24/7 off grid usage.
This idea got me thinking - there's an RJ45 port on the Delta Pro for comms with a "Remote" display - which is a remote display device that shows the same as the display of the Delta Pro - I have a Remote and it works with a simple ethernet cable, plug it in and the Remote's display lights up and starts showing values the same as the Delta Pro.
It's more likely that the ethernet port wiring isn't RJ45 and protocol isn't TCP/IP, but I do wonder if it's something that, say. a RasPi could be configured to communicate with and, using the same logic as @nuppls, we use the RasPi to surface the real-time data from the Delta Pro and have HA communicate with the RasPi (via Wifi).
The Remote port also definitely provides power to the Remote device - infact on the rear of the Remote device, it is defined as 12V DC (Delta Pro only).
I wish I were skilled enough to move this forward - something tells me the other option is going to be to use a Bluetooth proxy instead since, as far as I can tell, the Remote also communicates via Bluetooth when it isn't wired to the Remote port on the Delta Pro.
Hi @lwsrbrts , the manual for the Ecoflow Smart Generator contains a circuit diagram which shows the 6 pin data connector on the DC power cables to be CAN Bus, which makes sense. Also there seems to be a standard CAN pinout for the RJ45 connector.
Thank you all for your contributions. At the moment i have following setup since a few hours:
- Old Android Phone (with developer mode display always on) with opened Ecoflow App within IoT Wifi of Ecoflow Delta Pro
- When IoT Wifi is used and the app is opened the Wifi wil not disabled
- Raspberry Pi with configuration above HAProxy to bridge information to my normal local network.
I didn´t find out how the App starts the communication. Because i don´t understand the communication on port 8055. If someone maybe @vwt12eh8 understands this protocol we investigate further. Just to send update message to Delta Pro like in the app. I have tried an MITM Attack in Wifi ARP manipulation via ettercap but i didn´t understand the communication. My python skills are also not the best.
Yes RJ45 with CAN is maybe a solution, but i don´t want to buy an remote and until now i havn´t used CAN communication in other projects. For me my "simple" but ugly solution is a workaround.
If someone is interested we can go further. Just let me know with a short PN.
Hi @lwsrbrts , the manual for the Ecoflow Smart Generator contains a circuit diagram which shows the 6 pin data connector on the DC power cables to be CAN Bus, which makes sense. Also there seems to be a standard CAN pinout for the RJ45 connector.
It's also CAN on their Power Kits
Edit: The RJ45 connectors are for CAN on the Power Kits.
I got this from support last night.
Hi, I purchased the Ecoflow River Pro about a week ago because it had such great local API support. And it has served me great for about a week until last night when i was prompted to do the V3.0.1.11(Wi-Fi) firmware update. Ever since I have not been able to connect to the local API…
…Is there anyway that I can roll back this firmware update to make the local API usable again...
Qing (Support)
Thu, Oct 20, 11:51 PM (10 hours ago)##- Please type your reply above this line -##
Your request (275799) has been updated. To add additional comments, reply to this email.Qing (EcoFlow)
Oct 20, 2022, 23:51 EDTAccording to the feedback from our technical support, this issue will be settled via App updates which will be released very soon.
We appreciate your patience and understanding.
Please feel free to contact us if you need any assistance.
Best regards,
Thank you all for your contributions. At the moment i have following setup since a few hours:
* Old Android Phone (with developer mode display always on) with opened Ecoflow App within IoT Wifi of Ecoflow Delta Pro * When IoT Wifi is used and the app is opened the Wifi wil not disabled * Raspberry Pi with configuration above HAProxy to bridge information to my normal local network.I didn´t find out how the App starts the communication. Because i don´t understand the communication on port 8055. If someone maybe @vwt12eh8 understands this protocol we investigate further. Just to send update message to Delta Pro like in the app. I have tried an MITM Attack in Wifi ARP manipulation via ettercap but i didn´t understand the communication. My python skills are also not the best.
Yes RJ45 with CAN is maybe a solution, but i don´t want to buy an remote and until now i havn´t used CAN communication in other projects. For me my "simple" but ugly solution is a workaround.
If someone is interested we can go further. Just let me know with a short PN.
Hi, I have a Delta Mini and I was trying to use it with Domoticz therefore I made a communication trace between APP and my device. I am using Node Red for the communication. I am not a big expert but It is working for me.
Basically I am sending two strings to the device for the communication and than decode the message that is returning. I could not find all coded information, but enough for me. I am also switching AC and DC on/off depending on the time to save energy in the night. Please find attached node red flow, maybe it can help you to find a little bit more how the communication flow is working
Br. Frank
ecoflow.flow.zip
Hello, @nuppls I can confirm your workaround works with DeltaMax!
Same setup as you have. Raspi Setup:
https://github.com/fogfon/Raspberry-Pi-Hotspot-EcoFlow-Workaround
A rooted mobile runs EcoFlow app, logcat gives some information.
Where to share, here?
PM does not exist in guthub.com, no?
Hi, I have a Delta Mini and I was trying to use it with Domoticz therefore I made a communication trace between APP and my device. I am using Node Red for the communication. I am not a big expert but It is working for me. Basically I am sending two strings to the device for the communication and than decode the message that is returning. I could not find all coded information, but enough for me. I am also switching AC and DC on/off depending on the time to save energy in the night. Please find attached node red flow, maybe it can help you to find a little bit more how the communication flow is working Br. Frank
Hi, @franki29, does this work for you without connected EcoFlow app?
If yes, do you send something like keep alive packets in your strings?
I find "DeviceInputFragment updateTcp 数据更新" and "setOffline:false" in EcoFlowApp log, something like this?
https://github.com/fogfon/Research-home-assistant-with-EcoFlow-powerstation-s-/blob/main/logcat_IOT_WIFI
Hi @fogfon , basically it is working like @vwt12eh8 solution, just a little bit simpler and not so professional.
No app or internet connection is necessary. Using Note Red, I am sending a string via TCP to Port 8055 and get a answer back that I decoding. As example : If you send AA 02 00 00 B5 0D 00 00 00 00 00 00 20 02 20 02
3B 41 to the device you get a answer back from the device and byte 30 of the answer will give you the % that is shown at the device display. Byte 33 & 34 is the input in Watt, no matter if AC or Solar. And so on.. I am sending every 5 Second the command to the device. For MTTP information I am sending a different string.
https://github.com/nielsole/ecoflow-bt-reverse-engineering
I started reverse engineering the bluetooth interface of my Delta 2 and collected some sample data. Maybe someone can build on top of that.
I think it might be possible to build a bluetooth <--> WiFi/TCP bridge using e.g. an ESP32 without much effort. At least the commands (toggling outputs) on the Delta 2 on Bluetooth they seem to use the same structure.
Not sure when I will have time to test that idea.
I think it might be possible to build a bluetooth <--> WiFi/TCP bridge using e.g. an ESP32 without much effort. At least the commands (toggling outputs) on the Delta 2 on Bluetooth they seem to use the same structure. Not sure when I will have time to test that idea.
Sounds like a great idea. Keeps everything local and doesn't rely on the cloud and there'd be no way for Ecoflow to turn it off.
Successfully used the RFCOMM as backchannel for the UDP version request packet. Adding the device is the only thing working right now in blueooth bridge mode, but promising. (This is using t python desktop for prototyping the bluetooth bridge)
Concerning the solution idea: Bluetooth Proxy to connect EcoFlow Delta Pro:
I have built a bluetooth proxy using ESPHome which worked on the first try. ESPHome provides a comfortable website to install this right away with a few mouseclicks: https://esphome.github.io/bluetooth-proxies/
Then I tried to get the Delta Pro connected to HA. This needed some tries. To make sure, that HA recognizes the Delta Pro, I built a device tracker in configuration.yaml:
device_tracker:
- platform: bluetooth_tracker
- platform: bluetooth_le_tracker
track_new_devices: true
track_battery: true
interval_seconds: 90
When checking known_devices.yaml my Delta Pro occurs. I had to use the service bluetooth_tracker: Update to force scanning, before.
This is working reliably so far.
Now someone should contribute the last and biggest step: Reading from EcoFlow and controlling it via BLE.
It appears that the integration works with firmware v1.0.1.118 in the US.
Hi - sounds good !!
We are using two DeltaPros. One with old firmware (working), the other with the new one.
When having noticed your comment, I instantly installed 1.0.1.18 an restarted HA.
I expected, that HA will find the new instance of DeltaPro #2 when running the next device scan.
3 hours later: not success.
I deactived the integration again - started HA new to make the deactivation valid - actived it & restart.
Now I'm waiting for a successful scan ... waiting ... waiting ...
Do you have a hint for me?
I thought I was having the same problem as you all but it turns out I was using the beta in HACS and not the latest release. I switched to the latest stable release (2.x), deleted the integration from Home Assistant, added it back in with the IP, and everything just worked. Still working right now.
This is hardware I bought last week, so it's brand new and firmware is at the latest. 1 Delta Pro + 2 Extra batteries, all on an IOT vlan.
Thank you kidhasmoxy,
it is working now with ONE of our two EcoFlows. Thank you. With the old firmware, it accepted both EcoFlows.
It's a pity ... we have to find another manufacturer and stop using EcoFlow.
Regards / mike
A rather annoying matter. It still does not work with my DELTA Pro.
Thank you kidhasmoxy,
it is working now with ONE of our two EcoFlows. Thank you. With the old firmware, it accepted both EcoFlows. It's a pity ... we have to find another manufacturer and stop using EcoFlow.
Regards / mike
I suspect the port closure was part of a recent WiFi update that only applied to certain units with a particular WiFi board. I have two "newer" Delta Pro units with 1.0.0.96 firmware that work with this HA integration and one "older" unit on 1.0.1.18 that works with this integration. But I've seen reports of others with .96 where the port is closed...
DELTA Pro: This is the version that I have installed and the integration doesn't work with it.
This is what I have on the DP that is still working with HA integration:
DELTA Pro: This is the version that I have installed and the integration doesn't work with it.
I just upgraded to the same versions (both base and wifi), and my integrations have stopped working too.
Hi @thivyan,
my DELTA Pro has the same problem / board with V3.0.1.11 (Wi-Fi) so i have just communicated this to the EcoFlow support.
We are in contact with EcoFlow-Support since the problem became evident. Meanwhile they received some requests for opening the API-port for HA, which was closed because of "security concerns". That's a joke .. if you have to set up an account on a chinese webserver to control your EF.
It looks like, that after email #5 oder #6, they are now taking our requests more serious. Especially since we told them, that we have delisted EcoFlow as supplier because of that hazzle and didn't place any more orders.
Now we are waiting, what will happen or not.
I'll keep you informed.
Regards - Mike
It looks like, that after email #5 oder #6, they are now taking our requests more serious. Especially since we told them, that we have delisted EcoFlow as supplier because of that hazzle and didn't place any more orders.
A "secure" IoT device is almost an oxymoron... Since monitoring/control of DP via the TCP port does not appear to require any sort of authentication there is, in fact, a "security" issue since anyone who can access the port can control the device...
My suggestion to EF is to provide an advanced setting that allows the user to "enable" the port and provide IP addresses (or ranges) allowed to connect to it. This leaves the average user less vulnerable while giving enthusiasts a way to 'allow' HA (or their own scripts, or other platforms) to access the device...
The MQTT method does require credentials. First, you need an EF account (email/password) then you need to follow a process, using that account, to obtain a separate ID, user, and password which is then used, over an encrypted connection, to login to mqtt.ecoflow.com and subscribe to topics specific to your ID and serial number of the device(s). I've been using this method to integrate SHP and D2 into HA (neither of which have even been supported by this HA integration due to neither ever having an open TCP port)...
I would prefer that all EF devices allow for local LAN access both using the native app and via platforms like HA (either via API or even straight MQTT). Most devices can be locally controlled using BT but the range is limited and in some cases (like SHP) the BT has to be manually activated by pushing a button each time... I don't like "cloud controlled devices" or having to access a server elsewhere in the world to monitor and control a device elsewhere in my own house... and I'm not a fan of EF having both 'all my usage data' as well as the ability to 'control' my devices (SHP is especially concerning in this regard)... Use of the cloud server should be an optional 'feature' the end user can decide to enable if they want to allow remote control or facilitate remote support from EF...
I was persistent with support because of the blocked local port and got the info from Ecoflow support that a reset of this firmware is only possible by sending the device to a repair shop. I received a return label (free of charge) from Ecoflow Support. Device was sent to repair shop and now I'm waiting. The whole procedure can take up to 20 days. I am curious.
Today - after exchanging strongly worded email with a sleeping support - I received an API-code and an API-password to get access to one of our EcoFlow DeltaPros.
Does anyone have a concept, how to use that stuff to get access via API?
@michael5411
You can test the access with a tool called POSTMAN.
And I am using NodeRED with Home Assistant.
@GeorgWolter
Thank you for this very interesting hint. I'm not a software-developer. Therefore I had no trouble to set up an POSTMAN-account and I found entries concerning EcoFlow. But not more ...
How do I get to the point to enter my credentials and get access to my data? I guess, there is a simple way, if you have the account and your know-how :-) ?
@michael5411 keep in mind that the public api has only a tiny amount of data, and is read only. Better than nothing, but a far cry from the original internal api.
@skpow55
Nice! Thank you👍
@michael5411
Postman: Here my examples. I am getting four values for my DELTA Pro:
"code": "0",
"message": "Success",
"data": {
"soc": 31,
"remainTime": 3748,
"wattsOutSum": 0,
"wattsInSum": 0
Yesterday an update of the wifi module appeared.
The port is free again and the integration works.
…how many Entitys?
69 Entitys
…cool! Works with Delta Pro, right? Including ACtemp and ACout+loss?
How old ist your DP?
3 months I bought them in December.
Yes all these Entitys.
My ACtemp rises up to 80°C while Fan=0 (ACoutput 0-140W and DCinput <110W). Same there?
Where do you find the WLAN version number? My app only reports a system version number (1.0.1.18). Is the integration still working.? Mine worked fine until a firmware upgrade broke it. Looks like it still doesn't work for some others.
Where do you find the WLAN version number? My app only reports a system version number (1.0.1.18). Is the integration still working.? Mine worked fine until a firmware upgrade broke it. Looks like it still doesn't work for some others.
I had heard that the most recent update re-opened the port allowing the hassio integration to work again. I cannot confirm as I am still running .96 on 2x DPs and both still work with the hassio integration. I also have full MQTT access to both just in case the local integration (with is much more efficient and reliable) fails.
If you are on the most current version of firmware the firmware page in the app should show both the system and WiFi versions. If a firmware update is available you will only see the current and new version of that specific update (system or WiFi)
@tronron there are version numbers for everything available in the MQTT data but I have not determined how to translate them to what is displayed in the app.
Firmware V1.0.1.67 - V3.0.3.25 Wi-Fi, no cloud intégration is still not working 👎
Firmware V1.0.1.67 - V3.0.3.25 Wi-Fi, no cloud intégration is still not working 👎
@Nekenlight - I'm pretty sure it is the .25 WiFi update that closed the port. Not sure which DPs have WiFi modules that update applies to...
Have you contacted support to see if they will re-open the port or roll back your firmware? They need to stop breaking the HA integration and pushing everything into the cloud while dragging their feet on a decent cloud API (let alone a local one). But we need some sort of group with a loud voice they will pay attention to... May not pay much attention to hacker enthusiasts...