Hi
so far, I did all the configuring on the Classic Panel itself
I did look at the local app, but had not entered the unlock serial, so it was grayed out. I did noticed the grayed out values were 'funny' set at 9 and 9, but did not worry about it.
Until yesterday the SOC% high on reset itself from 99% to 90%.
Not sure why. Today I set them back to 50% for off and 99% for on. And I wrote down the serial number.
As I now unlock the local app, I see it has values 10 and 10 for SOC% off and on.
That is damn scary. And incorrect. I *definitely* set it back to 50% and 99% on the panel and pressed enter. I sure do hope the local app did not write it to 10%, because that is WAY to low.
I guess I have to drive back to the boat to check, this is not something I can ask of my brother in law.
Using release 1759 BTW
So did you set the initial settings on the MNGP and pressed Enter to save and then before unlocking the Local App you found it again on the MNGP wrong? Trying to get a handle on the issue so I can try to recreate it
Ryan
No I did not yet found it on the MNGP. not wrong or right. I need to drive back to the boat for that.
I set it on the MNGP, definitely pressed enter, drove home, unlocked the local app, and saw it state 10/10
Even if I would have forgot to press enter on the MNGP, it was set to 50/90 before (which is also already incorrect) and I would never have put 10/10 in there. And I am 100% sure I did press enter.
I did not press any up or down button in the local app, did not enter a single value in there other then the unlock code.
I'll step into the car now.
Ok my guess is it is a bug in the local app and it is not reading it correct. Keep us poste
Well, the good news is the actual setting on the actual midnite is still 50/99
So I do not need to worry about batt going down to 10%
The less good news is, now the classic is not reachable anymore from local app. It still pings on the IP, but the local app cannot find it.
This was normal all through last year when we were running firmware about february 2013. Normal resolution is completely power down the classic (disconnect both PV and Batt) I did not even bother to always do that.
But I had sort of hoped it would have been solved with the update, as some updates last year were about the network stack.
But it seems that the locking up of the TCP stack and/or modbus stack is still there.
Quote from: cybermaus on March 02, 2014, 12:17:53 PM
The less good news is, now the classic is not reachable anymore from local app. It still pings on the IP, but the local app cannot find it.
But I had sort of hoped it would have been solved with the update, as some updates last year were about the network stack.
But it seems that the locking up of the TCP stack and/or modbus stack is still there.
That is curious. I thought that was fixed awhile back. I used to see that regularly but not for a couple updates?
Might be back to odd hardware combinations causing it. That was a thought in the early days of this issue.
Hope you get it sorted. Using 1758 here.
Tom
While I have not seen the local app / Classic network lock up with 1779. The continuing network disconnect are still there for me and have never been resolved as far as I know they were blamed on the Adobe Air network stack that was was being used by the local app.
Quote from: Resthome on March 02, 2014, 01:37:31 PM
While I have not seen the local app / Classic network lock up with 1779. The continuing network disconnect are still there for me and have never been resolved as far as I know they were blamed on the Adobe Air network stack that was was being used by the local app.
John;
Frankly, I only use the Local App to occassionally reconfigure the Classic and check things when folks post questions. I exclusively use RossW's application to read Classic data. So that bypasses Adobe problems.
Just from here.
Tom
Quote from: TomW on March 02, 2014, 01:40:36 PM
John;
Frankly, I only use the Local App to occassionally reconfigure the Classic and check things when folks post questions. I exclusively use RossW's application to read Classic data. So that bypasses Adobe problems.
Just from here.
Tom
It is more a nuance that a major problem as it auto goes back and connects, but the disconnect message is there to let you know the disconnect occurred and you have to go back and click on the connect to reopen the app and then go back to the where ever you were at the time of the disconnect. It appears to be short lived and does not lock up.
I guess RossW's solution would be a alternative.
I doubt the network stack timeout issue has been fixed. Andrew said it was on a long list, last i heard. Here, ive worked around it by maintaining a single open newmodbusd connection, where the symptoms dont manifest. So sadly im no longer a canary for the issue.
Well, I played a bit, have a theory of what happened, but could not reproduce it.
First the important bit: Local app vs Aux1 SOC% settings (as in the title of this thread): The actual settings remained 50%/99% on the NMGP. They also remained 10/10 on the local app trhoughout all my further testing. That means I do not trust the local app for *any* settings, so I even removed the unlock code from the local app to avoid mistakes.
Then the TCP/IP monitoring lockup, which I consider annoying but less critical:
I made the Classic powerless, and restarted. The local app connected again. HOWEVER, it seems you can only connect one local app at the time. If the PC had it, the Android app did not connect. If the Android app had it, the PC did not connect.
And this I think is a hint as to why it locked up: at home the local app was running on my own PC when I jumped into the car and drove to the boat. From where I connected using my brother-in-law's PC.
The PC at home did not close the local app, but it did go to sleep after 30 minutes or so. I suspect that somehow because it did not properly close the TCP socket but became unresponsive from the PC side (PC went to sleep) the Classic was stuck to that one link, and would not accept another link.
Quote from: cybermaus on March 02, 2014, 02:30:26 PM
Then the TCP/IP monitoring lockup, which I consider annoying but less critical:
I made the Classic powerless, and restarted. The local app connected again. HOWEVER, it seems you can only connect one local app at the time. If the PC had it, the Android app did not connect. If the Android app had it, the PC did not connect.
And this I think is a hint as to why it locked up: at home the local app was running on my own PC when I jumped into the car and drove to the boat. From where I connected using my brother-in-law's PC.
The PC at home did not close the local app, but it did go to sleep after 30 minutes or so. I suspect that somehow because it did not properly close the TCP socket but became unresponsive from the PC side (PC went to sleep) the Classic was stuck to that one link, and would not accept another link.
This "one device access at a time" issue is known limitation for the Classic. That is why I read the Classic data and feed that to my own display pages.
Bottom line is you can only access a Classic directly with one device at a time.
Tom
Yes, but that is not the point I am making. The point is, it may provide a clue as to why it locked up.
Quote from: cybermaus on March 02, 2014, 03:23:25 PM
Yes, but that is not the point I am making. The point is, it may provide a clue as to why it locked up.
Could be a clue. As I only access the Classic with one device using the Local App and I do not ever remember having a lockup where I had to power down the Classic to get Ethernet communication going again. Just my $.02
Quote from: Resthome on March 02, 2014, 04:46:47 PM
Quote from: cybermaus on March 02, 2014, 03:23:25 PM
Yes, but that is not the point I am making. The point is, it may provide a clue as to why it locked up.
Could be a clue. As I only access the Classic with one device using the Local App and I do not ever remember having a lockup where I had to power down the Classic to get Ethernet communication going again. Just my $.02
Which seems to show that we are often not comparing apples to apples and more information is always better than less.
I think multiple, back to back attempts to connect to the Classic appear to be a big factor in the past lockups.
Anyway, All I know is what I observe and those lockups have pretty much gone away as near as I can tell here. They used to be daily.
Sorry to the original poster but we seem to have gone on a topic drift here.
I'm done.
Tom
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.
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.
Quote from: boB on March 03, 2014, 02:04:07 AM
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
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!
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.
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
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.
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)
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...
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.
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%...
Quote from: zoneblue on March 27, 2014, 04:53:32 PM
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.
Quote from: Resthome on March 27, 2014, 06:15:52 PM
Quote from: zoneblue on March 27, 2014, 04:53:32 PM
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 ?
Quote from: boB on March 27, 2014, 10:30:02 PM
Quote from: Resthome on March 27, 2014, 06:15:52 PM
Quote from: zoneblue on March 27, 2014, 04:53:32 PM
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.
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.
Quote from: cybermaus on March 28, 2014, 02:09:11 AM
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.
Writing the same thing doesn't hurt it either. Writing zeros is typically what uses up the write cycles.
If it was going to be just one value being written to a block of EEprom, wear leveling takes care of any lifetime
aging issues as long as it isn't writing lots like, hundreds of times per minute. This is because it would write to a
different area of memory every time for many times before coming back to the original write address again.
This is one of the things they have to do with flash disk drives and is why having a larger flash drive
than needed 'should' better for life-time because there is more of those blocks for the wear leveling to
work. I would sure hate to have to deal with that on a disk drive size basis !