Commands #1
Comments
Heartbeat Package
Delta Heartbeat Package (extends Heartbeat Package)
River Heartbeat Package (extends Heartbeat Package)
River Mini Heartbeat Package (extends Heartbeat Package)
|
I can confirm the mobile app when using v3 servers protocol connects to Username is named as This is what the application gets: MPTT status {
"id": ##########,
"params": {
"latestTimeStamp": 1652835724751,
"mppt.carOutAmp": 0,
"mppt.carOutVol": 0,
"mppt.carOutWatts": 0,
"mppt.carState": 0,
"mppt.carTemp": 0,
"mppt.cfgChgType": 0,
"mppt.cfgDcChgCurrent": 8000,
"mppt.chgPauseFlag": 0,
"mppt.chgState": 0,
"mppt.chgType": 0,
"mppt.dc24vState": 1,
"mppt.dc24vTemp": 24,
"mppt.dcdc12vAmp": 0,
"mppt.dcdc12vVol": 0,
"mppt.dcdc12vWatts": 0,
"mppt.faultCode": 0,
"mppt.inAmp": 0,
"mppt.inVol": 0,
"mppt.inWatts": 0,
"mppt.mpptTemp": 23,
"mppt.outAmp": 1,
"mppt.outVol": 494,
"mppt.outWatts": 7,
"mppt.reserved": [
0
],
"mppt.swVer": 50397200,
"mppt.xt60ChgType": 0
},
"timestamp": 1652835724751,
"version": "1.0"
}Energy system status {
"id": ##########,
"params": {
"ems.bms0Online": 3,
"ems.bms1Online": 0,
"ems.bms2Online": 0,
"ems.bmsModel": 1,
"ems.bmsWarningState": 0,
"ems.chgAmp": 1000,
"ems.chgCmd": 1,
"ems.chgRemainTime": 143999,
"ems.chgState": 3,
"ems.chgVol": 45000,
"ems.dsgCmd": 1,
"ems.dsgRemainTime": 8292,
"ems.emsIsNormalFlag": 1,
"ems.f32LcdShowSoc": 85.83515,
"ems.fanLevel": 0,
"ems.lcdShowSoc": 86,
"ems.maxAvailableNum": 1,
"ems.maxChargeSoc": 80,
"ems.maxCloseOilEbSoc": 94,
"ems.minDsgSoc": 8,
"ems.minOpenOilEbSoc": 20,
"ems.openBmsIdx": 1,
"ems.openUpsFlag": 1,
"ems.paraVolMax": 50726,
"ems.paraVolMin": 49126,
"latestTimeStamp": 1652835724715
},
"timestamp": 1652835724715,
"version": "1.0"
}BMS status {
"id": #########,
"params": {
"bmsMaster.amp": -337,
"bmsMaster.bmsFault": 0,
"bmsMaster.bqSysStatReg": 128,
"bmsMaster.cellId": 2,
"bmsMaster.cycles": 6,
"bmsMaster.designCap": 80000,
"bmsMaster.errCode": 0,
"bmsMaster.f32ShowSoc": 85.83549,
"bmsMaster.fullCap": 75998,
"bmsMaster.inputWatts": 0,
"bmsMaster.maxCellTemp": 25,
"bmsMaster.maxCellVol": 3329,
"bmsMaster.maxMosTemp": 25,
"bmsMaster.minCellTemp": 25,
"bmsMaster.minCellVol": 3323,
"bmsMaster.minMosTemp": 25,
"bmsMaster.num": 0,
"bmsMaster.openBmsIdx": 1,
"bmsMaster.outputWatts": 0,
"bmsMaster.remainCap": 65233,
"bmsMaster.remainTime": 0,
"bmsMaster.soc": 86,
"bmsMaster.soh": 0,
"bmsMaster.sysVer": 16777298,
"bmsMaster.tagChgAmp": 48000,
"bmsMaster.temp": 25,
"bmsMaster.type": 1,
"bmsMaster.vol": 49921,
"latestTimeStamp": 1652835724716
},
"timestamp": 1652835724716,
"version": "1.0"
}Power delivery status {
"id": ##########,
"params": {
"latestTimeStamp": 1652835724679,
"pd.beepState": 1,
"pd.carState": 0,
"pd.carTemp": 0,
"pd.carUsedTime": 86809,
"pd.carWatts": 0,
"pd.chgPowerAc": 359398,
"pd.chgPowerDc": 4,
"pd.chgSunPower": 1291,
"pd.dcInUsedTime": 139,
"pd.dcOutState": 1,
"pd.dsgPowerAc": 342805,
"pd.dsgPowerDc": 902,
"pd.errCode": 0,
"pd.ext3p8Port": 0,
"pd.ext4p8Port": 0,
"pd.extRj45Port": 0,
"pd.iconAcFreqMode": 1,
"pd.iconAcFreqState": 0,
"pd.iconBmsErrMode": 0,
"pd.iconBmsErrState": 0,
"pd.iconBmsParallelMode": 0,
"pd.iconBmsParallelState": 0,
"pd.iconBtMode": 0,
"pd.iconBtState": 0,
"pd.iconCarMode": 1,
"pd.iconCarState": 0,
"pd.iconChgStationMode": 0,
"pd.iconChgStationState": 0,
"pd.iconCoGasMode": 0,
"pd.iconCoGasState": 0,
"pd.iconEcoMode": 0,
"pd.iconEcoState": 0,
"pd.iconFactoryMode": 0,
"pd.iconFactoryState": 0,
"pd.iconFanMode": 0,
"pd.iconFanState": 0,
"pd.iconGasGenMode": 0,
"pd.iconGasGenState": 0,
"pd.iconHiTempMode": 0,
"pd.iconHiTempState": 0,
"pd.iconInvParallelMode": 0,
"pd.iconInvParallelState": 0,
"pd.iconLowTempMode": 0,
"pd.iconLowTempState": 0,
"pd.iconOverloadMode": 0,
"pd.iconOverloadState": 0,
"pd.iconPackHeaterMode": 0,
"pd.iconPackHeaterState": 0,
"pd.iconRcMode": 0,
"pd.iconRcState": 0,
"pd.iconRechgTimeMode": 0,
"pd.iconRechgTimeState": 0,
"pd.iconSocUpsMode": 1,
"pd.iconSocUpsState": 0,
"pd.iconSolarBracketMode": 0,
"pd.iconSolarBracketState": 0,
"pd.iconSolarPanelMode": 0,
"pd.iconSolarPanelState": 0,
"pd.iconTransSwMode": 0,
"pd.iconTransSwState": 0,
"pd.iconTypecMode": 0,
"pd.iconTypecState": 0,
"pd.iconUsbMode": 0,
"pd.iconUsbState": 0,
"pd.iconWifiMode": 0,
"pd.iconWifiState": 0,
"pd.iconWindGenMode": 0,
"pd.iconWindGenState": 0,
"pd.iconWirelessChgMode": 0,
"pd.iconWirelessChgState": 0,
"pd.invUsedTime": 3760241,
"pd.lcdBrightness": 141,
"pd.lcdOffSec": 300,
"pd.model": 1,
"pd.mpptUsedTime": 3642,
"pd.qcUsb1Watts": 0,
"pd.qcUsb2Watts": 0,
"pd.remainTime": 8292,
"pd.soc": 86,
"pd.standByMode": 120,
"pd.sysChgDsgState": 1,
"pd.sysVer": 16908346,
"pd.typccUsedTime": 37720,
"pd.typec1Temp": 24,
"pd.typec1Watts": 0,
"pd.typec2Temp": 25,
"pd.typec2Watts": 0,
"pd.usb1Watts": 0,
"pd.usb2Watts": 0,
"pd.usbUsedTime": 4687,
"pd.usbqcUsedTime": 17151,
"pd.wattsInSum": 312,
"pd.wattsOutSum": 312,
"pd.wifiAutoRcvy": 0,
"pd.wifiRssi": 0,
"pd.wifiVer": 774,
"pd.wirelessWatts": 0
},
"timestamp": 1652835724679,
"version": "1.0"
}Inverter status {
"id": #################,
"params": {
"inv.acDipSwitch": 2,
"inv.acInAmp": 0,
"inv.acInFreq": 60,
"inv.acInVol": 123183,
"inv.acPassByAutoEn": 1,
"inv.cfgAcEnabled": 1,
"inv.cfgAcOutFreq": 2,
"inv.cfgAcOutVoltage": 120000,
"inv.cfgAcWorkMode": 0,
"inv.cfgAcXboost": 0,
"inv.cfgFastChgWatts": 0,
"inv.cfgSlowChgWatts": 1800,
"inv.cfgStandbyMin": 0,
"inv.chargerType": 0,
"inv.chgPauseFlag": 0,
"inv.dcInAmp": 0,
"inv.dcInTemp": 23,
"inv.dcInVol": 0,
"inv.dischargeType": 1,
"inv.errCode": 0,
"inv.fanState": 1,
"inv.inputWatts": 337,
"inv.invOutAmp": 2814,
"inv.invOutFreq": 60,
"inv.invOutVol": 122613,
"inv.invType": 0,
"inv.outTemp": 23,
"inv.outputWatts": 337,
"inv.sysVer": 33620289,
"latestTimeStamp": 1652835724751
},
"timestamp": 1652835724751,
"version": "1.0"
} |
|
@ticpu That looks like it is everything and more than I had hope it would be, thank you for digging into that. This is the first time I have played with MQTT and I'm trying to connect using MQTT Explorer and I can't see to configure it connect with the path Edit: I have got to the point where I am just getting the error "Connection refused: Bad username or password". I have tried my account password, I'm guessing there is some meta data in the app after it has authenticated to give a new username and password to connect to MQTT? Edit 2: I have managed to obtained the username/password, who knew android logs could be so helpful :) I have managed to connect to the Ecoflow MQTT server now but I don't see any topics. Unsure where I am going wrong atm. Edit 3: Got it, MQTT topic names are case sensative and I had put the serial number in lower case, it needed to be upper case. |
|
it looks as though the commands to turn on and off things like DC and AC are also done with MQTT based on what I am seeing in the logs: Turning DC On: Turning DC Off: I am assuming here that ID 81 is DC I do think it is being published to a different topic though. Here are the topics I can see in the logs:
The ###### is a 20 digit number, perhaps some kind of account ID? |
|
I have successfuly got the data going into InfluxDB using fairly simple Telegraf config using MQTT Consumer and JSON v2: [[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
## API token for authentication.
token = "<token>"
organization = "<org>"
bucket = "<bucket>"
[[inputs.mqtt_consumer]]
servers = ["mqtts://mqtt.ecoflow.com:8883"]
topics = [
"/app/device/property/<serial number>",
]
## If unset, a random client ID will be generated.
# client_id = ""
## Username and password to connect MQTT server.
username = "<username>"
password = "<password>"
data_format = "json"
[[inputs.file]]
data_format = "json_v2"
[[inputs.file.json_v2]]
timestamp_path = "timestamp"
timestamp_format = "unix"
[[inputs.file.json_v2.object]]
path = "params"Only problem I have right now is that watts provided by the Delta Pro are have 1 decimal place effectively making the number of watts 10 times higher than it should be. |
|
This is the current login sequence to be able to get the mqtt
This returns a response with a This will return a response with a body like: Would love to know if/when anyone has a working home assistant setup using this mqtt data. |
|
That looks like a standard OAuth2 API login to me, nice and easy to integrate with :) @mtb-ninja I would like to do a home assistant setup if I can, I'm not familar with it though and is why I am doing the InfluxDB so I at least get pretty graphs. |
|
Hi , there is a implementation without mqtt by https://github.com/vwt12eh8/hassio-ecoflow for home assistant. I have a delta mini and I like to use the heartbeat packages with node red. I already discovered that packages that begins with AA 02 6F. Byte 33 & 34 is the watt information from the solar panel and byte 30 seems to bet the actual % of the battery. Byte 31 & 32 the AC out usage. But I like to get more information out of the packages. Can you tell me how did you find the information about the heartbeat packages? |
|
@franki29 OOoh I had been looking for something like that with home assitant, I am definetly going to have to check that out. As for the Heartbeat info I decompiled the APK (downloaded from the Ecoflow website) using http://www.javadecompilers.com/apk/ it is a little tricky to read as the decompile isn't great but it is enough to start picking out objects, I have not yet managed to find the part that actually reads the binary stream into the objects though. |
|
Hi mattwells, thanks for the information. I tried also with jadx, but as I am not familiar with coding, it did not help a lot. I have to correct myself with the information regarding the Watt usage : Byte 33 & 34 is the watt input in total, no matter if I charge from AC or Solar panel. This is maybe only for the delta mini. I tried to figure out in the app how they are switching on/off the 12V DC and the AC output. No way to find it in the decompiled app for me. But with the direct connection to the device and a network sniffer I could find the required sequence to send. Here the buffer values that has to be send for the delta mini with node red: ["0xaa","0x02","0x01","0x00","0xa0","0x0d","0x00","0x00","0x00","0x00","0x00","0x00","0x20","0x05","0x20","0x51","0x01","0x0f","0x02"] 12V DC out on ["0xaa","0x02","0x07","0x00","0xde","0x0d","0x00","0x00","0x00","0x00","0x00","0x00","0x20","0x04","0x20","0x42","0x00","0xff","0xff","0xff","0xff","0xff","0xff","0x2e","0xe8"] AC out off ["0xaa","0x02","0x07","0x00","0xde","0x0d","0x00","0x00","0x00","0x00","0x00","0x00","0x20","0x04","0x20","0x42","0x01","0xff","0xff","0xff","0xff","0xff","0xff","0x3e","0x28"] AC out on Maybe you find a way to figure out the values for other commands looking into the app. I could find parts of it in the class com.ecoflow.common.command.DirectDeviceCommand |
|
No problem Frank, I'm really glad that you are finding it useful. A few other things that I have noticed is that the MPPT side of things, despite the properties being called Watts, Amps and Volts are actually deciwatts, deciamps and centivolts, you have to devide them by 10 or 100 to actually have them in actual watts, amps and volts. As a side note, I do enjoy seeing the MPPT Watts in and Watts out, you can see how effeciant the MPPT conversion is. In regards to the BMS the cell voltage is actually in milivolts. The PD time remain is in minutes, I haven't looked very hard but I haven't noticed anything explicitly saying weather it is charging or discharging but I would expect there is a boolean flag on one of the PD properties. Tempuratures are all in celcious. Inverter uses watts. It must have been fun fixing all these values in the app rather than picking a standard... |
|
Hi mattwells, thanks for the information. It look like I could detect also the MPPT packets. In my case they are in the packets that starts with AA 02 42 starting at byte 24 with inVolt Br. Frank |
Hey, is this still working? When I send a HTTP post to https://api.ecoflow.com/auth/login I get following error: |
|
I personally never managed to get that endpoint to work myself. I grabbed my credentials from the Android logs while using the app. |
|
OK. It is now working as well. Under iOS it is a little bit problematic. But I got the credentials with the help of Charles. https://www.heise.de/ratgeber/Schnueffel-Apps-finden-3986944.html?seite=5 Now I get all messages into my IPSymcon installation. |
|
@mattwells did you figure out how to send commands via mqtt or Is it not possible? |
Sorry I didn't really try it, I suspect that you can do so but by the time I was looking into doing that I had come across Ecoflow Hassio which did everything I wanted. |
|
@mattwells Hi, what app did you use to find the logs from the app on android? I can't figure out how to get certificateAccount / certificatePassword. I'm trying to figure it out because my hassio-ecoflow stopped working(because of a firmware update) Thanks. |
|
I didn't use an app (although there may be one), its something you do with ADB (Android Debug Bridge) a quick search for a guide brought up this page which looks like what I do https://yoodley.com/view-and-examine-android-logs/ |
|
Thanks. I will try it. |
Yes, I was thinking about this solution as well, but with new firmware ecoflow has closed port 8055 :-( |
I am aware but thankfully I didn't upgrade my firmware yet, but I really hope it can be sorted soon, now I have had a taste of HA with Ecoflow I don't want to give it up |
You forgot about |
Yep, it doesn't expire, I'm using it since one week and collecting all info to InfluxDB, then viewing in grafana. It's nice that I see voltage of solar panel and amps (app shows only Watts only if >=15W) |
|
PreEdit: I replied and realised that I wasn't really answer the question being asked, I have limited time at the moment I would like to get back onto this project if I see questions I can answer I will try and make time for them. Need to get back to work now >.<
Love it, that is what I was trying to do but I couldn't quite work out how to do it as I hadn't played with MQTT before.
It is the device's serial number, using capital letters, for the subscription. If you have multiple devices you have to subscribe to them individually:
The one you want to use to get information from the device is I haven't tried doing control over MQTT though so I am unsure how this would work.
I actually decompiled the Android app to find them. As for the serial number if you go into the app on your phone once you have it connected go to the device, clock the cog in the top right, then go to the Specifications menu open and it is at the top of the screen prefixed with |
|
Thanks for putting this together! I recently picked up a Delta Max, had it integrated in HA for 1 day, updated the firmware and man do I regret that now. Anyway, after writing an angry email to Ecoflow about the local API, I managed to get this all working! Here are the sensors I ended up creating: mqtt:
sensor:
- name: "Delta Max ***NUMBER*** Battery (mqtt)"
unique_id: "delta_max_***NUMBER***_battery_mqtt"
state_topic: "ecoflow/***NUMBER***"
unit_of_measurement: "%"
state_class: "measurement"
value_template: >
{% if value_json['params']['ems.lcdShowSoc'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_battery_mqtt') }}
{% else %}
{{ value_json['params']['ems.lcdShowSoc'] | int(0)}}
{% endif %}
- name: "Delta Max ***NUMBER*** AC Charge Speed (mqtt)"
unique_id: "delta_max_***NUMBER***_ac_charge_speed_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "power"
unit_of_measurement: "W"
state_class: "measurement"
value_template: >
{% if value_json['params']['inv.cfgSlowChgWatts'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_ac_charge_speed_mqtt') }}
{% else %}
{{ value_json['params']['inv.cfgSlowChgWatts'] | int(0)}}
{% endif %}
- name: "Delta Max ***NUMBER*** AC Input (mqtt)"
unique_id: "delta_max_***NUMBER***_ac_input_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "power"
unit_of_measurement: "W"
state_class: "measurement"
value_template: >
{% if value_json['params']['inv.inputWatts'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_ac_input_mqtt') }}
{% else %}
{{ value_json['params']['inv.inputWatts'] | int(0)}}
{% endif %}
- name: "DELTA Max ***NUMBER*** Total Output (mqtt)"
unique_id: "delta_max_***NUMBER***_total_output_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "power"
unit_of_measurement: "W"
state_class: "measurement"
value_template: >
{% if value_json['params']['pd.wattsOutSum'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_total_output_mqtt') }}
{% else %}
{{ value_json['params']['pd.wattsOutSum'] | int(0)}}
{% endif %}
- name: "DELTA Max ***NUMBER*** Total Input (mqtt)"
unique_id: "delta_max_***NUMBER***_total_input_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "power"
unit_of_measurement: "W"
state_class: "measurement"
value_template: >
{% if value_json['params']['pd.wattsInSum'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_total_input_mqtt') }}
{% else %}
{{ value_json['params']['pd.wattsInSum'] | int(0)}}
{% endif %}
- name: "DELTA Max ***NUMBER*** Total Output Energy (mqtt)"
unique_id: "delta_max_***NUMBER***_total_output_energy_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "energy"
unit_of_measurement: "Wh"
state_class: "total_increasing"
value_template: >
{% if value_json['params']['pd.dsgPowerAc'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_total_output_energy_mqtt') }}
{% else %}
{{ value_json['params']['pd.dsgPowerAc'] | int(0)}}
{% endif %}
- name: "DELTA Max ***NUMBER*** Total Input Energy (mqtt)"
unique_id: "delta_max_***NUMBER***_total_input_energy_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "energy"
unit_of_measurement: "Wh"
state_class: "total_increasing"
value_template: >
{% if value_json['params']['pd.chgPowerAc'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_total_input_energy_mqtt') }}
{% else %}
{{ (value_json['params']['pd.chgPowerAc'] | int(0)) + (value_json['params']['pd.chgPowerDc'] | int(0))}}
{% endif %}
- name: "DELTA Max ***NUMBER*** Main Battery Cycles (mqtt)"
unique_id: "delta_max_***NUMBER***_main_battery_cycles_mqtt"
state_topic: "ecoflow/***NUMBER***"
state_class: "measurement"
icon: mdi:battery-heart-variant
value_template: >
{% if value_json['params']['bmsMaster.cycles'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_main_battery_cycles_mqtt') }}
{% else %}
{{ value_json['params']['bmsMaster.cycles'] | int(0)}}
{% endif %}
- name: "DELTA Max ***NUMBER*** MPPT Input Watts (mqtt)"
unique_id: "delta_max_***NUMBER***_input_mppt_watts_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "power"
unit_of_measurement: "W"
state_class: "measurement"
value_template: >
{% if value_json['params']['mppt.inWatts'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_input_mppt_watts_mqtt') }}
{% else %}
{{ value_json['params']['mppt.inWatts'] | int(0) / 10 }}
{% endif %}
- name: "DELTA Max ***NUMBER*** MPPT Input Energy (mqtt)"
unique_id: "delta_max_***NUMBER***_mppt_input_energy_mqtt"
state_topic: "ecoflow/***NUMBER***"
device_class: "energy"
unit_of_measurement: "Wh"
state_class: "total_increasing"
value_template: >
{% if value_json['params']['pd.chgSunPower'] | int(-1) == -1 %}
{{ states('delta_max_***NUMBER***_mppt_input_energy_mqtt') }}
{% else %}
{{ value_json['params']['pd.chgSunPower'] | int(0)}}
{% endif %}
binary_sensor:
- name: "Delta Max ***NUMBER*** Charging (mqtt)"
unique_id: "delta_max_***NUMBER***_charging_mqtt"
state_topic: "ecoflow/***NUMBER***"
payload_on: "1"
payload_off: "0"
value_template: >
{{ value_json['params']['inv.chargerType'] | default(0, true) | int(0) }}
- name: "Delta Max ***NUMBER*** Fan (mqtt)"
unique_id: "delta_max_***NUMBER***_fan_mqtt"
state_topic: "ecoflow/***NUMBER***"
payload_on: "1"
payload_off: "0"
value_template: >
{{ value_json['params']['inv.fanState'] | default(0, true) | int(0) }}
I wanted to put my solar back into the Energy dashboard so I made 2 sensors for MPPT input and input energy. I also added a binary sensor for the fan as I may want to use this to turn on an external fan. I also made a change to the input energy sensor so that it adds AC and DC input energy fields together. Anyways, it all seems to be working but I am hoping the local API comes back soon. I hate depending on the cloud :/ |
|
I've removed a few comments I've made on this thread in line with some others who have done the same. As a result, you'll see quotes from comments that don't appear to be sourced from any comment in this thread. We all hope to put the information back here sooner rather than later as we realise people are looking for a solution after updating their firmware. |
|
@lambro690 local api support was disabled even on offline mode? Or offline mode is still working? I still have the unit, but I'm sorry I almost hadn't had time since created this github 😪😩 |
Servers were down for most of a day. I assume your stuff is working again at this point, yes? |
|
Hi there, thanks both @hardy and @neo .. indeed I contacted ecoflow support and they said where doing some maintenance/upgrades. So the above was a false alarm. The thing is I have a different kind of problem now that I would like to ask you about . My bridge at some point (feels like its every 15-20 minutes) stops receiving updates from the topic and it only works again if/when I "open" the mobile app. It looks as if it gets stuck or sleeps and when a topic pub reaches the mqtt server it wakes again. Any ideas? Anyone else with the same issue? BR, |
I have started having the same problem - starting on or about 18th June. I added these two configuration lines to my After adding the above, if I restart the Mosquitto add-on in HA but do not open then app on my phone, the bridge connection continues to work for ~10 hours before it times out and disconnects. Restart Mosquitto and I get the same again. If I restart Mosquitto, the connection works as above, but if I then open the app on my phone and then close it or let my phone go to sleep, the bridge connection stops receiving updates within a minute or so. A little disappointing this has started to happen. |
|
Hi lwsbrts, in your case I would schedule a mosquitto restart to happen every 5-10 hours. Unfortunately what I experience is not the same. Mine receives updates when the app is active and when it's not it stops after a few minutes. So far I tried scheduling a mosquitto restart every 1 minute which makes it a bit better. When the bridge comes up it receives messages for around 50" .. so it's not that bad. I also tried scheduling a mosquitto_pub to check the senario that if something gets published in the TOPIC the bridge would get "unstuck"... unfortunately that doesn't seem to make things any better. Looking forward to hearing from the rest of the group. BR, |
|
Not seeing this behavior though I did notice strange DNS issues a couple days ago related to ecoflow.com... But I've not been losing connection and during the DNS issues only new connections appeared to be effected. However, I do tend to leave the app open to SHP and DPs on Android emulators a good portion of time... |
|
By all accounts, others are having the same issue with disconnects as I've described above. Another integration author has implemented disconnect logic recently to reconnect to account for this new issue. That integration: https://github.com/tolwi/hassio-ecoflow-cloud If I don't open the app, the bridge connection via Mosquitto works fine. |
This might make sense as in MQTT the client id is supposed to be unique, i.e. when the same client id connects twice, the old connection is force-closed. Did you copy the ID from the app or did you generate a random UUID? |
|
I started having the disconnect problem yesterday (8/28/23) and came looking for help. I added @lwsrbrts's mosquitto.conf code addition just now and restarted the MQTT add-on. So far, so good. But it's only been a few minutes. :) If the answer is to remember to restart MQTT if you have to use the Ecoflow app, I can live with that. |
In fact I wrote a PowerShell script that would do exactly that :) vwt12eh8/hassio-ecoflow#26 (comment) |
I still occasionally need to open the Ecoflow app but having realised that I was doing it and then having to force close Ecoflow, wait a minute or so and then faff with Home Assistant to restart the MQTT addon, I decided to create an automation. It waits until the alias: Smart Home Panel not updating notification
description: ""
trigger:
- platform: template
value_template: >-
{{ now() - states.sensor.shp_circuit_1_power.last_changed >= timedelta
(minutes=5) }}
id: power_info_stale
- platform: event
event_type: mobile_app_notification_action
event_data:
action: restart_mqtt_addon
context: {}
id: restart_mobile_notification
condition: []
action:
- choose:
- conditions:
- condition: trigger
id:
- power_info_stale
sequence:
- service: notify.mobile_app_pixel_6_pro
data:
message: Power information for Smart Home Panel circuits is stale.
title: "WARN: Stale power data"
data:
color: "#800000"
sticky: true
tag: shp-stale-data
notification_icon: mdi:transmission-tower-off
actions:
- action: restart_mqtt_addon
title: Restart MQTT Addon
- conditions:
- condition: trigger
id:
- restart_mobile_notification
sequence:
- service: hassio.addon_restart
data:
addon: core_mosquitto
mode: single |
|
@lwsrbrts I regularly open the app and occasionally a separate MQTT Explorer session to mqtt.ecoflow.com and, thus far, have not see this issue. I do use totally unique random client IDs for each instance (app vs mosquito vs MQTT Explorer) prepended with 'ANDROID_' I assume you are using unique client IDs on everything as well and have tried generating new GUIDs for UUID, etc? Hoping I continue to stay immune to this issue but also curious if something in my setup has created this 'immunity'. Would certainly be nice if we could get everyone 'inoculated'. |
|
Did someone already tried the MQTT interface on a PowerStream inverter device? hexdump looks the following (edited S/N): 00000080 0A 3D 0A 03 08 D8 04 10 20 18 35 20 01 28 01 38 .=...... .5 .(.8 I'm going to check if it is just a compressed json or something simmiliar. As the app must also understand it, it might be possible to get it out of the android app. |
I appear to be experiencing something like this now. I've had a couple cases of MQTT going silent. I just now opened the app and data flow resumed (did not reboot or reconnect Mosquito). Soon after closing the app the data flow stopped again. Restarted Mosquito at that point and data updates are back and seem to be solid again. This is the 2nd time I've seen updates cease in the past couple weeks. Not sure if connection is going stale, server is imposing some sort of timeout, or something else is going on... I sure wish we better understood the nature of "what changed" since I don't think any of us had these issues when we first started tapping into mqtt.ecoflow.com |
|
I've been looking more into this now very annoying issue. When updates cease on my dashboard and I then connect to my local broker (Mosquito) via MQTT Explorer I can see that nothing new is appearing on my side of the bridge. If I leave that connection open and then connect a second instance of MQTT Explorer to mqtt.ecoflow.com (using a different client ID than what Mosquito is using of course) data starts posting to the monitored topics on both sides. If I then close the mqtt.ecoflow.com connection data ceases (same if you open the app and then close it). I'm not sure what is triggering this or if there has been a change on the server side but I'm wondering if in fact something changed with Mosquito... ... Any chance an update to Mosquito was installed prior to this problem cropping up? I have done some updates to Mosquito recently which have not helped but I'm not sure exactly when the problem started on my end. When you first mentioned it I was not experiencing it at all then more recently I am experiencing it. Now I'm wondering if you simply updated Mosquito a few weeks before I did... |
|
I have dealt with this issue by setting a relatively short silence timeout, if there is no new data for about 10s then the client reconnects to MQTT and everything works OK. Since my Prometheus collection interval is 30s the reconnects are not visible and are not affecting the graph at all. Upon reconnection the client requests all data from the devices so no updates are lost. |
|
When it started happening to me, I hadn't made any changes to Mosquitto in HA OS at all. I have since, like you, updated Mosquitto a couple of times when offered the update via HA OS but that hasn't made any change to how the connection is behaving. I see exactly the same as you:
My automation above sorts out the resolution for me now but before that I would swipe the app away, wait 30 seconds and then restart Mosquitto in HA to reconnect the bridge. This is the top section of my current connection ecoflow-bridge
address mqtt.ecoflow.com:8883
remote_username [removed]
remote_password [removed]
cleansession true
remote_clientid [removed]
try_private true
# Fix disconnects?
start_type automatic
restart_timeout 30 180
persistence true
bridge_insecure false
bridge_protocol_version mqttv311
bridge_tls_version tlsv1.2
bridge_cafile /etc/ssl/certs/ca-certificates.crt
[removed]The disconnects section I added while troubleshooting, but it doesn't kick the connection back in to life per my testing. Since it wasn't hurting, I just left it there. |
|
I tried similar things in mosquito.conf and I also setup an automation that posts a request for ‘latestquotas’ to ../get every 30 seconds. When this condition occurs the connection from Mosquito to cloud server stays in tact and I see responses on ../getreply — I can also post commands to ../set but nothing seems to trigger status data to start posting again short of restarting Mosquito. I suppose this would tend to point the finger at changes on the cloud server. I just find it odd that I noticed no issues until quite recently while you and others noticed it much earlier. The question of “what changed” continues to plague me. |
|
Ich lade die Ecoflow Delta 2 abhängig vom aktuellen Solarüberschuß im Haus über den A/C Eingang. Der AC-Eingang wird entweder über einen Shelly ganz abgeschaltet (< 200W) oder die Ladeleistung je nach Höhe des Überschusses per MQTT: acChgCfg und chgWatts geregelt. Ich habe die Befürchtung, daß zu viele An-/Abschaltungen des AC-Eingangs durch den Shelly evtl. schädlich für den AC-Eingang der Ecoflow sind und würde gerne die AC-Ladung über chgPauseFlag schalten. Bei der Änderung der Ladeleistung in der App wird neben acChgCfg und chgWatts jedesmal auch chgPauseFlag : 255 gesendet. Eine manuelle Änderung von chgPauseFlag über MQTT (z.B: auf 0) hat aber leider keinen Effekt und die Ecoflow lädt munter weiter über AC. Hat das Pausieren des Ladevorgangs über chgPauseFlag schon jemand hinbekommen? |
|
you could try my NodeRed flow. It might help you, how I handle this. it´s not perfect yet, but functional ;) Details
but in general you need to change the charge limit (max_charge_level) to a value under your actual SoC and ac_charging_power to 100 ( it will charge with 120W) to pass throught from the grid. if the SoC is below max_charge_level to reach the level again. |
|
Thank you! I'll give it a try at the weekend. Which package are the nodes 'api-current-state' and 'api-call-service' from. I guess one of the Home Assistant pallettes? |
|
yes, it´s "node-red-contrib-home-assistant-websocket" |
|
Your flow is pretty much exactly, what I need for the Ecoflow charging cycle. Especially the 'current state' node with the possibility to determine a time frame for a value to be consistently under/over a certain threshold is awesome. However, I do not run a HomeAssistant server - is there somewhere a similar node for mqtt input? |
|
Yes, there are mqtt in and mqtt out nodes in the network section. So you should be able to adjust it. Here is my previous version with setting charge limit with mqtt. So maybe it will inspire you. Details
|
|
Has anyone noticed a change in how the MQTT reporting works? My Delta Max 2000 just got a firmware update and seems to no longer be publishing anything to the "data" topic unless the app is open, and I can't figure out how the battery "knows" if the app is open or not? And closing the app it stops sending after just a few seconds. I saw others having issues a few months ago, but mine didn't start acting up until after the firmware update tonight. Similar thing, only getting updates published if the app is open on a device. I don't have to restart anything so MQTT isn't dropping, I just need the app left open. Yes, using a unique random UUID. Wondering if we need some kind of keepalive or heartbeat topic published required to let the servers know the client is still active? |
Technically speaking, MQTT isn't dropping, but the bridge connection is no longer receiving updates from those topics. If you close the Ecoflow app and then ensure it's dismissed (assuming you're using Android) then restart MQTT, you should see the data start to flow in to the MQTT server/bridge connection again. If you open the Ecoflow app again, the data will continue to flow while the app is open but as soon as the app is put to sleep by the OS, the bridge connection will go stale again. The only solution to this is to ensure the app is dismisses/completely closed, restart MQTT and don't open the app again - that's what I've been doing for my Smart Home Panel for months. Yes it's a workaround but in the absence of a solution, that's what I do. |
After messing with a River2 unit I'm starting to wonder if we don't know about something that the app is "publishing" to announce its connected and open. Because the River2 doesn't update at all unless the app is open AND its also the "active device" on the phone screen...like somehow it can tell the difference between selected and just app is open. I'm wondering if we are missing at least one MQTT topic used for app management. |
|
Hi, my actual firmware is 1.0.1.107 and everything is ok. In the app there is an announcement for a 1.0.1.111. With your infos i will not do an update! Thanks!
Best regards Hardy
Am 13. Dezember 2023 10:46:22 MEZ schrieb Lewis Roberts ***@***.***>:
…> Has anyone noticed a change in how the MQTT reporting works?
>
> My Delta Max 2000 just got a firmware update and seems to no longer be publishing anything to the "data" topic unless the app is open, and I can't figure out how the battery "knows" if the app is open or not? And closing the app it stops sending after just a few seconds.
>
> I saw others having issues a few months ago, but mine didn't start acting up until after the firmware update tonight. Similar thing, only getting updates published if the app is open on a device. I don't have to restart anything so MQTT isn't dropping, I just need the app left open. Yes, using a unique random UUID.
>
> Wondering if we need some kind of keepalive or heartbeat topic published required to let the servers know the client is still active?
Technically speaking, MQTT isn't dropping, but the bridge connection is no longer receiving updates from those topics. If you close the Ecoflow app and then ensure it's dismissed (assuming you're using Android) _then_ restart MQTT, you should see the data start to flow in to the MQTT server/bridge connection again.
If you open the Ecoflow app again, the data will continue to flow while the app is open but as soon as the app is put to sleep by the OS, the bridge connection will go stale again. The only solution to this is to ensure the app is dismisses/completely closed, restart MQTT and don't open the app again - that's what I've been doing for my Smart Home Panel for months. Yes it's a workaround but in the absence of a solution, that's what I do.
--
Reply to this email directly or view it on GitHub:
#1 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
Might actually have been a false alarm. I was attempting to update my HA YAML to poll the battery and...its working again. I think I may have forgotten another different device (tablet) had the app open still in the background from when I was trying to set my River2 up, and that was interfering with restarting the MQTT broker bridge. I'm now observing the same behavior as others, where it stops if the app is used, and it resumes upon restarting the MQTT broker to restart the bridge. |
I have not looked at it in a while but I believe the app will send an RTC update periodically while open once that starts and then stops the MQTT server stops echoing data to other subscribers not publishing that update... I have not proven that out 100% nor tried to re-create that behavior... instead I have HA watch for stale data (last update >1 minute) and restart mosquito if it sense that... |
I'm investigating the same problem (I think) in berezhinskiy/ecoflow_exporter#70, wherein I tested out @Ne0-Hack3r's theory -- unfortunately the RTC update does not appear to be the trigger, and I've subscribed to all the topics I can find. |
and others
A few things having done some digging myself.
Port 6093 seems to have something to do with upgrading firmware, perhaps the reason it leaves offline mode is because it is preparing to receive an update?
There are a few method that have peeked my interest:
BleCommand.setMainsParamandDirectDeviceCommand.setDcInputModeI am really hoping that this will allow control over charging from the mains (e.g. on/off), but it seems to be used to set the voltage and fequency so I am guessing that wont be the case.BleCommand.setEspModethis appears to send a boolean value, perhaps turn on the ability to debug or flash the ESP module?BleCommand.sendBmsDataCommand,DirectTcpManager.getBmsDataBytesandDirectTcpManager.getBmsSDataBytesit would be really nice if the BMS exposes information about each cell in the power stationThere are a few methods around MQTT which suggests that it could be configured to push information to an MQTT server, maybe this is how they are getting the graphs in the mobile app for charge and discharge? Unless it is a typo for MPPT
com.ecoflow.common.command.BleCommand
The first param
strin all of these methods appears to be the address of the device.com.ecoflow.common.command.CommandUtil
com.ecoflow.common.command.DirectDeviceCommand
com.ecoflow.common.helper.DirectTcpManager
The text was updated successfully, but these errors were encountered: