Interface restriction announcement

[ElevenFan]

Recently, it was found that the following two interfaces are set very frequently, which seriously affects the FLASH flash data of the device. After internal confirmation by the team, the startup limit is set once a day, and it can only be set 10 min after it is set.

https://openapi.alphaess.com/api/updateDisChargeConfigInfo https://openapi.alphaess.com/api/updateChargeConfigInfo

Thanks

[Gaspode69]

@ElevenFan

I appreciate your consideration regarding potential actions that might impact our devices.

Especially updateDisChargeConfigInfo is often used to optimize the UPS Reserve based on PV forecast data. In my case, I set "batUseCap" in the evening to a low value if the PV forecast for the next day looks favourable and to a high value if not. If the PV forcast changes, I currently adapt "batUseCap" during the night and in the morning. Presently, I find myself making up to three adjustments a day. However, mostly there's no need for any adjustment at all.

In essence, this rigid limitation renders updateDisChargeConfigInfo impractical for my specific use case.

I propose two potential solutions for your consideration and discussion with your team:

1. It might not be necessary to persistently write each change to the flash memory. Perhaps, updating the values once, say at midnight, if they were altered during the day, could be a viable approach.
2. Another option could involve considering a limit for a longer duration, such as permitting 30 updates per month.

Thank you for your attention to this matter. Gaspode

[ElevenFan]

Now the impact is very big, Flash will be burned out, I saw a user setting it 60 times a minute. There is no way to modify the hardware.

[Gaspode69]

I understand the problem, however, there is a big difference between every second and once a day. Once a day is very restrictive, maybe you can think about my proposal # 1.

But in my opinion even better would be solution # 2. I don't know the architecture, but I'd think that this is not a hardware modification, but a software modification in the EMS software.

[ElevenFan]

I will first see how many people have opinions, and then lower the requirements appropriately. Mainly, I don’t know why some people can set up 60 times a minute or 60 times an hour. I don’t know what they are doing.

[Gaspode69]

I will first see how many people have opinions, and then lower the requirements appropriately.

Thank you.

Mainly, I don’t know why some people can set up 60 times a minute or 60 times an hour. I don’t know what they are doing.

I totally agree.

[gbackus]

I think that a change frequency of one per second is a programming error by a user who wants to control the system automatically with a self-programmed script. However, Gaspode's comment about adjusting the change depending on the solar forecast also makes sense, so I would also recommend increasing the frequency up to 5 times per 24 hours. Does the change to once per 24 h also affect the ModBus interface?

[Eytsch0]

In my opinion the number of allowed changes per day should be an even number or not restricted at all. When an user needs to switch something on he should be able to switch the same thing off again in all circumstances. 10 times a day would be ok, I think.

@elevenfan: Do you know the minimum MTTF for the particular flashes / flashing devices across all system types?

[KarlKlammer99]

I understand concerns about burning out the flash with excessive writes.

But there are use cases where writing once a day is too restrictive and would make them impossible. I would also be OK with 10 times a day.

[ElevenFan]

I want to know why someone has to set it up every 5 minutes, what is this doing

[philosifer]

I agree that once a day is way to restrictive. Maybe it could be set to only once every 15 minutes or as already suggested 10 times a day. More than once every 5 minutes is clearly a problem though and not a good use case. My use case for setting it is to charge the battery from the grid in the afternoon if the capacity is too low to get us through the more expense 4-7pm slot in the evening (which only really happens in the middle of winter). That means I'd need to be able to change the value on and then off again to allow the battery to be used once it has charged up.

[jasonwins]

This is a very restrictive change. I too update the charge parameters based upon predicted solar, etc to ensure I can cover the peak rate times from the battery charge. This may involve several updates as usage and sun changes throughout the period. I’d favour option 1 as I really don’t need the values persisted as they will be updated programmatically anyway by me later in the day. Perhaps another api call to persist could be provided, or an option on the existing api call to persist.

[haardman]

I'm on a tariff (Octopus Agile UK) that changes pricing every 30 minutes. Therefore the minimum number of changes per day I'd need is 48, but often more than that. e.g. if I choose to charge my EV then I need to enable charge & disable discharge while doing so and then reverse once charged,

[dan-s-github]

My current plan has two tariffs (Flick Off Peak NZ) and there are two peak rate blocks during the day. I currently check the battery state twice a day 2 hours before the peak rate to decide if I need to charge the battery to get over the peak rate period without using grid power. I will then also disable grid charge when battery is charged to the externally predefined capacity. In my current use case I would create at most 4 write requests to enable or disable charge from grid. As I don't have an EV yet I don't need the disable discharge option so far.

