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
Integration Broken Delta Pro afer Firmware Update // Ideas for solution #60
Comments
Good idea! |
Hi @fogfon 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, |
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 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:
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. |
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.
|
Sounds promising! I assume "App updates" means that they will reopen
port 8055 hopefully.
…On 10/21/2022 9:34 AM, mtegen wrote:
App updates
|
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. |
For Workaround see here vwt12eh8/hassio-ecoflow#60 (comment)
Hello, @nuppls I can confirm your workaround works with DeltaMax! |
Hi, @franki29, does this work for you without connected EcoFlow app? |
Hi @fogfon , basically it is working like @vwt12eh8 solution, just a little bit simpler and not so professional. |
https://github.com/nielsole/ecoflow-bt-reverse-engineering |
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. |
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. |
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:
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. |
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. 3 hours later: not success. I deactived the integration again - started HA new to make the deactivation valid - actived it & restart. 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. Regards / mike |
A rather annoying matter. It still does not work with my DELTA Pro. |
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... |
I have the same version on my Delta Pro and the integration works.
…On Thu, Nov 24, 2022 at 8:54 PM Ne0-Hack3r ***@***.***> wrote:
This is what I have on the DP that is still working with HA integration:
[image: image]
<https://user-images.githubusercontent.com/110427837/203884721-70447bca-fa52-4029-a311-2f3749110d80.png>
—
Reply to this email directly, view it on GitHub
<#60 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAJCASRFK53UCOVIVZNQH3WKAL6NANCNFSM6AAAAAAQ67OFR4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi @thivyan, |
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. |
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 |
@GeorgWolter 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. |
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
<#60 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AS75SI6M6SSTKSKSVRGHB7TWPLYU7ANCNFSM6AAAAAAQ67OFR4>.
You are receiving this because you commented.Message ID:
***@***.***>
|
@skpow55 |
@michael5411
|
…how many Entitys? |
69 Entitys |
…cool! Works with Delta Pro, right? Including ACtemp and ACout+loss? |
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. |
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 👎 |
@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... |
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
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.
The text was updated successfully, but these errors were encountered: