(3/15/23 - Driver BROKEN due to Ecoflow MQTT security change)
What the driver does:
Opens an MQTT connection with the Ecoflow broker to give Hubitat control of all battery functions. This driver has been tested on Ecoflow Delta Pro and Delta 2 batteries. Some additional testing on River series batteries is needed and an update will be released soon.
More access than the OEM app:
This driver allows control of all the OEM app features and adds additional data points ordinarily unavailable to the end user. Child switches are created based on battery features to control AC, DC, USB, Xboost, and LED outputs. In addition, with the use of custom attributes and custom actions, all battery settings can be displayed on dashboards and adjusted in rules by sending parameters.
Adding additional attributes:
All battery data points are loaded to state variables to track down additional attributes. Also, changes to battery variables are logged after each data refresh to help locate difficult OEM data point names.
I have tried to keep the driver event load down so data can be refreshed often without a burden on the hub. The large quantity of battery data points are only updated to state variables when debug is active. Only changed battery data points are loaded to current device states. Decimals have been removed from data points to stop small fluctuations from triggering attribute updates. To keep attributes accurate a setting allows all device attributes to be refreshed at a reduced frequency compared to the changed attributes setting.
Obtaining the MQTT keys requires a script to be run under Powershell. A URL is listed in the driver providing access to the script and the loading instructions.
Disclaimer:
This is my first MQTT driver and only the second driver I have written. I have spent many hours reverse-engineering the json MQTT command lines required to gain control of the battery. However, I am new to this, and some bugs could still lurk in the data point names or driver code.
Thanks:
I want to thank the following individuals for their help tracking down errors and MQTT command lines.
Mark H. - for helping me get MQTT explorer connected to my battery. That was the starting point. @shircliffs for giving me control of his Delta Pro to test functions and figure out variable names @steve101 for providing Delta Pro output json control strings. @ronv42 for providing River Parameters and engaging in code path discussions @snell for always taking the time to give detailed responses to my never-ending coding questions.
I've been kicking around the idea of a Delta 2 for use as a backup to one of my sump pumps. Bringing in data to a Hubitat dashboard would be a good way to keep tabs on it.
Really appreciate your great work. To be able to integrate my EF DP with your driver was the last nudge to finally purchase a Hub yesterday. Can't wait for it to arrive. Cheers from Germany, Chris
I updated the firmware on my D2 to V1.0.0.64 and noticed a change in the behavior of the EF app. When the EF app is active on my phone, it sends "latestQuotas" requests to the battery every 3 seconds. Before the upgrade, this request was only sent out when the app opened. This "latestQuotas" request is the same command the Hubitat driver issues to refresh, so you may see a Hubitat "excessive event" warning if you leave the EF app open.
Can some DP users see how often the driver updates when they open the EF app on their phone?
I do not leave the EF app status screen active on my phone, so a short period of a heavy refresh load should not cause me any issues. However, I may be able to sense the repeated requests and disconnect from the Broker for a short period. Is that needed? Not sure; looking for opinions.
Ok thanks, Chris.
I have a fix that stops the 3-second data updates when the app is in use. I also did some other cleanup stuff, but I have not released the updates.
-- Not Released --
4 -Added code to stop the 3-second data update when the EF app is in use.
3 -Removed MQTT topic from inside parse() command - clean up of redundant code
2 -Blocked or removed log.info requests that were used for driver development
1 -"Output AC Always" status bit added to device current states.
While you wait for the HE - run through the instructions and get your MQTT keys for your EF DP. You do not need to install or set up MQTT Explore - but it is interesting if you want to see what is going on in the background to support remote functions of your DP through the EF app.
Hi Daryl, to my surprise I managed to get it to work on the first try, but to be honest, the sheer amount of data that is being recorded with this Explorer tool is just overwhelming.
More than 210 different paramters, wow, and I had the feeling the refresh time was more like three times a second than every three seconds. I tried it with Node-red also, no problem to get a connection here, too. Maybe so I could set a trigger for updating less often and can set it up for
some tool like Influxdb to store some history. Thats one main con for the actual EF app imho. Got to have to learn a thing or two the next days it seems.
However my package got stuck at the mailoffice, as they want customs and duty etc. so I'll pick it up there tomorrow. Thanks for the great instructions btw, even me as a mechanical engineer could do that. Best Regards, Chris
Chris,
Take a look at the MQTT subscription for property/{serial number}. That updates the data in small blocks and runs maybe a few times per second; Very busy!
While opening the EF app, look at the subscription "get"; you will see a latestQuotas" command appear - this is the EF app asking the battery for a full data dump.
You will then see a reply from "get_reply" marked "latestQuotas". This is the battery sending all the data back in JSON format.
I did not want the hub reading and updating data multiple times per second, so I monitored the "get_reply subscription and send out a request for data at an interval set in the driver configuration settings.
Good morning Daryl, I finally received my HE, set it up and have a first couple of shelly plugs added yesterday. Took me a while to find it as they didn't want to tell me which post office they dropped the package in. Easter bunny is working early this year. However the setup was pretty easy so far. Today, I will try to add the DP. By the way, is there a chance to add the data of the Extra Battery I have? Will it maybe just require to copy the respective lines of code and change the name from BMS.Master to BMS.Slave1(or2, depending on the port where it is plugged in)? In this MQTT tool, the BMS-related parameters with soc, temp, voltages, etc. are identical to the Master BMS as far as I can see. What do you think? Thanks and best regards, Chris
You do not need to add another HE device for the EB. The EF master battery takes control and sends EB info through a single MQTT broker account. The HE driver has data points for the EB and should display under current device states.
Got it, thanks! Works very well, installation was successful on the first try. I can also see the EB data as you mentioned. I will have to test and play around a bit more to understand how this works and what I can do with it. The update rate seems to be well chosen. Creating a dashboard out of the battery data is somewhat less intuitive in HE as installing devices was, I still have to find out how this is intended to be done. Thanks for your patience! CK
Hi Daryl, I somewhat do not understand how to choose certain available variables (like soc for master and/or slave, f.ex.) to be shown on the dashboard. There is no "choose parameter" option when creating a tile. Do I have to define a child device first, containing the soc variable, like the three switches you created? At the moment I can only choose a tile-style and then it seems a little like magic a whatever-value is displayed (for example a temperature pops up when choosing a temp-style tile, but which temp is it actually? No info is given as for the full variable name...). Did I do something wrong? The videos and docs are only showing the beautyfying process with colors and font styles... And, how can I choose an available parameter in a rule? (F.ex. When DC Input power is above 300W, do switch Shelly1 on a.s.o.) I do not find them here too...? Sorry for the possibly stupid questions, thanks a lot, Chris
Hi Chris,
First, a disclaimer - I am not the right person to help you with HE dashboards, as I use very basic android-based dashboards. For your best experience, you should direct HE questions outside this thread. Many helpful people here that could assist you better than I.
dashboard tiles - As this is a special device that does not fit the mold as a switch, thermostat, or such, a Custom Attribute (CA) callout is used to display information in dashboard tiles. When picking what to display in the tile, select CA, the device name, and you should see all the device attributes listed, like " SOC Master Cell" and such. You should be able to select one or more to display in the tile.
Rules are the same way. For the trigger, select CA, the device's name, and the variable name. Inside the rule, you can also set your "if" commands using the CA function. Sometimes, depending on your instruction, the CA call-up is unavailable inside the command. In that case, just set a local variable to the CA variable above the instruction and use the local variable inside the instruction.
So...for DC Input power is above 300W
Rule trigger - CA for EF battery with the variable as "DC input power" > 300
Your rule actions can then handle the switch on/off and such.
That hint with "attributes" was actually gold,
I had not seen that in the first try.
Thank you very much!
For rules it's also working, but here I have to do more tinkering, thats a world of its own...
Sorry for bothering you on my first clumsy steps here, and thanks again for your patience!
Cheers, Chris
Chris
Ask me all the questions you want. Not a bother whatsoever! But, as your questions move away from this driver and on to other HE stuff, I am most likely not your best resource.
Glad you do so, actually!
Maybe, as a german, I am using the words a little wrong sometimes or it may sound slightly quirky... to say "bothering" was maybe not completely hitting it
One more question however; at the very bottom of the device page of the EF, there is this "tile template" with a kind of code-snippet-looking text. It says something about remaining time... I dont know what I am supposed to or can do with it?
And regarding remaining time there is an error message in the log data? Does this belong together?
Wow, this looks amazing! Super new to hubitat, as in just opened up this link 3 minutes ago (lol) but does this allow for local control of a delta pro? Or do you still need to be online to change parameters? Any chance there's plans to add commands for a smart home panel?
Sorry, no local control with an MQTT broker. I am working on a new parent/child driver allowing multiple EF devices under a single broker account. Similar to how multiple devices show up on the EF phone app. This will pave the way for connecting multiple DPs with an SHP. I currently do not own an SHP, so mapping will be difficult.
EF has a beta HTTP API out for testing, but from what I hear, this will not be local either.
Added error processing in this release will allow the driver to recover much better from internet interruptions. Support for River series batteries has been added to this release. One device attribute name was changed in this revision; check driver change notes.