[ffrog8]

My power price changes every 5 mins - i want to be able to charge or not depending on the price. Once a day is crazy - i notice i can change the settings more than once a day in the app and on the web page.

[braindeadmalc]

This really messes me up. I use Intelligent Octopus Go in the UK. If the intelligent EV charge starts outside the nominated six hours at night, it drains the Alpha battery. I currently detect when EV charging starts so I can set the Alpha to charge at a cheap rate which also means it doesn't get discharged. I could live with ten changes a day but one is ridiculous.

Who would buy an Alpha battery with this kind of restriction?

[lemnik]

I'm also using Octopus Agile tariff and find the "once a day" restriction to be far too heavy handed.

As an alternative to this API, it might be useful for the AlphaESS OpenAPI to also expose a direct "charge from grid" function to turn charging on / off without writing to flash (and with no timing). Something where HomeAssistant or other IFTTT style integrations could handle the timing and simply tell the AlphaESS system to start or stop charging with an upper limit (ie: "start charging to 90%", "stop charging").

[dan22h]

Same here with the Octopus energy tariff, my Alpha ESS battery is getting drained in the morning now whenever I get a cheap rate charging window for the car, I need some method of stopping the house battery discharging which has now been removed.

If I'd known this in advance, I wouldn't have bought an Alpha ESS as it's a serious drawback for my use.

[braindeadmalc]

Same here with the Octopus energy tariff, my Alpha ESS battery is getting drained in the morning now whenever I get a cheap rate charging window for the car, I need some method of stopping the house battery discharging which has now been removed.

If I'd known this in advance, I wouldn't have bought an Alpha ESS as it's a serious drawback for my use.

I've raised a complaint with them. We all should IMO.

[gbackus]

To prevent my household battery from being discharged by the EV, I agreed with my electrician that the wallbox would be connected in front of the Alpha metering device instead of behind it. This means that the car can be charged at any time when prices are low without affecting the battery and without having to adjust any of the Alpha parameters. I don't know the regulations in the UK, but it works in Germany.

[djsepp]

Once a day is not Good and to less. I think once a hour would be OK for the most customers. I use it to charge Battery if price is low (could me more than 1 hour a day). Also is say, don't discharge Battery if price is low (also more than 1 times a day).

[ElevenFan]

It is now limited to 10S, and we have modified the setting to set it every 10 minutes.

[Poshy163]

Great change, glad to see alphaESS listening to feedback

[braindeadmalc]

Great...i think. Thanks for the change Does that mean 1 setting every 10min is available? I'm slightly confused by the wording.

[braindeadmalc]

It is now limited to 10S, and we have modified the setting to set it every 10 minutes.

I have a couple of questions please. When will this be implemented? I've tried an API call from HA and it didn't update the settings on the B3. Can you explain your statement in a little more detail please?

Thanks

[Poshy163]

Even if you need to dual write it in english and Chinese, any clarification would be better

[braindeadmalc]

@ElevenFan We still seem be limited to the one a day setting for charging. When will something sensible be implemented e.g. 10 times a day?

This is adversely affecting my use of the system.

[ElevenFan]

Now it is ten mins.

[ElevenFan]

You can try it,Many people have already started using it

[braindeadmalc]

You can try it,Many people have already started using it

Excellent! Thank you. I was confused because the API description on open.alphaess.com still shows once in 24 hours for the API https://openapi.alphaess.com/api/updateChargeConfigInfo

I have tried it and it's working.

[eagle779]

once every 10 seconds is more than enough more my use cases... but design wise I'd limit it by day or month though rather by seconds because if I made a mistake and notice it on save... which humans tend to do... then I'm naturally going to retry immediately. if it was 24 times per day or whatever then it eliminates your write problem and doesn't create any usability issues.

PS while i'm on here, any chance anybody here has some sample c# code I could use to get me started with the API? thanks in advance you'd make my day will buy you a coffee if you do :)

[Tonyslogic]

Not C#, but there is the beginning of a java implementation here: https://github.com/Tonyslogic/comparetout/tree/master/app/src/main/java/com/tfcode/comparetout/importers/alphaess Part of an Android app to project usage and compare costs.

OpenAlphaESS*.java and the responses package show the pattern to follow...

[ElevenFan]

We don't use C#,we use python code.

[hjpfourie]

@ElevenFan I have multiple inverters, but it would appear that the 'limit' is on the API, not per inverter. Can this be updated so I can set both inverters at the same time and not have to wait in between.

[gbackus]

@ElevenFan : Do you know if there are any other parameters or ModBus registers that are stored in the flash memory and could potentially be burned out as well?