[BATTERY SUPPORT] Indevolt PowerFlex/SolidFlex 2000/3000

[Coornh]

Requested battery

Manufacturer: Indevolt
Model: PowerFlex 2000, SolidFlex 2000, SolidFlex 3000

https://www.indevolt.com/products/powerflex-2000-balcony-power-system-with-storage
https://www.indevolt.com/products/solidflex-2000-balcony-power-system-with-semi-rixed-lifepo-batteries
https://www.indevolt.com/products/indevolt-solidflex-3000-ac-with-semi-solid-batteries

What kind of support are you requesting?

Full control: charging, discharging, and monitoring

Developer documentation

https://docs.indevolt.com/docs/hardware/open-data/introduction

Documentation access

Publicly available without an account

Known connection methods

• Local network over Ethernet or Wi-Fi
• Modbus TCP
• RS485 / Modbus RTU
• MQTT
• Local HTTP API
• Cloud / Internet API
• Bluetooth, USB, or serial port
• I don't know

Capabilities found in the documentation

• Read the real battery percentage — SOC (battery_soc)
• Read actual charging and discharging power in W (battery_power)
• Command a specific charging power (apply_setpoint +W)
• Command a specific discharging power (apply_setpoint -W)
• Stop charging and discharging and remain idle at 0 W (standby)
• Determine the safe maximum charging and discharging power
• Detect when the connection or telemetry is no longer updating
• Enable external control, if the device requires it
• Determine whether commands are temporary or stored in device memory
• I cannot identify these capabilities

Technical references and useful clues

Home Assistant integration:
https://www.home-assistant.io/integrations/indevolt/
https://github.com/home-assistant/core/tree/dev/homeassistant/components/indevolt
Uses HTTP

Do you have access to the battery for testing?

Yes, I can test versions and share results of PowerFlex 2000.
@RemBrandNL has SolidFlex 3000

What would you like to achieve?

Charge from surplus solar and predictive charging/discharging based on dynamic pricing.

Confirmations

• I have searched for existing requests for this brand and model.
• I have removed passwords, tokens, API keys, complete serial numbers, and other sensitive information.
• I understand that available documentation does not guarantee integration or a development date.

[RemBrandNL]

I have a Indevolt Solidflex 3000, similar to the 2000 model, just different specs when it comes to charging and uncharging. Does that valid a separate enhancement request?
Cheers,
Remco

[Coornh]

The API is equal for the PowerFlex and SolidFlex 2000 / 3000, so I would say the same enhancement request. Difference is the 2000 model is limited to 2400W charge/discharge and the 3000 model to 3000W. Both require additional battery packs to reach the maximum power ratings, without it they are limited to 900/1000W.
The battery capacity is varying anyway by number of battery packs (1.8 to 19.8kWh), and is returned by the API.

I’ll update the enhancement request.

[RemBrandNL]

Thanks, well leave it as one then. I have 2 extra 3.6 modules and soon dedicated connection for full 3kW charge and back.

[tkaspersNL]

I would love to request support for the Indevolt home battery systems in Omnibattery as well!

Indevolt systems running the Gen-2 firmware layers (V1.01.xx for the 2000 series and V3.xx for the 3000 series) feature fully unlocked, native local OpenData protocols. You can freely toggle both local HTTP and MQTT (as well as Modbus TCP) directly within the official Indevolt app settings.

Because these systems share the same unified API structure, a single driver should be able to cover the entire product family (PowerFlex 2000, SolidFlex 2000, and SolidFlex 3000). The Gen-2 local API fully supports real-time telemetry as well as bidirectional control commands (such as adjusting grid charging limits and switching operational modes), making it an excellent candidate for Omnibattery's dynamic zero-balancing and price-shifting logic.

Technical Resources & References

• Existing HA Integration: The official standalone Indevolt integration is fully open-source and uses local HTTP POST/GET requests with JSON payloads: https://github.com/home-assistant/core/tree/dev/homeassistant/components/indevolt
• Official API schema: https://docs.indevolt.com/docs/hardware/open-data/http-api/

How I Can Help

I have a SolidFlex 2000 system at home, and a SolidFlex 3000 will soon be added.

I would be more than happy to:

• Pull local API JSON payloads or provide live MQTT topic dumps for your development.
• Test beta code/drivers on my actual hardware and provide Home Assistant logs.
• Help troubleshoot the integration during the testing phases.

[tkaspersNL]

I'm a developer by the way, so if no integration is planned I might be willing to see if I can open a pull request for it. Just hope I can find the time for it, and would like to know from @ffunes if you guys are open to that, or would prefer developing it yourselves. If you have an integration guide somewhere let me know.

Also @Xirt, since you created the official Home Assistant Indevolt integration, would you be interested in this as well? You know the system and possible Indevolt API limitations very well.

[tkaspersNL]

Okay already did some more research by comparing how the Zendure / Anker drivers work and have been integrated. The basics for adding Indevolt are pretty straightforward, since it's mostly mapping of data with the local Indevolt API, but testing and finetuning to get it stable and production ready will take a few days. I am testing it on my local machine to see if I can get it up an running, will send updates here :)

[ffunes]

Hi guys!

Happy to have new batteries added to Omnibattery. I always prefer if owners add their drivers to the integration since they can do all the testing on their own, but can work the other way around too. @thijskaspers if in doubt, please let me know if you need anything. I will try to get some guidelines of what is needed, as future improvement.

[tkaspersNL]

Great, I am currently developing/testing with the Indevolt SolidFlex 2000. I see @Coornh has the Powerflex 2000 and @RemBrandNL has the SolidFlex 3000, so this is perfect for test candidates.

@Coornh @RemBrandNL once I have a beta version, would you be willing to test it out on your local HA installations? I'll let it run for a couple of days on my installation first to see if it works with the Solidflex 2000.

[Coornh]

Certainly, let me know when it is ready to be tested!

[tkaspersNL]

Just a quick update: I already have the Indevolt SolidFlex 2000 running in OmniBattery. Right now I'm testing all the controls to see if everything works as intended and I'm running tests to compare the local API vs modbus TCP, to see which one is faster to react to meter changes. In order to get as good as possible net-zero, we need it to react as fast as possible within the recommended request rate limits (Indevolt recommends ≥5s between HTTP and Modbus requests, with a 1s minimum and 1s response time).

I'll also compare it with Indevolt's own net-zero mode.

To be continued

[tkaspersNL]

Another update:

We are running into the technicalities of the local API and Modbus TCP, which requires more testing before we can safely use it.

There are things the manuals don't cover (yet). For example with Modbus:

Do values get written to flash/EEPROM, or straight into RAM? If it's flash, then continuous updates could quickly become a problem if they keep rewriting the same cells.. that could wear them out into hardware failure in the long run. If it's RAM then that won't be an issue.

The manual has read rate limits (>=5s recommended/1s minimum), but no mention of supported/recommended write intervals or the combined read/write budget. Right now we don't know yet if limits are per device, or per connection/protocol, and if a read immediately after a write count against the budget.. For example, if 2 second telemetry with 5-second target updates is supported.

With the local API instead of modbus, we can't assume HTTP is any safer for hardware, because it could ultimately update the same internal settings. There is already proof that some HTTP requests alter values via Modbus.

I've also seen comments of people using the local API and having their device lock up when trying to update realtime controls (probably because of too many requests or 100% RAM usage).

Last thing to be aware of is that other applications might have their own traffic too... so if you use the official Xirt Home Assistant integration, that polls the inverter, and then have EVCC running, and also some custom integrations + OmniBattery, it can all add up and quickly go over the recommended request rate limits. Guess we'll have to write documentation for the integration on how to properly set it up.

Long story short:
Before we can open the integration for everyone, we need to be sure that it can run stable over a long period of time and falls within Indevolt's recommendations for safe operation. I'm already trying to get in touch with their devs for some answers.

[tkaspersNL]

Also now investigating MQTT because of all of this.

Have received word from Indevolt that they are looking into this and might update documentation, to be continued.

[RemBrandNL]

Hopefully support is as open as the api ;-) Use case for me is that I might switch to a full dynamic contract and want to charge it at will. Mostly in winter (solar first) and of course lowest price needs ro beat highest by well over RTE.

[tkaspersNL]

Same usecase for me :) I am mostly using the net-zero mode, but on cloudy days, you'd want the battery to charge during lowest price hours, etc.. I want to maximize ROI.

I've received more information from Indevolt support by the way on which requests are RAM vs ROM writes, so I'm running more tests.

I'm skipping MQTT for now, as it requires a broker to be set-up in Home Assistant, and both local API and Modbus TCP are much easier to configure and the response times seem to be pretty good.

[tkaspersNL]

I'm running actual load tests now with the Indevolt integration and so far so good. Indevolt recommends only 1 read or write every 5 seconds to their API (in their API docs), which isn't very fast to be honest.

I'm running load tests to test 2,3,4,5 second reads for a couple of hours and have also implemented a throttler that will automatically slow down requests once it notices that the Inverter is slowing down due to memory/CPU filling up. It will automatically recover once responses become faster again.

To be continued

[tkaspersNL]

@Coornh @RemBrandNL I'm running the integration in my house right now :) so far so good! I need a couple of days of testing to see if it does a better or worse job than the "Eigen verbruik" mode from Indevolt itself (and do some tweaking), and after that I'll get back to you guys so you can also test it if you want, and provide feedback.

@ffunes is on vacation right now, so he won't be able to look at or approve the integration until after November 3rd, but we can test it in the meantime.

[tkaspersNL]

I'm curious, which meter do you use? Solarman P1? I'm using a HomeWizard P1 with my Indevolt, and while my smart meter can update every second (SMR 5.0), the HomeWizard P1 in Home Assistant uses 5s. So if the home power usage is updated only once every 5 seconds, it makes no sense for OmniBattery to write faster than that. In other words, it isn't OmniBattery or Indevolt then that is slow, but the meter updates.

Home Assistant core rules generally do not permit built-in integrations to poll faster than 5 seconds or expose a direct config setting for the poll interval, so this goes for all P1 meters. I tried the Tibber integration too.

It's possible to poll faster by disabling the polling of the P1 and writing an automation that polls faster than that, but it would strain your Home Assistant server more... I still have to test that.

[Coornh]

I have the HomeAssistant directly connected to the smart meter by a Serial to USB cable, and with DSMR Smart Meter you can set this to update each time the meter sends an update (each second for DSMR 5.0). This gave my Sessy battery a fast response, although it was a noticable load on the HomeAssistant. At the moment I'm not using a net-zero control, so have set the update interval to 5s to reduce load.

[tkaspersNL]

Nice! I'm writing an integration so I can use the homewizard P1 at 1s or 2s polling. I think I'll go with 2s, as that is still fast enough, but noticeably less load on the system.. with throttling, so if response times go down it will automatically go from 2-3-4->5 and back.

OmniBattery also recommends a 1s or 2s meter interval by the way to function properly, so yeah that will be important (Although mine is doing quite a good job with P1 at 5s now, since my house has a heatpump and quite stable standby loads.) You only notice the slowdowns on high powered appliances, like a coffee machine or iron.. You'll still notice it with 1s or 2s too, because the battery has a ramping safety feature, it can't instantly go from 0w to 2000w, but it will react faster with faster meter updates.

Oh and you'll notice less than ideal reaction times on pulsating appliances, like induction hobs or a Quoocker tap.. but that is to be expected. OmniBattery will recognize this and show the PD-status is "oscillating", and even the native Indevolt net-zero mode can't handle it as most other batteries can't.

[tkaspersNL]

@RemBrandNL curious what meter do you use for the Indevolt? P1? and what is the update speed. Almost ready for testing 🚀

[RemBrandNL]

@RemBrandNL curious what meter do you use for the Indevolt? P1? and what is the update speed. Almost ready for testing 🚀

Using a Solarman P1 dongle P1-2WR. No idea how I can check the sampling rate.

Just came back from holiday and in my holiday the battery dropped of wifi for a few hours. Result, there was solar surplus but no charging.

Will most likely switch to LoRa between P1 and battery, omdat het kan ja 😆

Solarman integration doesn’t support this type yet last time I checked. Maybe added with the last updates.

Remco

[gj2830]

Hi all, I’ve read this thread with interest. I have a slightly different setup that might be useful for testing: three PowerFlex 2000 towers (10.08 kWh each) running as one cluster, controlled from Home Assistant through the official Indevolt integration.

For the past several weeks I’ve been running my own zero-export controller in HA (a PI loop on the P1 reading) using real-time control. One thing I found on the cluster that may matter for the driver: only tower 1 (the master) needs to be commanded. Towers 2 and 3 follow every charge/discharge command automatically, whatever their own energy mode is. Sending commands to them directly had no effect at all. So for a cluster I’d expect the driver to treat it as one battery behind the master’s IP, not as three separate ones.

On request rate: my loop runs every 2 seconds and a write takes about 0.2–0.5 s through the HA integration. No lock-ups so far.

@thijskaspers about the HomeWizard P1: I ran into the same thing. The core integration only updates every 5 seconds, which was too slow for my loop, so I ended up making my own version that polls every second.

Still in doubt to kick out the cluster and set it up as 3 seperate systems, but it takes some time to configure everything back if it does not work as intendet.

[tkaspersNL]

If you'd like to test too that would be great!

I'm currently running the P1 in realtime (immediately on meter refresh, which is 1s on DSMR 5), and Indevolt requests from Omnibattery run every second too (both read and write), which is the absolute minimum. So far so good, no lock-ups, no missed or delayed requests. Reads are typically 30ms, writes around 500ms~. I don't have the Ubihub (LAN module) yet on my Solidflex 2000, using Wi-Fi now, but I'll buy it so I can hardwire the inverter to hopefully improve the stability even more :)

I still have to run more tests if Omnibattery can keep a better net-zero than the "net-zero / Eigen verbruik" mode on the Indevolt itself.. it's complicated to test that, because Omnibattery has a lot of PD controls and config options that will impact net-zero, while tweaking those settings are unrelated to request speed handling towards the Indevolt.

I did find delays between a write request to the Indevolt and the time it takes before it starts acting on it (also because of battery ramping). Don't know yet if an API write triggers slower than an internal request from the inverter itself. I don't really mind though if Indevolt's native mode appears to be slight better in the end.. If I can get close enough (90%+) I'll be satisfied, because Omnibattery has a lot more smart features and planning options, and it knows about my car, PV systems etc. while Indevolt does not.

[tkaspersNL]

One more thing, maybe you found this too: power readings from the local HTTP API lag behind what the battery is actually doing. Writes are picked up quickly (500W → 400W and the battery follows within a few seconds on the P1 meter). But the read points only refresh every so often: AC power about every 5–6s (cache perhaps?), so you get the same value multiple reads in a row, and battery power only every 10–16s. Over Modbus, the inverter and battery power registers change about every 2s, so it looks like the HTTP values are just refreshed less often. I've also tried modbus for the integration, but it's not better than HTTP. Reads are slower, only 1 data point per request and max 10 requests before you have to reconnect, so less stable..

For OmniBattery the slower readings are only visual: the battery status in the interface updates slower than we’d like. Net zero runs on the P1 meter, which updates every second, and in the end that’s the one that counts.

[gj2830]

Yes correct AC input/output reading is unreliable. I don't use it for controling, I remember just what I asked it to do, and hope it does so.
Perhaps an additional Schuko plug-in meter could resolve that, if necessary.

[KawaZX6R]

@tkaspersNL nice work! I also want to use my indevolt SF2000 with omnibattery and already started reading the documentation from indevolt and the battery driver requirements from omninattery. I also concluded that something similar to the zendure driver should be possible for indevolt. But then i stumbled on this request and saw you already have progress. Nice!

[tkaspersNL]

@KawaZX6R Yeah I'm waiting for an answer from an Indevolt dev regarding read speeds of current AC and battery power over HTTP, and after that I'm rounding up for testing.. I'll probably draft installation instructions and share it for testing this week.