[solved] Aux1 SOC% in local app incorrect

[boB]

Even though the Classic can only have one modbus over TCP/IP connection at at a time,
it is no excuse for it to "lock up".   I have seen myself, the Classic talk to the Local App
and modpol on the same laptop alternate back and forth just fine depending on
whoever got the connection last.  It was kind of cool...  No lockup.  But it's been
a while.  Might be something  new ?

BTW, I found a way to have the Classic reset that I have just fixed, but unfortunately, I
do not  think this is the typical  reason that people have random reset issues.
Hopefully it is related though.   If you have the MNGP sitting in either the WIND GRAPH
screen OR one of the data logging graph screens, Daily or Hourly (Minutely, actually) the
Classic will reset every 5 or 10 minutes when it saves the Hourly (Minutely) data logs.

You have  to be in one of those 3 screens though or doing a file transfer read from
a custom app at that moment to get it to reset.

I should post to the bugs link  too.  I have fixed this particular issue and the next release will
have it but this should be a very rare event.

[cybermaus]

Well, as I said, lock-up is annoying, but it distracts a little from what I consider a more important issue: Local app giving bogus Aux1 SOC% settings.

I will simply avoid using local app for settings, so not extremely urgent, but please do put it on the to-check/to-do list somewhere.

[Resthome]

BTW, I found a way to have the Classic reset that I have just fixed, but unfortunately, I
do not  think this is the typical  reason that people have random reset issues.
Hopefully it is related though.   If you have the MNGP sitting in either the WIND GRAPH
screen OR one of the data logging graph screens, Daily or Hourly (Minutely, actually) the
Classic will reset every 5 or 10 minutes when it saves the Hourly (Minutely) data logs.

You have  to be in one of those 3 screens though or doing a file transfer read from
a custom app at that moment to get it to reset.

I should post to the bugs link  too.  I have fixed this particular issue and the next release will
have it but this should be a very rare event.

Yep that is where I use to see the disconnects. In the Local App doing things in the data graph view or exporting data. Not sure where the Classic MNGP was sitting. Will watch it more closely after that next up date to see if it is still occurring there

[cybermaus]

There is a new local app (got an update question) and it now correctly displays the 70%/99% in the local app (no more 10/10 regardless of setting). Thanks!

[zoneblue]

In regards to using SOC based aux settings, in the current live firmware, SOC isnt saved to EPROM at all, so any loss of power, or controller initiated reboot, will change SOC to an incorect value.  (to 100%, ie higher than it actually is). In the current beta firmware, two things changed, the SOC was stored to EPROM overnite, and upon reboot, it reverts to the last saved figure. This figure will tend to be lower then it actually is. Aux1 may have some checks and balances for this i guess, but some caution is in order for the moment until the code settles down.

[cybermaus]

Ok, clear.

While the actual SOC% may be a little lower then the stored and reused value, the stored value surely is a better estimate then 100%.

The latest beta, which one is that?

Maurits

[zoneblue]

1795, the link is in the thread: important error in SOC

Agreed a lower figure is better than 100% for you. But thinking on it, it could be lower or higher. The SOC it resets to the last midnite value, and if, say, it dropped furhter then resets before charging, will reset to a higher value. All depends when it resets. Honestly id still be leaning on voltage if it was me.

[cybermaus]

Voltage is very unuseable, because it varies with load and charge. We have done that for a year, but it does not work if the PV array is too little to ensure a full charge every day. The following will (has) happened:

Because on a daily cycle we use more then we charge, the voltage gets lower. Ideally I would like to drop it at 23.8V. But sudden loads (boiler, iron, coffeemaker) could drop it lower temporary even when the battery is quite full. So for that I added a 10 minute (600 second) delay). That works reasonably well. So bottom "turn off load" is OK.

But turning the load back on? When?

A battery is full at about 25V no load. But when charging it could have the same 25V when almost completely empty. Same for 26V. Even if I put put the on voltage at 28.8V, it would reach it before the battery is full.

If I allow the battery to connect to a load again, by setting a 25V voltage and a 999 second delay (I could not go higher in the delay time), it typically never gets topped off. This has likely caused my battery to sulfate over the last year. I estimate I lost half of the nominal capacity of my only one year old bank.

Best for me would be a situation where the "turn off" would be a combination of voltage and soc% ( so when SOC% < 50% *or* voltage < 23.5V for more then 10 minutes) and "turn on" would be not just SOC% but even charge phase (end of absorb or end of eq)

[Westbranch]

Sorry, cant remember your setup, but it sounds like you need to WEEKLY  do a forced Bulk with your generator or?? (grid?) and finish off with PV to ensure you are fully cycling your batteries...

[cybermaus]

Yes. Weekly, or maybe bi-weekly.
But not keep it in the middle area for a year. I know that now.

If only I had seen the setting and know the meaning of the auto-equalize last year.

But anyway, voltages are not a good method to determine top end. SOC% is better. Force a EQ phase every two weeks and suppress Aux1 during that forced EQ even better. Voltages ideally should only be used as fail-save on the bottom end.

[zoneblue]

Yeah that sounds about right.  A reliable SOC will be real useful for that sort of thing.
We'll just have to send bob good vibes so he can sort out out the watchdog resets, or maybe save the SOC to eprom more often, like hourly maybe? Or whenever it changes more than 5%...

[Resthome]

We'll just have to send bob good vibes so he can sort out out the watchdog resets, or maybe save the SOC to eprom more often, like hourly maybe? Or whenever it changes more than 5%...

+1

I like the idea of saving SOC to eeprom. I don't pull my bank down that much so saving it on a timed schedule would work better for me. Maybe once every hour. Don't know how bad a hit that would be on the eeprom life.

[boB]

We'll just have to send bob good vibes so he can sort out out the watchdog resets, or maybe save the SOC to eprom more often, like hourly maybe? Or whenever it changes more than 5%...

+1

I like the idea of saving SOC to eeprom. I don't pull my bank down that much so saving it on a timed schedule would work better for me. Maybe once every hour. Don't know how bad a hit that would be on the eeprom life.

I had thought about this a while back.

Probably not very hard on EEprom life.  Wear-Leveling would be even better but once an hour or so
would be an easy life I think.

Once per hour would be good for at least 12 to 15 years for 100,000 writes, or, if it
was limited to say, every 5% of change, and didn't have to write at night, might be good
for 25 years or more ?

[Resthome]

We'll just have to send bob good vibes so he can sort out out the watchdog resets, or maybe save the SOC to eprom more often, like hourly maybe? Or whenever it changes more than 5%...

+1

I like the idea of saving SOC to eeprom. I don't pull my bank down that much so saving it on a timed schedule would work better for me. Maybe once every hour. Don't know how bad a hit that would be on the eeprom life.

I had thought about this a while back.

Probably not very hard on EEprom life.  Wear-Leveling would be even better but once an hour or so
would be an easy life I think.

Once per hour would be good for at least 12 to 15 years for 100,000 writes, or, if it
was limited to say, every 5% of change, and didn't have to write at night, might be good
for 25 years or more ?

Humm what if you would write it when it changed. I don't think it changes that fast and that way folks with light loads get taken care of and large loads would just be writing more. Then again we don't want these writes to conflict with any reads do we.

[cybermaus]

I sure hope its a good eeprom.

A few years back I had programmed a linux computer as DVR (Tivo like) system. I had made a script so it would program BIOS wakeup to 5 minutes before next scheduled recording. So it did that a few times per day. It lasted about 4 years, then it kept getting BIOS parity errors

So if you do write every few hours, can I suggest  a read-first&only-write-if-changed approach?
Maybe you are already doing that, as it is a good method for any eeprom write, but I wanted to have mentioned it anyway.