Reaction time and lack of participation with multiple devices #625
Replies: 7 comments 18 replies
|
I now gave it another try with switching on "Fair distribution" but no B2500 was kicking in when I switched on the oven. See attached log - now in debug mode |
|
I think this is mostly your config, and two settings in particular. The one I'd change first is The battery sitting at 0 W is So I'd try: grid_predict_trust: 0.5 # was 0
osc_damp_max: 0.95 # was 0
fair_distribution: true # was false
balance_deadband: 25 # was 5
concentrate_deadband: 60 # was 20
smooth_target_alpha: 0 # was 0.5
deadband: 0 # was 6The last two are worth dropping because your meter already updates every 3 s, smoothing it just adds lag. Keep |
|
Thank you for taking care of it. I will test the changed parameters and report. |
|
I'd leave it alone for now. Pacing isn't what's holding your reaction back. The grid predictor is what keeps the step response quick, and with it off, raising the pace step mostly buys you bigger overshoot, which is the problem you already had. Get the other changes in first. If the grid then looks lagging rather than hunting, e.g. sitting on one side with few zero crossings on the Diagnostics tab, raise |
|
config.txt Tested it now yesterday and today. Reaction time (when already active) got better, but start-up time got worse. Still batteries are not kicking in when they should. Plus now: Already active batteries are also not giving what they could. What is wrong? 
|
|
You're on 2.2.4, and this is a bug I've already fixed on A B2500's DC channels can't energize below ~40 W each, so a unit needs roughly 80 W before it produces anything at all. Ramp pacing only grew a battery's per-poll cap while it was seen moving, so a B2500 that hadn't started stayed clamped at the 30 W base step indefinitely and sat at 0 W while the load was imported. That's #600, fixed in #614. Could you try the dev build? Add this repository in Home Assistant and update the add-on:
Then set |
|
Installed dev version and tested this with the provided parameters. Does not really change anything for me - maybe you can see more from the data. 
|
|
Two settings explain both halves of what you're seeing.
min_efficient_power: 100 # was 150
pace_base_step: 100 # was 30
pace_max_step: 400 # new, default is 100I simulated your setup with these: five B2500, 400 W max output each. At 1100 W of load: all five batteries now run instead of four, and a load step is followed in ~25 s instead of ~70 s. Two notes. Below ~500 W of load some batteries will still stay off. That is |
|
Now it's working better. All 4 batteries are participating. Reacting good, but ramp up not fast enough, if you ask me. The water boiler is already off again when the batteries reach their peak load. 34dea19a_b2500_meter_2026-08-26T17-21-46.703Z.log The 4 batteries active here have 5 outputs in play, which summarizes in 2000W. In the example above they raech this peak after two mins, but in a second example, they do not reach their peak. There still is some space of 150-250W (19:26:00 ff.) |
|
Another fresh example: 34dea19a_b2500_meter_2026-08-27T06-07-23.180Z.log It is the washing machine with varying power consumption. 4 batteries switched on, AstraMeter reacts, but only with one battery. In the beginning, it is the one with 2 output-connected, that delivers 800W. Even with this larger one being active, the peak phases (last 15 secs) of 200-250W are not covered. To test if other batteries kick in, I deactivated the large one and another one at 07:58:20. But only one of the 2 remaining (400W) took over. At 08:01:00 I switched the other one to Manual Target of 250W. That made the curve look better, but I would rather like AstraMeter to take care of it. |
|
I am sorry to bother again, but to be honest, I am not thoroughly understanding the behaviour and algorithm of B2500/AstraMeter. Neither which parameter to change to receive a predictable result. If you could look again into my setup, I would appreciate it very much. I can provide another example of this morning with more data: Time to wash again...same like yesterday: 4 batteries switched on, 1 of them (my #5) has 2 outputs = 5x400W = 2000W to provide in peak I unfortunately did not shoot the screen before, but I could see that #2 and #4 (controlled by AstraMeter) contribution went down from peak to <300W the moment #5 came in. Although there still was a demand of >800W. #1 stayed at maximum. At 08:07 I then switched #5 to manual target, also to see whether it does not deliver peak at all or because of the algorithm: #5 gave maximum then, but #2 and #4 did not perform as they could. So, there are still two open question I have with AstraMeter in my setup:
|
|
For One thing I still can't explain: two other batteries were told ~0 W while your meter read 1000 W of import. Your log doesn't say why, so I added a line that records the reason behind every command. Please update and send me a fresh log. The Two things before you retest: put |
|
Followed your advise and changed inverter in Marstek app to Marstek-own for each B2500. config.txt The best device to test ramp-up: The Airfryer. 4 batteries switched on and all participate, also against 0. I am satisfied with this, knowing where we came from. However, if there was one thing to improve: It takes throttled AstraMeter about 5 power meter cycles (each 3s) to react visibly to the high demand. And 5 more to have it reduced to a low level. Also the opposite way (ramp-down?) takes some cycles too much. Is there a trick to speed that up a little bit? |
|
Good to hear, and thanks for the log. It's the first one with the new per-command diagnostics, so this is measurable now. At the airfryer step (19:15:56, grid → 1599 W) the balancer wanted 400–470 W from each battery and sent 200 to all four. Same on the next two polls. You can increase it but it comes at the cost of more oscillating, so it's a compromise. The lever that will actually help is your power meter. You're on a 3-second sensor with Which Powermeter are you using? |
|
My power meter is a Hichi/Tasmota and I collect the current consumption via Rest-API. Up to now every 3 secs, following your advise I changed that to 1 second now. First test shows positively faster reaction - nice. But on the other hand again one active battery not in play. Unfortunately, that was this morning and I can't extract it from the log (in UI) anymore. Where can I find the log file anyway, so I can search/copy from it? |
|
There is no log file, the add-on logs to the Supervisor and the Log tab on the add-on page only keeps the tail. Two ways to get the whole thing:
If you set log_level to debug beforehand, the develop build logs once per poll what each battery was told and why, which is what I need for the one that stays out. |
|
That's what I have done. But when you follow the path Settings > System > Logs, there is no "full log" downloadable, just up to 10000 rows: Also Never mind, I will try to reproduce the example and then report the current log entries - like done before. But earliest tonight, too much sun coming in right now... |
|
Two fresh examples for 5 batteries with 6 outputs (2400W) on the field, but not all playing. Water boiler: nice ramp-up and steady, but 600W missing for the perfect picture: Air fryer: several ramp-up phases, but not one is really good. (between 06:45 and 06:47 the coffee machine demands additional power). Maybe you can find out, why? |
|
On your battery 7ce71219ae84 you set a distribution weight 10, the other four have 1. In the boiler window at 05:38 the grid is importing 672 W. That battery gets 10/14 of it, 480 W, while the other four get 48 W each. It is pinned at 400 W and cannot take any of it. The balance correction uses the same weights, so it targets about 104 W for each of the other four while they are actually delivering 265 W, reads them as over-serving and cancels their 48 W share. That is why they sit flat at 265 W with 672 W imported instead of ramping up toward their own limit. Set 7ce71219ae84 back to 1 and the load should spread across all five. Was the 10 deliberate? |
|
"Was the 10 deliberate?" |
|
Restarted and changed that. Looks of course better right away. Thank you again, I just did not look into that value because I was not aware I did something with it. So I have a new picture while my wif is doing her hair in the bathroom: All batteries do participate. But there is always a gap of 50-90W above 0. Not all batteries seem to be at 100%, especially not the two-output one. Could you give me a hint what I can do about it? |
|
Looks like 009c17e01b79 is still switched off. It polls all the way through but every line says inactive, so its Active switch is off. |
|
Yes, it is empty. So I switched it off for charging. Still there are 4 batteries with 5 outputs there. |
|
With equal weights, fair distribution equalises output, not capacity, so your two-output battery gets held down to roughly what a single-output one does. At 09:13:31 the other three are at 400, 400 and 343, and 2419720d40da is at 484. Its share of the 71 W on the meter is 25 W, but the balance correction sees it 77 W above the four-way average of 407 and takes nearly all of that back, so it is sent +1 W. The two at 400 are sent +27 W each and cannot move. Set 2419720d40da to distribution weight 2. Its target share becomes two fifths of the pool instead of one quarter, and the second output gets used. |
|
Yes, I guess that is what I have been aiming for. Tried distribution weight 2 before, but with all trials and (self-made) obstacles in between I lost trying this again. My setup should be working well now, I will let it do it's work the next days. To optimize performance, I have one open task regarding EZ1-M firmware, but that is not an AstraMeter issue. Thank you for the assistance and generally, of course, the piece of software. |
Uh oh!
There was an error while loading. Please reload this page.
What's the issue?
I operate AstraMeter with 5 Marstek B2500 connected to 3 APsystems EZ1-M.
My power meter is a Hichi/Tasmota and to get faster updates, I collect the current consumption every 3 secs via Rest-API.
I tried several parameters in UI config, but am not satisfied with reaction time and amount of power/batteries activated. This occurs more or less always, my setup just is not right, I guess.
As an example I am sending log entries from this morning. Unfortunately not in debug mode - if that is needed I can deliver it.
Situation:
5 B2500 are on/active in AstraMeter.
At 05:15:00 1 B2500 is handling power demand 220W, 2 additional are "kept alive" (saw that), 2 deliver 0W
Now there is a power demand of 2500W starting at 05:15:45. The one active B2500 puts out 415W, but none of the other B2500 comes for help. At 05:18:00 the two "live-kept" react and 3 B2500 now handle a demand of 1200W. This demand raises consistently during an hour to 1500W, but the remaining 2 B2500 are not jumping in over the whole period.
To abstract my concern:
a) my devices do not react quickly enough, except they are already active
2) devices put into "sleep" mode do not get activated
I read the manual, I tried each parameter, but am more confused than at the beginning. I appreciate support with my setup.
Version
2.2.4
Installation method
Home Assistant add-on
If "Other", which?
No response
Configuration
power_input_alias: sensor.verbrauch_aktuell_3s power_output_alias: '' device_types: ct002 throttle_interval: 2 wait_for_next_message: false marstek_auto_register_ct_device: true marstek_mailbox: *** marstek_password: *** cloud_reporting: false active_control: true min_efficient_power: 150 efficiency_rotation_interval: 1200 min_dc_output: 0 grid_predict_trust: 0 log_level: info balance_gain: 0.2 balance_deadband: 5 smooth_target_alpha: 0.5 deadband: 6 fair_distribution: false concentrate_deadband: 20 osc_damp_max: 0Logs
All reactions