-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Circumvent online requirement for local API access #92
Comments
FWIW, on the River Pro at least it's definitely an Espressif wifi chip -- probably an ESP32 -- based on the MAC address. |
I'm experiencing the same issue with the Delta Pro. It appears that as soon as internet access is lost or restricted, the Delta Pro stops TCP communications locally, making true "local" control impossible. From my investigation, it seems that the device requires ongoing communication with both Here's what I've tried so far, which feels like progress, but I haven't fully solved it yet:
The communication appears to be serial, and the traffic seems unencrypted. From what I've seen, EcoFlow's server mainly responds with ACK packets. The challenge I'm facing is that if the Delta Pro doesn't receive the correct ACKs from the server, it retries a few times and then stops TCP communications altogether. Generating the proper ACK responses seems to be the key, but I haven't quite nailed it yet. If anyone has deeper insights or suggestions, especially around properly emulating those ACK responses or maintaining the connection locally, I'd love to hear your thoughts! |
This thread is quite active: nielsole/ecoflow-bt-reverse-engineering#2 From it, we can learn that EcoFlow is able to deploy proper cryptography. So I would not be surprised if this TCP traffic which goes over the Internet is a kind of cryptographicly signed kill switch. |
The last comments on #69 (comment) got me thinking. Even when EcoFlow is kind enough to "push" 3.0.2.21 on individual request, it does not give us full offline control.
I guess we need to put more effort into it if we want to have that.
From the changelog we can conclude that most of the work is done by the main firmware. The Wi-Fi firmware only does Bluetooth, Wi-Fi and Internet connectivity. So we can either disable that module somehow and directly speak to the chip with the main firmware on it. The hope would be that the protocol is similar or identical to what is already implemented. Or if the Wi-Fi module is something common like a ESP32, we could even write a Open Source firmware for that. I did a quick check. At least I don’t know/have found ESP32 modules like WROOM with the chip pin layout of the picture below. Finding an ESP32 in the DELTA Pro would have been my hope.
Not sure when I come around to teardown my DELTA Pro again to see what can be done. I wanted to create this issue to keep the other issues focused.
Picture of the Wi-Fi module:
Source: https://youtu.be/lagxSrPeoYg?t=968
The text was updated successfully, but these errors were encountered: