Delta 2 (MQTT)

[Ne0-Hack3r]

I've started down the road of trying to integrate Delta 2 data with HA via MQTT...

I already have mosquito broker setup as per the instructions from @lwsrbrts in ISSUE #1 and my tweaks for SHP per ISSUE #5 so I simply added the following to mosquito.conf:

# Delta2 Data
topic "" in 0 ecoflow/D2/data /app/device/property/<D2 Serial Number in UPPER CASE>

After seeing the ../D2/data topic on the local broker via MQTT Explorer I used a power shell script to gather messages and log them over the course of several minutes and captured a number of short messages with 1-5 key/value pairs each similar to this:

{"id":1330299617613842767,"version":"1.0","timestamp":1669603258,"moduleType":"1","params":{"pd.carTemp":36}}
{"id":1330299618754038533,"version":"1.0","timestamp":1669603258,"moduleType":"2","params":{"bms_bmsStatus.minCellTemp":26,"bms_bmsStatus.vol":53494,"bms_bmsStatus.f32ShowSoc":89.7}}
{"id":1330299618642890337,"version":"1.0","timestamp":1669603258,"moduleType":"1","params":{"pd.carTemp":35}}
{"id":1330299626203776316,"version":"1.0","timestamp":1669603259,"moduleType":"3","params":{"inv.acInVol":123113}}
{"id":1330299627343973305,"version":"1.0","timestamp":1669603259,"moduleType":"2","params":{"bms_emsStatus.paraVolMin":52491,"bms_emsStatus.paraVolMax":54491}}
{"id":1330299627232824896,"version":"1.0","timestamp":1669603259,"moduleType":"2","params":{"bms_bmsStatus.maxCellVol":3343,"bms_bmsStatus.vol":53491,"bms_bmsStatus.f32ShowSoc":89.7}}
{"id":1330299634793709708,"version":"1.0","timestamp":1669603260,"moduleType":"5","params":{"mppt.carOutVol":46,"mppt.outVol":53331,"mppt.carTemp":36}}
{"id":1330299635933905399,"version":"1.0","timestamp":1669603260,"moduleType":"1","params":{"pd.carTemp":36}}
{"id":1330299635822756850,"version":"1.0","timestamp":1669603260,"moduleType":"3","params":{"inv.acInAmp":66,"inv.acInVol":123084}}
{"id":1330299634793710818,"version":"1.0","timestamp":1669603260,"moduleType":"1","params":{"pd.carTemp":35}}
{"id":1330299687473516144,"version":"1.0","timestamp":1669603266,"moduleType":"1","params":{"pd.carTemp":35}}
{"id":1330299695952298376,"version":"1.0","timestamp":1669603267,"moduleType":"2","params":{"bms_bmsStatus.vol":53490,"bms_bmsStatus.f32ShowSoc":89.7,"bms_bmsStatus.minCellVol":3342}}
{"id":1330299694923253762,"version":"1.0","timestamp":1669603267,"moduleType":"1","params":{"pd.carTemp":36}}
{"id":1330299696063449385,"version":"1.0","timestamp":1669603267,"moduleType":"5","params":{"mppt.carOutVol":46,"mppt.inVol":942,"mppt.outVol":53331,"mppt.carTemp":36}}
{"id":1330299695952300772,"version":"1.0","timestamp":1669603267,"moduleType":"3","params":{"inv.acInAmp":74,"inv.acInVol":123504}}
{"id":1330299747603057983,"version":"1.0","timestamp":1669603273,"moduleType":"1","params":{"pd.carTemp":36}}
{"id":1330299756081840390,"version":"1.0","timestamp":1669603274,"moduleType":"2","params":{"bms_emsStatus.f32LcdShowSoc":89.7,"bms_emsStatus.paraVolMin":52494,"bms_emsStatus.paraVolMax":54494}}
{"id":1330299755052794531,"version":"1.0","timestamp":1669603274,"moduleType":"2","params":{"bms_bmsStatus.remainCap":9626,"bms_bmsStatus.minCellTemp":26,"bms_bmsStatus.vol":53490,"bms_bmsStatus.f32ShowSoc":89.7}}
{"id":1330299756192990623,"version":"1.0","timestamp":1669603274,"moduleType":"1","params":{"pd.carTemp":35}}

