Repository navigation
Ecoflow contacted us #521
Replies: 53 comments 57 replies
|
As usual, in case something bad happen (and I hope not) the integration is installed on your local system, with AI help you can prolong it's life with new HA updates, so nothing to worry about. |
|
If their official API actually had all the important features, maybe more people would use it? Some extremely critical ones missing for the Stream Ultra - e.g. it can't set the base load. Your API also seems to be a lot more reliable (thanks for all your hard work!) Most likely they just want more people to pay their for their own cloud automation service, rather than automating via HA? (Though none of their automations are even supported for my other EcoFlow battery, and pretty sure they'd anyway be worse than my own ones.) I just hope they don't try and push firmware updates to break your BLE integration, that would be horrible. |
|
Official API they have (as far I know) requires cloud and internet, which is exactly why it can't be used by multiple customers. I would not say that ha-ef-ble is "my" API - the integration uses BLE api of Ecoflow, but it lacks of "official" status, although used by their apps... It's hard to speculate on the actual reasons - but if they are eager to help the community, I suppose we need to support them to do that right. And surely they don't want to break anything - safety is main priority here, so I hope they are going the good way of collaboration rather then breaking something that works well. |
|
This is the main reason why I'm not responding to issues right now, I'm waiting on how it pans out. Just a note that this contact was quite friendly and they seem to be open to discussion so this is not necessarily bad news. They did already publicly announce Local Mode for STREAM 5000 devices working over LAN and other devices might follow so there is a possibility that it will make this integration obsolete - that would be a good outcome. There is a second reason for my absence - I wanted to take a longer pause from development of this integration as it was taking more time that I'd like to admit so I'm was thinking about taking this opportunity to focus on my other projects for some time. This integration was feature complete for me a year ago and it was and still is fun to keep developing this, but work on personal projects keeps piling up as I was giving this more priority. If we receive a positive response, I will continue development, but in a limited mode. |
|
Yeah man, totally understandable! That's why in the first place I did not want to support the other devices (besides the ones I have on hand) - because it's a burden)) You did exceptional work and I suppose this integration is already rewritten by you ~99%. Please don't feel any pressure or obligation - I think everyone understands how hard it is to support all those devices on pure enthusiasm! I think over time the users who want more devices or features can join the process (in case of positive outcome), so we just need to delegate. No need to worry too much about it, it works just fine thanks to you ;) |
|
The work both of you have put into this is the only reason I bought additional Ecoflow gear honestly. I bought a Delta 2 to use as a load-shifting UPS thinking my primary setup would be electing a static charge rate, and then managing island state via smart plug. After finding this plugin and it's features, I was willing to go bigger with the Delta 2 Max, and eventually a pair of their expansion batteries. A relative with a pair of D2's will be moving in soon with me too, so I'm planning to add them so I can coordinate the charge behaviors of all 4 Ecoflows against excess home solar or emergencies. Thank you both for your efforts, I'm curious to see what Ecoflow puts out there, but I'm not holding my breath that they're going to adapt their entire product line. |
|
Hope they choose to support Matter with all the sensors, switches and knobs exposed 🤞 Thank you for all the work on this project! |
|
We shall see if they support all their previous devices too. |
|
I am using this integration because it is local, and it exposes all of the features of my device to me. I have been afraid that ecoflow would pull the rug on this operation, so I proactively removed the cloud connection for my device and am relying on the bluetooth connection for the majority of my needs, and I also have it connected with USB as a UPS. I am only using a River 3 plus as a network backup UPS. I am happy with it so far, but I do not trust this company. Disconnecting from network and the internet is going to prevent firmware updates which will hopefully keep this thing working for as long as I choose. I understand this is not likely an option if you have a whole home battery system. For those that are using this just for like a UPS, now may be the time to disconnect and avoid firmware updates. |
|
Good shout. Mine is being used as a UPS too, just to be on the safe I've cut it off from the internet to prevent firmware updates. This integration is actually so reliable that I haven't used the ecoflow app in ages, no point in keeping it connected. |
|
I disconnected from network since started this project - my 2xSHP2 and 4xDPU with batteries are working just fine and no surprises) |
|
Couple weeks ago I was traveling across Europe in my van and while waiting in a queue to pass the border control, I opened the app to see how my Ecoflow battery is doing, which is River 2, but what I saw was completely different battery - Ecoflow Delta from another camper next to me. Right in the official app I could see the energy flow, turn on and off AC/DC, control all the settings - X-boost, schedules, everything fully exposed via Bluetooth So I get why they want to keep it hush hush and prevent wide spread usage of BLE protocol, because anybody with the app (or with HA) can control any Ecoflow device (or at least the older ones) in a proximity without proper authorization. |
|
Security by obscurity never works and leads to such issues - because if you think it's "invisible" - you give yourself a slack and poorly managing such security. That probably would be better if they make the direct device protocols official and treat them as public, but it's out of our reach... |
|
if they pushed an update that required a pairing code for encryption that could solve the "insecurity" they have the ability to display numbers. or use the serial number or something like that.. |
|
I would have preferred to use a local TCP based protocol. But they have a different way of handling every battery system differently and it's a PITA. This plugin allows me to simply get my data and monitor my units locally which I really appreciate. |
|
I keep my skepticism; if there is no clear implementation, it's just another BS corpo lang. "your integration is not safe, we want users to use our app; we want to create this local API, but nothing actually worked yet". Let say ecoflow did it, which devices? how it works? How far the timeline? |
|
In our world it's a common thing - but we still should appreciate the approach and encourage collaboration rather then demand something. They did what they can - we did what we can, now it's time to combine our efforts to get even better results for the community. |
|
Thank you, @rabits and @GnoX, for your work and for keeping us informed. As a STREAM Ultra / Ultra X user, this integration has made my EcoFlow hardware much more useful. I built a Home Assistant PI controller around it to manage charging and discharging based on actual household power demand. Local control is an essential part of my setup. Honestly, I am sceptical about the promised local API. I have seen no firmware updates for my device for months—which, with a working BLE setup, is actually a relief—and no updates to MQTT support either. Based on that experience, another announcement alone does not give me much confidence. Before asking a working community project to stop, EcoFlow should provide a usable alternative for existing customers. Which devices will be supported? Will that include STREAM Ultra and Ultra X? Will we retain control over charging, discharging and base load? Will it work fully offline? And what is the timeline? If there are specific security concerns with the existing BLE protocol, those deserve a proper technical solution. Stopping this integration would not, by itself, fix a vulnerability in the devices. It is encouraging that the contact was friendly. I hope it leads to concrete cooperation and a working migration path. Until then, I remain cautious. This community has added real value to EcoFlow’s products. Thank you to everyone who made that possible—you certainly do not owe us unlimited unpaid support. |
|
Are you sure? My Ultra X had a firmware update just last week to support the new 5000 series.
I've spoken to EcoFlow and written above that they have confirmed it will not. STREAM 5000 series only. |
|
Same - using because this integration is local. Them them engaging I see as a positive, and @rabits thanks for offering our assistance. I'm sure I'd speak for many here that we'd want the API available on the LAN interface, and for it to work alongside the phone app. |
|
Thank you for the integration anyway and your hard work and many hours of development! I stopped updating the integration a while ago because it covers my device as far as I like and since it works all properly: Never touch a running system. Cloud API from EF was not supported for my D3Plus, hence I use this integration. But if EF does a local API, why not, assuming no internet connection is needed. A couple months ago I cut Internet access to EF. It runs and shall not do a FW update (Which I think must be done with the app). I did one a while back and then it developed a strange behavior with SOC, which I now have solved. So it runs but I do no more updates. There is a FW update available but I don't trust it. Even if EF does an API, I will stick with my setup, it works just fine. I am very happy and very thankful for your Integration. Off-Topic: I charge to 86%. Then EF does a cycle itself from 86% to 83%, then recharges to 86% (That is repeatedly done and takes around 7-9 hours). And then after 2 days it starts to make a SOC spike. It charges until 84-ish % and then jumps directly to 86% within seconds. My part in this cycle: All these SOC spike/glitch is then over after this 100% spike. After this it is completely normal again. All this is a repeating cycle it repeats every 5 days. So all good for me here, I hope EF does a step to help users have their control locally. |
|
Hm, this sounds suspiciously like the issue that has lead me to returning two Delta 2s... It would turn off AC. Started as a once a day occurrence then would grow to be unusable. My current unit (2nd unit about to be returned) won't even turn on now despite claiming to be at 100%. Could this be leading to a drifting SOC that leaves the battery drained? |
|
The fact that Ecoflow contacted you is both good and hilarious. Users have been asking Ecoflow for years to allow full local api access to their products. The cloud dependency goes against the very heart of the use-case for their products.....but I guess they would rather force their customers to keep using their app and their cloud rather than let their products be 100% controllable without their cloud....like, for instance, is necessary in an off-grid situation with no internet! ...so I'm not holding my breath but it would be nice if they finally release a 100% local api for ALL their current and older products! I have stopped buying their products specifically because they lack a real local api. |
|
Yeah, unfortunately for us we're minority - and most of the customers don't care until the emergency situation gets them. And Ecoflow in general goes the right way to spend most of their resources to support majority, because they are paying for the product. We, on the other hand, only need a proper interface and nothing more. So I hope they will just ensure it's safe, supported and allows to control the devices via automation. |
|
Folks, disable ANY possible auto-upgrade you might have configured. Here, they "oopsie" disabled the access, even for developers to their own API: and With EcoFlow, it's always promises (and likely even lies..) The BLE integration, is local, and works well. Don't succumb to whatever Ecoflow is trying to pull on you guys. |
|
In general you're right, but we need to keep open hand to anyone who comes - because it's the only way to collaborate and do something even better. Community always need to show the open-minded approach, even if the intentions of the other side are up to no good. Worst case scenario - we all just keep the existing systems alive, because they are local. The best case scenario - we will show that collaboration is possible and makes the company product even better for our own benefit as customers. So I think it's worth the shot. |
|
Please don't stop this project unless Ecoflow give a local API to support |
|
No worries - everything is local, so you will not get into a situation where you can't control your hardware. You can pin to any version of the integration and stop updating - it will continue to work. One thing - that if you update HA it could have some issues, but AI in our days can easily help you to fix it on your own without centralized repository. |
|
TBF, i think there is a long road ahead of us. even if we give ecoflow the benefit of the doubt and assume they follow through with the local API, there will still be a whole bunch of stuff that need to be tested to verify it’s as feature rich as the BT API. |
|
Yeah, it's a very complicated topic with no good answer, because requires quite a bit of resources from EcoFlow on support side and if the feature is needed just by 1-2 guys they would probably skip it, because it will never make any money for them. The solution is probably to opensource the firmware for the old hardware - but as usual there is a lot of parties involved and the process itself takes man-years and enormous pressure to even consider it as a solution... So no one takes away the BLE transport any time soon - it's just technically very hard and will ruin the app ecosystem they've built... But the local API - yeah, don't know much about that and how they want to pull it off, but we will see. |
|
Basically, this was just a ruse from Ecoflow to be able to control a proper open integration, that's arguably working better than their own options. They have no intention do to a proper open local API. Ecoflow will be Ecoflow.. |
|
I see the repository is now "maintenance-only" thanks to Ecoflow :-( Just curious: what gives them the right to do this? |
Yeah....internet access has been blocked for a while now for all my Ecoflow devices....I don't want any surprises with unexpected firmware (or other) updates and I don't feel the need to supply them with free statistics of how my devices are being used. |
|
It's actually both - I don't want this to become a problem and the maintenance of the new devices is a chore. I suppose the folks who want to support new devices will be able to start their own project, especially with help of AI now it looks much easier and closer to non-RE folks, then when I started. So ha-ef-ble did it's job, showed the way, now it's ready to pass the torch and have just a stable support for already added devices providing long-term value for the users. |
|
so, what happens if i would fork it and add support to new device? |
|
Probably nothing at first. But if it gets enough traction, you'd most likely get an email similar to ours and be facing the same dilemma. |
|
@rabits (and @GnoX) thanks for all your work so far. I understand, that newer devices might be a hassle. But as far as I understood from the various posts: newer devices will get some local API anyway (somewhere in the future). But I doubt that they will enable older devices (powerstream, delta2, ...) with that functionality. And those devices work perfectly fine via ha-ef-ble. So: new devices would do it some new ecoflow way, and the legacy stuff could use this plugin. Win-Win. I don't see buying some mystery-box for having local access - which i already could have otherwise. (Rather I'd sell my ecoflow stuff :D) |
|
It's just an email, the part about the repos - effectively an agreement:
Nothing was signed, but it's an agreement. |
|
I understand the frustration, but I think it's worth clearing a few things up. Nobody signed anything, there is no contract and nothing legally binding. The maintenance-only mode was actually our own proposal: I suggested it in my very first reply to them (quoted above) and rabits confirmed it with them. EcoFlow simply said they're ok with it. rabits can correct me if I'm wrong. We chose to work with them rather than against them, mostly because fighting wouldn't really get us anywhere:
We get that it's not ideal, the ideal would be everything fully open, but both sides had to make some compromises. So I think this is still a good outcome: the repo stays up, supported devices keep getting fixes and everything keeps working locally. If they ship a local API that is actually usable, great. If they don't, nothing changes for devices that are already supported. It's also worth saying that the freeze doesn't change much in practice. I was the one adding most of the new devices, and doing that without owning almost any of them took a lot of time: every one meant working out fields and going back and forth with reporters over diagnostics. And it's getting more painful with every new generation: the newer devices are a lot more complex, and trying to add the STREAM AC 5000 or Ocean Pro took a lot more time than the earlier ones, even with AI help. I was already planning to step back from that, and there isn't anyone else with the time to add and check new devices anyway. This reply was written with AI assistance, mostly to put my thoughts into better English. I reviewed and refined all of it. |
|
I'm not sure what part of the world you live in, but I don't think Ecoflow would have grounds for a takedown, even if you had to reverse engineer their app to be able to connect. In fact the opposite is true, and some practices to lock down owners access to their devices or to repair them and mod them are very illegal in many parts of the world, as big corporations like (one for all, Apple) painfully know. I get it that they have unlimited resources, and ways to make it impossible for a small developer to stand in their way, both legally and not. This is where foundations and organizations that deal with this sort of things can help enormously, if you will. Thankfully, we live in an incredible time, and there will be many developers willing to fork your work and make it live forever. I myself have archived your repo locally and am ready to keep it alive as long as I use ecoflow products, while waiting for their official implementation. |
|
I'm not saying they would have grounds for a lawsuit, but the way I understand it, a takedown doesn't need a winning case. The protocol and our implementation are most likely fine, the concern is some private data from their app that the integration relies on. Fighting a takedown means being willing to go to court against a company, which neither of us wants for a hobby project. And even if we did and won, we'd just win a key to a door they can change the lock on whenever they want. |
|
Yeah, agree with @GnoX - the issue with fighting is taking the responsibility. Usually when fight is over you need to take it, just to make a point - it's a waste of time, because we have no resources. No matter where you live - there is no way to win without resources & power and borrowed power is very dangerous. So we have to be respectful, especially since we already did what we wanted. But on the bright side - now anyone can reverse-engineer whatever they want. |
|
I wonder what "private data" from their app that could be? I just want to connect to devices I legally own... But anyhow. Thanks for all the work so far - maybe, just maybe, the obvious publicity of this thread might bring some additional awareness/ressources on the topic. |
|
My personal impression is that EcoFlow simply does not want ha-ef-ble to keep growing within Home Assistant. I suspect EcoFlow is uncomfortable with an independent project that gives users this much control over their hardware. It allows customers to build their own local automations without relying on EcoFlow’s ecosystem. In my view, that conflicts with parts of their business model. That is why I remain sceptical about the promised local API. So far, the concrete outcome is that this community project stops expanding, while a usable official replacement for existing devices remains unclear. To me, this looks more like an effort to contain ha-ef-ble than a commitment to support independent local control. I would be happy to be proven wrong by a documented, fully local API for our existing devices. I fully understand why the maintainers want to avoid a conflict and reduce their unpaid workload. My criticism is directed at EcoFlow. Your work has made their products more valuable to customers like me. |
|
That is a fair read, and I share some of that skepticism, as I noted in one of my earlier replies. And it's not only about avoiding conflict or workload either: this is still a reverse engineering effort, and even if we won, they could patch it out with a firmware update. They could've also gone the adversarial way instead of talking to us. I would have no problem fighting for it if it made sense, but the real problem is something else: the lack of official local support, which plagues a lot of other companies too and plenty of people are already being vocal about it on many forums. That's an entirely different topic, and not one that fighting over this project would solve. |
|
I have two points: First, you have done great work here and getting this into HA is very much appreciated by me and obviously others that are using it. Thank you. Second, these companies are bananas. The technical people are using HA and their hardware. When someone asks me [tech person] what to use I will recommend what I use if there is a decent product for them. IOW, I want the control of HA. People that ask me what to use are mainly not going to use HA because it is "too hard". But, if EcoFlow has an app [which they do] that is decent then I will tell the people that their product is good and they can use their app. I am not going to suggest to someone that they get HA so that I support them. |
|
Yeah, that's pretty much exactly what I replied to them - the people using HA are the ones others ask before buying. But the fact still stands that we're unfortunately a minority, and most of their customers don't need local support. Well, at least not until it actually matters. |
|
Thank you for keeping this project maintained—I rely on local Home Assistant control for my DELTA 2 and DELTA 3 Max, and both are working after the v1.3.0 update. I hope EcoFlow supports a documented, fully offline API for existing devices while preserving the functionality this community has made possible. |
|
I'll echo some of the previous sentiments but I think it's important for EcoFlow to understand just how crucial local integrations are to many of their customers. I live on an island, me and many of my fellow islanders have sporadic internet access or none at all. This is the case all across my area (coastal BC) for people living both on grid with backup power or off-grid with solar and generators. Removing our ability to use Home Assistant to manage our power system locally isn't just an inconvenience it's a matter of safety and without it EcoFlow products become dumb batteries instead of being power stations. |
|
I use this integration fairly heavily. This is really a message to EcoFlow, if this project stops working and I can't manage my EcoFlow products locally via Home Assistant, I will sell them and buy replacement products from another company that does support local management. Requiring internet access to manage a product that is designed to work during a power outage i.e. when the internet is likely to be down, is nonsensical. I bought and paid for my EcoFlow products, they are mine to do with as I wish. |
|
WTF Ecoflow? I was sooo happy that there is finally a way to control my Delta2Max and Powerstream locally without being dependent on some Cloud. Now this? I am very sceptical that Ecoflow will provide a working local-only LAN mode, especially for „older“ devices. |
I do get their point on safety, but is entirely self inflicted - some devices accept values that go outside their safe range and are only enforced on the application level, not on firmware level so their app over BLE is safe because they control it, but if we did not enforce limits in this integration too, it could actually do some damage - you can read more info about this in my email response to them I posted earlier.
We didn't discuss specifics of freeze, but I believe it only applies to new devices and new features for existing devices - maintenance mode should cover all environmental breaks, HA API updates, BLE link improvments and critical device fixes. But yes, it will stop working if they decide to implement new auth procedure. In our readme, we already mention that if you don't have any major problems with your device, there is no reason to update your firmware - that way, this integration will keep theoretically keep working forever (if they do decide to take it down later, you have local copy and you can still use AI to update it if anything breaks with new environment). |
I believe they arent. They are adding it to the STREAM 5000 series. |
|
@GnoX - i get the point with safety, yet it is their oversight. The COULD also just fix their firmware and make sure that only valid limits are possible and embrace this solution as an semi-official way for local control. Basically they get work done for free here, they should actually send you a paycheck... I hope, that "maintenance mode" will make it possible to securely use the extension for several years. As far as for the AI thing, sorry, this ain't no real solution over a (small) community based approach - this will only be a (bad) band-aid - at that point I will rather sell my ecoflow stuff to someone who is happy using it with their cloud-control and get myself something else which can be run locally. :) |
|
Those corp's products are basically no better than those from an random diy guy. |
First rule of programming security: never ever trust client data. |
|
Reddit discussion about this discussion https://www.reddit.com/r/homeassistant/comments/1xcg3hf/ecoflow_asks_developers_of_opensource_home/ |
|
Their own hardware is only an ESP32 in the STREAM AC series btw - communicating with the internal board over a 1Mbps serial link. At some point, I might reverse engineer their internal communications link, and make my own ESP32 with local API, and couple it with a Shelly Energy Meter for injection / storage... this is the RATGDO scenario all over again.. 😆 |
|
I'll just say this one thing: Any device that can be put into an unsafe condition via Bluetooth is fundamentally unsafe by design. Whether or not Ecoflow is telling the truth about a safety issue or the "safety" argument is just a ploy as part of a control/money grab, either way, no one should be buying any more of their products if their preference is to tell people that their devices are fundamentally unsafe by design. I was considering purchasing an EcoFlow product but they are now permanently off of my list of consideration for any product. |
|
I read a lot about the fact that the bluetooth interface is unsafe because in theory it's possible to send values outside their safe range which may cause the device to malfunction, be bricked....maybe even catch fire? I'm wondering if this also applies to the official cloud based api? I assume it does because it controls the same registers in the devices as when using bluetooth!? Surely there are safeguards in the cloud api to prevent this (like there are in the ha-ef-ble integration) but what if the cloud api is hacked? Would it then be possible for the hackers to brick (or destroy) all connected Ecoflow devices? Not a nice thought and only makes the case for 100% local api stronger! It's not that the cloud api being hacked is un unlikely scenario these days......and Ecoflow should really already have built-in safeguards for this in all the devices firmware! |
|
Interesting and valid point. Above, someone mentioned https://github.com/RGarrett93/hassio-ecoflow-mqtt-decoder which basically intercepts the mqtt-traffic and emulates the ecoflow-cloud. So, one could go ahead and simply try and investigate what is possible there and verify your theory. If it would also be possible to send unsafe values via the mqtt-decoder to the device, this then means that there are actually no safegurads at all on the device side. So a malicious hacker could also take over the cloud and send rubbish to all devices. Anyone capable of crafting this and producing a CVE of some sort? :D |
I think some people are blowing this a little bit out of proportion and I guess that's my fault for not explaining it properly, so few things:
I did some experimenting a long time ago and noticed that official API does enforce some limits BLE didn't so it should be technically safe since they directly control it.
I think some people are forgetting that you still need to authenticate to be able to send any commands, so for any actual device vulnerability to surface means that you to need to find a vulnerability allowing access to their account or for BLE, be able to find their user id first and have physical proximity to the device. |
|
@GnoX thanks for clarification. Thing is, without a transparent and clear communication (looking at ecoflow here), people start speculating. I try to summarize what I understand now:
Regarding the MQTT/API-Question: yes, the official API enforces things if you run via the cloud, but what if you do a Man-in-the-middle as the other mentioned HA-plugin does, and you redirect the entire MQTT-Traffic to your own server and emulate the ecoflow-cloud. It‘s just a guess, but then, things would probably be similar to the BLE extension, as then only the Hardware/Firmware-Safeguards exist probably. Thanks for your patience with all the interest this has raised. |
|
I've had my delta2's mqtt redirected to a local server for a while, with a heavily modified version of the hassio-ecoflow-mqtt-decoder python script to translate whatever it published in cleartext to HA (many disjointed json messages with fields that change all the time - I had the script collect / cache the fields and update them when data shows up); maybe I should give the logged protobuf data to one of my servitors and have it figure things out (back when I set this up the smartest thing I had at my disposal was devstral, now even the local qwen 3.8 is smarter and I also have the good ones in ollama cloud - glm-5.3, kimi, etc. - I ain't paying sam and dario for this 😁) however, I like this BT integration more, since it's a lot cleaner and can also press some buttons I can't with the other one, unless I figure out the delta2 specific protobuf (edited to add: I think I even tried ioborker at the time, it didn't work and forced me to send telemetry, so I removed it after a few minutes) edit 2: ... and I just realized I could just point it to mosquitto and let it examine the data by itself instead of digging for the logs; after all it figured how to build me updated PHP RPMs for centos 7 a few days ago, within the constraints of the debian-based hermes container it's running in 😆 |
|
Honestly, if this is one of their concerns, unsafe value ranges, they should simply SEND THE CREATORS OF THIS INTEGRATION THOSE CONSTRAINTS.
…On October 24, 2026 1:04:34 AM PDT, Ton ***@***.***> wrote:
I read a lot about the fact that the bluetooth interface is unsafe because in theory it's possible to send values outside their safe range which may cause the device to malfunction, be bricked....maybe even catch fire?
I'm wondering if this also applies to the official cloud based api? I assume it does because it controls the same registers in the devices as when using bluetooth!?
Surely there are safeguards in the cloud api to prevent this (like there are in the ha-ef-ble integration) but what if the cloud api is hacked? Would it then be possible for the hackers to brick (or destroy) all connected Ecoflow devices? Not a nice thought and only makes the case for 100% local api stronger!
It's not that the cloud api being hacked is un unlikely scenario these days......and Ecoflow should really already have built-in safeguards for this in all the devices firmware!
--
Reply to this email directly or view it on GitHub:
#521 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
and others
Uh oh!
There was an error while loading. Please reload this page.
~2 weeks ago we were contacted by Ecoflow - in short they want us to stop the operations on this project, because the integration uses their ble protocol, which is for some reason is unsafe. They are creating some sort of local API that will allow a safe managing of Ecoflow devices. I hope they will do that and we offered our help in order to make sure the local API is usable, but so far there is no reply from them on our response email.
All reactions