hassio-ecoflow: Integration Broken Delta Pro afer Firmware Update // Ideas for solution

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…

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)

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.

It appears that the integration works with firmware v1.0.1.118 in the US.

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

Yesterday an update of the wifi module appeared. The port is free again and the integration works.

Take a look at the MQTT option for Home Assistant.  it will provide much more data if not all of it.  Note that this is still under development by the developer…  Simply run the shell script to obtain your config info from the Ecoflow MQTT server and follow the directions as provided to setup the config in Home Assistant.

https://github.com/mmiller7/ecoflow-withoutflow/tree/main/cloud-mqtt

On 12/27/2022 7:57 AM, Thiv wrote:

@michael5411 https://github.com/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.

— Reply to this email directly, view it on GitHub https://github.com/vwt12eh8/hassio-ecoflow/issues/60#issuecomment-1365920175, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS75SI6M6SSTKSKSVRGHB7TWPLYU7ANCNFSM6AAAAAAQ67OFR4. You are receiving this because you commented.Message ID: @.***>

@kidhasmoxy

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?

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.