After parsing and sorting a bit I came up with the following list of "unique" params:

bms_bmsStatus.amp
bms_bmsStatus.f32ShowSoc
bms_bmsStatus.maxCellVol
bms_bmsStatus.minCellTemp
bms_bmsStatus.minCellVol
bms_bmsStatus.remainCap
bms_bmsStatus.vol
bms_emsStatus.f32LcdShowSoc
bms_emsStatus.paraVolMax
bms_emsStatus.paraVolMin
inv.acInAmp
inv.acInVol
mppt.carOutVol
mppt.carTemp
mppt.inAmp
mppt.inVol
mppt.outVol
pd.carTemp

I also grabbed the payload from ..\get_reply in response to "lastestquotas" from the EF MQTT server (sent to ..\get by the D2 app when it opens) and discovered these unique keys:

bms_bmsStatus.amp             
bms_bmsStatus.bmsFault        
bms_bmsStatus.bqSysStatReg    
bms_bmsStatus.cellId          
bms_bmsStatus.cycles          
bms_bmsStatus.designCap       
bms_bmsStatus.errCode         
bms_bmsStatus.f32ShowSoc      
bms_bmsStatus.fullCap         
bms_bmsStatus.inputWatts      
bms_bmsStatus.maxCellTemp     
bms_bmsStatus.maxCellVol      
bms_bmsStatus.maxMosTemp      
bms_bmsStatus.minCellTemp     
bms_bmsStatus.minCellVol      
bms_bmsStatus.minMosTemp      
bms_bmsStatus.num             
bms_bmsStatus.openBmsIdx      
bms_bmsStatus.outputWatts     
bms_bmsStatus.remainCap       
bms_bmsStatus.remainTime      
bms_bmsStatus.soc             
bms_bmsStatus.soh             
bms_bmsStatus.sysVer          
bms_bmsStatus.tagChgAmp       
bms_bmsStatus.temp            
bms_bmsStatus.type            
bms_bmsStatus.vol             
bms_emsStatus.bmsIsConnt      
bms_emsStatus.bmsModel        
bms_emsStatus.bmsWarState     
bms_emsStatus.chgAmp          
bms_emsStatus.chgCmd          
bms_emsStatus.chgRemainTime   
bms_emsStatus.chgState        
bms_emsStatus.chgVol          
bms_emsStatus.dsgCmd          
bms_emsStatus.dsgRemainTime   
bms_emsStatus.emsIsNormalFlag 
bms_emsStatus.f32LcdShowSoc   
bms_emsStatus.fanLevel        
bms_emsStatus.lcdShowSoc      
bms_emsStatus.maxAvailNum     
bms_emsStatus.maxChargeSoc    
bms_emsStatus.maxCloseOilEb   
bms_emsStatus.minDsgSoc       
bms_emsStatus.minOpenOilEb    
bms_emsStatus.openBmsIdx      
bms_emsStatus.openUpsFlag     
bms_emsStatus.paraVolMax      
bms_emsStatus.paraVolMin      
inv.acDipSwitch               
inv.acInAmp                   
inv.acInFreq                  
inv.acInVol                   
inv.cfgAcEnabled              
inv.cfgAcOutFreq              
inv.cfgAcOutVol               
inv.cfgAcWorkMode             
inv.cfgAcXboost               
inv.chargerType               
inv.chgPauseFlag              
inv.dcInAmp                   
inv.dcInTemp                  
inv.dcInVol                   
inv.dischargeType             
inv.errCode                   
inv.fanState                  
inv.FastChgWatts              
inv.inputWatts                
inv.invOutAmp                 
inv.invOutFreq                
inv.invOutVol                 
inv.invType                   
inv.outputWatts               
inv.outTemp                   
inv.reserved                  
inv.SlowChgWatts              
inv.standbyMins               
inv.sysVer                    
mppt.acStandbyMins            
mppt.beepState                
mppt.carOutAmp                
mppt.carOutVol                
mppt.carOutWatts              
mppt.carStandbyMin            
mppt.carState                 
mppt.carTemp                  
mppt.cfgAcEnabled             
mppt.cfgAcOutFreq             
mppt.cfgAcOutVol              
mppt.cfgAcXboost              
mppt.cfgChgType               
mppt.cfgChgWatts              
mppt.chgPauseFlag             
mppt.chgState                 
mppt.chgType                  
mppt.dc24vState               
mppt.dc24vTemp                
mppt.dcChgCurrent             
mppt.dcdc12vAmp               
mppt.dcdc12vVol               
mppt.dcdc12vWatts             
mppt.dischargeType            
mppt.faultCode                
mppt.inAmp                    
mppt.inVol                    
mppt.inWatts                  
mppt.mpptTemp                 
mppt.outAmp                   
mppt.outVol                   
mppt.outWatts                 
mppt.powStandbyMin            
mppt.res                      
mppt.scrStandbyMin            
mppt.swVer                    
mppt.x60ChgType               
pd.beepMode                   
pd.brightLevel                
pd.carState                   
pd.carTemp                    
pd.carUsedTime                
pd.carWatts                   
pd.chgDsgState                
pd.chgPowerAC                 
pd.chgPowerDC                 
pd.chgSunPower                
pd.dcInUsedTime               
pd.dcOutState                 
pd.dsgPowerAC                 
pd.dsgPowerDC                 
pd.errCode                    
pd.ext3p8Port                 
pd.ext4p8Port                 
pd.extRj45Port                
pd.icoBytes                   
pd.invUsedTime                
pd.lcdOffSec                  
pd.model                      
pd.mpptUsedTime               
pd.qcUsb1Watts                
pd.qcUsb2Watts                
pd.remainTime                 
pd.reserved                   
pd.soc                        
pd.standbyMin                 
pd.sysVer                     
pd.typec1Temp                 
pd.typec1Watts                
pd.typec2Temp                 
pd.typec2Watts                
pd.typecUsedTime              
pd.usb1Watts                  
pd.usb2Watts                  
pd.usbqcUsedTime              
pd.usbUsedTime                
pd.wattsInSum                 
pd.wattsOutSum                
pd.wifiAutoRcvy               
pd.wifiRssi                   
pd.wifiVer                    
pd.wireWatts                  

It appears the D2 works differently than the DP. The DP will send a large message with the status of 'everything' for a given module (bmsMaster, ems, inv, ...) on a fairly frequent basis. SHP appears to operate in a similar way. The D2 appears to send only small messages with what seem to be status "updates" for specific data points which would seem to imply the app gets the status of 'everything' when it opens and then only receives update messages past that point... I'm still new to HA and MQTT and I'm not an "app developer" so some of my speculations here (based on initial observation) may well be incorrect...

For DP and SHP we can create automations in HA to trigger on specific payloads for specific params in messages such as "bmsMaster.errCode = 0" (for DP) or "id = 2" (for SHP) and, based on those triggers, re-publish the entire message to a unique sub-topic (such as ../SHP/circuits) then use an mqtt sensor to pull all the key/value pairs into attributes of an entity in HA. Once those attributes exist in HA custom sensors can be made to track specific attributes (such as sensor.shp_circuit_1_power) or the attribute values can be used directly in various places like {{ state_attr('sensor.shp_circuits','infoList')[10].chWatt | round(0) }}

For D2, the messages arrive with a unique "moduleType" but may contain one or several different parameters... The moduleType could be used by an automation to re-publish to a unique topic per module... but at that point I'm a bit lost in terms of how to structure mqtt sensors to pull the specific data/attributes into HA...

Perhaps someone here with more HA/MQTT background can suggest the best approach?

[Ne0-Hack3r]

I think I've come up with a sort of "work around" for this type of messaging that is similar to what @lwsrbrts came up with for DP and I adapted for use with SHP... Like SHP (and unlike DP) the Delta 2 messages have an identifier... For SHP this is an "id" in the payload that is unique to the module in question... for D2 this is a "moduleType" in the payload...

Created the following automations to re-publish payloads with certain module types to new topics:

- id: 'EF_D2_pd'
  alias: D2 - pd
  description: ''
  trigger:
  - platform: mqtt
    topic: ecoflow/D2/data
    payload: 1
    value_template: '{{value_json.moduleType}}'
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/pd
      payload: '{{trigger.payload}}'
  mode: single

- id: 'EF_D2_bms'
  alias: D2 - bms
  description: ''
  trigger:
  - platform: mqtt
    topic: ecoflow/D2/data
    payload: 2
    value_template: '{{value_json.moduleType}}'
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/bms
      payload: '{{trigger.payload}}'
  mode: single

- id: 'EF_D2_inv'
  alias: D2 - inv
  description: ''
  trigger:
  - platform: mqtt
    topic: ecoflow/D2/data
    payload: 3
    value_template: '{{value_json.moduleType}}'
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/inv
      payload: '{{trigger.payload}}'
  mode: single

- id: 'EF_D2_mppt'
  alias: D2 - mppt
  description: ''
  trigger:
  - platform: mqtt
    topic: ecoflow/D2/data
    payload: 5
    value_template: '{{value_json.moduleType}}'
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/mppt
      payload: '{{trigger.payload}}'
  mode: single

BTW: I assume moduleType '4' is for the extra battery but I don't have one to prove that... It's also possible that could appear under moduelType '2' as, unlike DP, both 'bms' and 'ems' keys appear under this same moduleType...

Then, created MQTT sensors to pull the above into sensor attributes in HA:

- name: D2-pd
    state_topic: "ecoflow/D2/pd"
    qos: 0
    value_template: "on"
    json_attributes_template: "{{ value_json.params | tojson}}"
    json_attributes_topic: "ecoflow/D2/pd"

  - name: D2-inv
    state_topic: "ecoflow/D2/inv"
    qos: 0
    value_template: "on"
    json_attributes_template: "{{ value_json.params | tojson}}"
    json_attributes_topic: "ecoflow/D2/inv"

  - name: D2-bms
    state_topic: "ecoflow/D2/bms"
    qos: 0
    value_template: "on"
    json_attributes_template: "{{ value_json.params | tojson}}"
    json_attributes_topic: "ecoflow/D2/bms"

  - name: D2-mppt
    state_topic: "ecoflow/D2/mppt"
    qos: 0
    value_template: "on"
    json_attributes_template: "{{ value_json.params | tojson}}"
    json_attributes_topic: "ecoflow/D2/mppt"

Then, not knowing which keys will appear in a given message payload for a given moduleType, I came up with this workaround to build out custom sensors for specific data points:

# D2 - Battery
  - name: "D2 Main Battery SOC"
    unit_of_measurement: "%"
    device_class: battery
    state_class: measurement
    state: >- 
      {% if state_attr('sensor.d2_bms','bms_bmsStatus.f32ShowSoc') is not none %}   
        {{ state_attr('sensor.d2_bms','bms_bmsStatus.f32ShowSoc') }}
      {% else %}
        {{ states('sensor.D2_Main_Battery_SOC') }}
      {% endif %}

  - name: "D2 Main Battery Voltage"
    unit_of_measurement: "V"
    device_class: voltage
    state_class: measurement
    state: >- 
      {% if state_attr('sensor.d2_bms','bms_bmsStatus.vol') is not none %}   
        {{ (int(state_attr('sensor.d2_bms','bms_bmsStatus.vol')) / 1000) }}
      {% else %}
        {{ states('sensor.D2_Main_Battery_Voltage') }}
      {% endif %}

... If the given attribute is not available in a given message the sensor stays set to it's last known state but if it is available (and not 'none') the state gets set to the value of that attribute (with whatever modifications I want like taking the voltage in mv and converting it to volts).

Still a bit tedious to identify which data points and build out sensors for each but at least it looks like this can now be done... It would certainly be nice if they would just give us a proper, locally accessible API or a secure way to enable a local MQTT broker on these devices... This is way better than nothing but I'm no fan of having all this tied to the cloud and it's starting to feel like a lot of layers and latency...

[Ne0-Hack3r]

I'm exploring a different approach which may work as alternative for D2 (as well as DP and SHP - though the payload for 'lastestQuotas' on SHP is HUGE)...

In the case of all 3 devices (SHP, DP, D2) when the app opens it publishes to ../get requesting 'status of everything' like this:

{"from":"Android","id":"101493325","moduleType":0,"operateType":"latestQuotas","params":{},"version":"1.0"}

The device will respond by posting a large payload to ../get_reply with JSON containing the status of 'everything'...

In this alternative approach, I created two automations. One that triggers every 10 seconds to ask for status and another to grab the response from ../get_reply and post it to ../status

- id: EF_D2_GetStatus
  alias: D2 - Get Status
  description: ''
  trigger:
  - platform: time_pattern
    seconds: "/10"
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/get
      payload: '{"from":"HA","id":"999000123","moduleType":0,"operateType":"latestQuotas","params":{},"version":"1.0"}'

- id: EF_D2_status
  alias: D2 - status
  description: ''
  trigger:
  - platform: mqtt
    topic: ecoflow/D2/get_reply
  condition:
  - condition: template
    value_template: '{{ ''latestQuotas'' in (trigger.payload) }}'
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/status
      payload: '{{trigger.payload}}'
  mode: single

I then created an MQTT sensor that sets state based on the value of the 'online' key and pulls the rest of the payload from 'quataMap' into attributes of the sensor...

  - name: D2-status
    state_topic: "ecoflow/D2/status"
    qos: 0
    value_template: >-
      {%if (value_json.data.online) == 1 %} online {%else%} offline {%endif%}
    json_attributes_template: "{{ value_json.data.quotaMap | tojson}}"
    json_attributes_topic: "ecoflow/D2/status"

At that point all the data is in HA and is updated every 10 seconds. You can display select attributes in the Templates section of Developer Tools and use them as the basis for custom sensors, triggers, etc.

The following:

{{ state_attr('sensor.d2_status','friendly_name') }} = {{ states('sensor.d2_status') }}

BMS
Fan Level        : {{ state_attr('sensor.d2_status','bms_emsStatus.fanLevel') }}
Discharge Limit  : {{ state_attr('sensor.d2_status','bms_emsStatus.minDsgSoc') }}%
Charge Limit     : {{ state_attr('sensor.d2_status','bms_emsStatus.maxChargeSoc') }}%
Input Power      : {{ state_attr('sensor.d2_status','bms_bmsStatus.inputWatts') }}W
Output Power     : {{ state_attr('sensor.d2_status','bms_bmsStatus.outputWatts') }}W

BATTERY
State of Charge  : {{ state_attr('sensor.d2_status','bms_bmsStatus.f32ShowSoc') }}%
Pack Temperature : {{ state_attr('sensor.d2_status','bms_bmsStatus.temp') }}C
Min Cell Temp    : {{ state_attr('sensor.d2_status','bms_bmsStatus.minCellTemp') }}C
Max Cell Temp    : {{ state_attr('sensor.d2_status','bms_bmsStatus.maxCellTemp') }}C
Pack Voltage     : {{ state_attr('sensor.d2_status','bms_bmsStatus.vol') /1000 }}V
Min Pack Voltage : {{ state_attr('sensor.d2_status','bms_emsStatus.paraVolMin') /1000 }}V
Max Pack Voltage : {{ state_attr('sensor.d2_status','bms_emsStatus.paraVolMax') /1000 }}V
Min Cell Voltage : {{ state_attr('sensor.d2_status','bms_bmsStatus.minCellVol') /1000 }}V
Max Cell Voltage : {{ state_attr('sensor.d2_status','bms_bmsStatus.maxCellVol') /1000 }}V
Design Capacity  : {{ state_attr('sensor.d2_status','bms_bmsStatus.designCap') /1000 }}Ah
Full Capacity    : {{ state_attr('sensor.d2_status','bms_bmsStatus.fullCap') /1000 }}Ah
Remain Capacity  : {{ state_attr('sensor.d2_status','bms_bmsStatus.remainCap') /1000 }}Ah
Battery Cycles   : {{ state_attr('sensor.d2_status','bms_bmsStatus.cycles') }}

Should produce output like this:

[Ne0-Hack3r]

I feel like the above approach is a bit cleaner than constantly triggering multiple automations on constant messages flowing into .../data and having to re-publish those to various other topics and then have an MQTT sensor for each topic...

However, it does mean updates are limited to how often the automation in HA triggers to ask for 'status' (every 10 seconds in my example) and does turn this monitoring into more of a 'polling' operation...

With this approach you don't need ../data in mosquito.conf but instead need:

topic "" in 0 ecoflow/D2/get_reply /app/<UID>/<SN>/thing/property/get_reply
topic "" both 0 ecoflow/D2/get /app/<UID>/<SN>/thing/property/get

I'd like to get some feedback on this approach (at least conceptually if not specific to the Delta 2) vs parsing each inbound message to ../data and re-publishing to various other topics before pulling, separately, into HA and also any opinions on if 10 seconds is too often or not often enough, etc.

[Ne0-Hack3r]

While testing this alternative, I also played with having the automation that publishes ../get 'status of everything' trigger on any message published to ../data

In this case updates are constant but so are requests asking for 'everything' - the rationale is that if something got published to ../data then 'something' changed so let's update 'everything' (to our single sensor in HA) and go from there... the potential drawback I see if that every time the device publishes an update to SOC, for example, HA will publish a request to mosquitto, which forward to public MQTT, which is picked up by the device, which then publishes a full payload with 'all status' that is then forwarded to Mosquitto read by HA, republished to Mosquitto under ../status and then read, again, by HA into the MQTT sensor entity...

In the case of DP, all the keys for status of a given module (bmsMaster for example) are sent together for each update so while you could use this alternative for DP is somewhat less compelling as you end up with 'all status' for each in one of 5-7 MQTT sensor entities in HA (though it still could be nice to have them all in one). With D2 it's a bit more convoluted since any given message contains only changes of status for 1 or a few attributes (simpler to handle in a purpose built script, more convoluted to get into usable form for HA)...

I have not decided which approach I will ultimately take in building out custom sensors to monitor D2 and I have yet to work on using HA to make changes to settings by publishing payloads to ../set

Ultimately all of this would be more elegant built as a formal HA integration but I'm not sure I'm ready to think about tackling that at this point...

[Ne0-Hack3r]

Just a quick update to say that I've refined my D2 integration further... I ended up going with 2 automations for MQTT such that one publishes a requests for 'state of everything' to ..\get whenever 'any' state change is published to ..\data (by the device) and another that triggers on receiving the list of all states on ..\get_reply and re-publishes the payload containing 'latestQuotas' to ..\status

I've also got a number of MQTT sensors setup (working from data in ..\status) as well as automations that update input_numbers and input_lists based on various payloads received on ..\set or publish appropriate payloads to ..\set to change settings (on the device) when inputs are changed on the HA dashboard... I do have a bit of an issue to figure out though where changing a setting in the app results in the automation to change input on the dashboard executing which then triggers the automation to publish the same change to ../set (because the input on the dashboard changed)... At this point it just causes the device to beep twice because it was told to change the setting twice (by app and HA) to the 'same value' (if beep is turned on)... but it "works"... I just find it annoying because it is ugly/kludge and I want to figure out how to employ some kind of logic to prevent redundant commands to change the same setting to the same value...

Here is what I have working, thus far in HA, for Delta 2

[jegres1709]

Hey,
I was almost about to send back D2 due to missing support in HA till I saw your issue and the amazing progress!
Could you share your automations and sensors with us to change the settings in HA?

I would like to combine these information with an external solar generator and a zigbee socket to charge Delta 2 efficiently.

[Ne0-Hack3r]

Hey, I was almost about to send back D2 due to missing support in HA till I saw your issue and the amazing progress! Could you share your automations and sensors with us to change the settings in HA?

Here is what I did to trigger a publish to ../get when a change is published to ../data and also to re-publish the response on ../get-reply to ../status -- at that point you can build out MQTT sensors using ecoflow/D2/status as the topic...

# Automations for D2
automation:

# Delta 2 - Status

- id: ef_d2_get_status
  alias: D2 - Get Status
  description: ''
  trigger:
  - platform: mqtt
    topic: ecoflow/D2/data
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/get
      payload: '{"from":"HA","id":"{{999900000+(range(10000,99999)|random)}}","moduleType":0,"operateType":"latestQuotas","params":{},"version":"1.0"}'

- id: ef_d2_set_status
  alias: D2 - Set Status
  description: ''
  trigger:
  - platform: mqtt
    topic: ecoflow/D2/get_reply
  condition:
  - condition: template
    value_template: '{{ ''latestQuotas'' in (trigger.payload) }}'
  action:
  - service: mqtt.publish
    data:
      topic: ecoflow/D2/status
      payload: '{{trigger.payload}}'
  mode: single

I'm still working on building out sensors and refining automations... but here is an example MQTT sensor that uses the data published to the ../status topic to pull SOC into HA...

# MQTT for D2
mqtt:

  # Standard MQTT Sensors
  sensor:

  - name: D2 Main Battery SOC
    object_id: d2_soc
    unique_id: d2_soc
    unit_of_measurement: "%"
    device_class: battery
    state_class: measurement
    state_topic: "ecoflow/D2/status"
    qos: 0
    value_template: "{{ value_json.data.quotaMap['bms_bmsStatus.f32ShowSoc'] }}"

[jegres1709]

Thank you! the automations and mqtt senosr to get the status are working like a charme!
Maybe I misunderstood your post regarding the possibility to change the settings on the device via HA (e.g. charge limit)
But on the left side of the screenshot it seems you get it working to publish commands to the mqtt-server to make these changes.
I would also like to have such overview of D2 settings and uninstall the android app after that

[Ne0-Hack3r]

Thank you! the automations and mqtt senosr to get the status are working like a charme! Maybe I misunderstood your post regarding the possibility to change the settings on the device via HA (e.g. charge limit) But on the left side of the screenshot it seems you get it working to publish commands to the mqtt-server to make these changes. I would also like to have such overview of D2 settings and uninstall the android app after that

I am working on refining the process to control and change settings... it's a matter of capturing appropriate payloads from ../set as you change settings on the app and then publishing them (potentially with some alteration) back to ../set from HA using automations and input_numbers/lists, etc. Right now I have an issue where if I change something in the app and my automation then changes the slider in HA, then another automation that works in reverse kicks off to change it (to the same thing) by publishing the same command again.. I'm, not sure, yet, how to prevent the double trigger without shutting down the ability to change settings from HA...

[jegres1709]

just played around to change some values (e.g. input power) and i´m facing a problem with publishing in /set.
the value changes ocacionally and will be overrided by the last andoid app command in MQTT explorer e.g.

{
"from": "Android",
"id": "237821030",
"moduleType": 2,
"operateType": "dsgCfg",
"params": {
"minDsgSoc": 30
},
"version": "1.0"
}

so i have to switch to another value and back again in hope the change will be applied.

[Ne0-Hack3r]

... i´m facing a problem with publishing in /set. the value changes ocacionally and will be overrided by the last andoid app command in MQTT explorer

I encountered some oddities in the beginning and have adjusted a few things and, at this point, don't seem to have an issue...

1. be sure to use a unique ID for "remote_clientid" in mosquite.conf (I used power shell to generate a GUID and used that)

2. Use a unique 'from' identifier when publishing the payload to ../set

3. Use a unique random ID when publishing the payload to ../set

I don't know for certain if all of the above are "required" (though you will have issues for sure if your remote_clientid is not unique)... But it does make it much easier to troubleshoot if you're watching the broker and can see if a command came from "Android", "IOS", or "HA" (what I use to designate 'home assistant') and, at one point, I suspected sending every payload with the same "ID" (like '999999999') was causing some issues (at least for Delta 2) which may or may not be an issue for every device and/or setting (depends on how the device itself actually interprets these payloads)...

You'll notice in one of the examples above I use the following for the payload:

payload: '{"from":"HA","id":"{{999900000+(range(10000,99999)|random)}}","moduleType":0,"operateType":"latestQuotas","params":{},"version":"1.0"}'

This means each time the payload is posted by HA to ../set it will be "FROM: HA" and use a unique ID between 999910000-999999999

Hope that helps...

[jegres1709]

point 2 and 3 was already implemented in my config.
I added point 1 to my mosquitto.conf:

connection ecoflow-bridge
address mqtt.ecoflow.com:8883
remote_clientid XXX
remote_username app-XXX
remote_password XXX
try_private true
bridge_insecure false
bridge_protocol_version mqttv311
bridge_tls_version tlsv1.2
bridge_cafile /share/mosquitto/cacert.pem
topic "" in 0 ecoflow/D2/get_reply /app/XXX/XXX/thing/property/get_reply
topic "" both 0 ecoflow/D2/get /app/XXX/XXX/thing/property/get
topic "" in 0 ecoflow/D2/set `/app/XXX/XXX/thing/property/set

in MQTT explorer I can see the changes sent, but it will not be applied..idk whats wrong now

EDIT: found it! should be:
topic "" **both 0** ecoflow/D2/set /app/XXX/XXX/thing/property/set

[Ne0-Hack3r]

EDIT: found it! should be: topic "" **both 0** ecoflow/D2/set /app/XXX/XXX/thing/property/set

Yup... that will do it... set to "in" the payloads published to mosquito from HA won't be sent to mqtt.ecoflow.com...

[Ne0-Hack3r]

NOTE: I made a final attempt to move away from constantly publishing a request for 'latestQuotas' to ../get and then re-publishing the response (with 'state of everything') to ../status for use by my MQTT sensors... While this does "work" the problem is that D2 only publishes the state of most things when/if they change so you end up with a lot of sensors in "limbo" until everything on D2 has been exercised... This makes for an ugly dashboard full of gauges in "unknown" state...

I'm not sure how "inefficient" it might be or how much (if any) extra power I'm using by querying for 'state of everything' every time any change is published to ../data (/app/device/property/SN) but the result is having all sensors constantly up to date and not having any in "unknown" state when sensors are reloaded and the dashboard appears quite responsive...

... still feels a touch kludgy or somehow "inelegant" so if anyone else comes up with a better way to handle this for Delta 2, please let me know!