My classic 250 is resetting during the day, it did it multiple times yesterday, Ryan you can you look at my data https://www.mymidnite.com/?q=user/121 and see the kwh reset in the afternoon. The classic runs diversion, waste not high, -.2v width 3 and when it resets it never makes it to float. my batteries are staying in bulk/abs for well over 4 hrs/day instead of the 2 hrs that I have them set at. They are using lots of water with the long abs time. the classic has the latest prod firmware in it.
Thanks
Dustin.
Dustin, the Classic is resetting while in absorb ??
What is the battery voltage, input voltage and approximate output power or current when it is in absorb and resetting ??
boB
PS approximate values are fine...
Dustin, can you please email Ryan on this.
We would like to try and get this unit to try and replicate your reset reset reset restttttting problem.
Thanks !
boB
boB,
All the data you requested is on mymidnite, 9-12 (which is actually 9-11 data) is a good example, it reset 4 times that day. power from that array is usually around 550w it seems to reset randomly I don't see any pattern.
Quote from: dbcollen on September 13, 2013, 02:47:48 AM
boB,
All the data you requested is on mymidnite, 9-12 (which is actually 9-11 data) is a good example, it reset 4 times that day. power from that array is usually around 550w it seems to reset randomly I don't see any pattern.
yes, Ryan showed me the graph. I think he has been in contact with you about possibly swapping
that one out. It might help us to figure your problem out as we have a hard time re-creating
this problem here.
Thanks !
boB
Quote from: boB on September 13, 2013, 05:20:46 PM
It might help us to figure your problem out as we have a hard time re-creating
this problem here.
Bob, you will recall I was having identical problems.
Mine have stopped. Completely. Totally.
The network connections, equipment, data polling, firmware etc are unchanged.
There are two other things that HAVE changed however.
1. The size of the array I have connected (down from 3.6KW to 500W)
2. The work-around for the controller failure. You will recall we removed R57 (?)
AND (perhaps more importantly) set it back to old legacy mode.
Have you had anyone else with these odd during-the-day resets try legacy mode and see if the problems go away?
If nothing else, it may point to where in the code the issue might be lurking??
(PS: we really must get back to fixing my classic, the days are getting longer, it'll be nice to have the unit functioning properly again)
Quote from: RossW on September 13, 2013, 06:26:46 PM
Quote from: boB on September 13, 2013, 05:20:46 PM
It might help us to figure your problem out as we have a hard time re-creating
this problem here.
Bob, you will recall I was having identical problems.
Mine have stopped. Completely. Totally.
The network connections, equipment, data polling, firmware etc are unchanged.
There are two other things that HAVE changed however.
1. The size of the array I have connected (down from 3.6KW to 500W)
2. The work-around for the controller failure. You will recall we removed R57 (?)
AND (perhaps more importantly) set it back to old legacy mode.
Have you had anyone else with these odd during-the-day resets try legacy mode and see if the problems go away?
If nothing else, it may point to where in the code the issue might be lurking??
(PS: we really must get back to fixing my classic, the days are getting longer, it'll be nice to have the unit functioning properly again)
Right ! Lower power and slower sweep. Less surging. This is why I want to look closer at the Aux supply.
Maybe if I have you just clip out some more parts ! ;D Actually, sometimes that is the solution.
OK, so, your R57 problem though is because there is a bad circuit on your power board so we will
have to work on that. I will work with Ryan and Mat and see what the best way is that
we can get that going. Board replacement or something since you are on the underside of
the planet.
boB
Quote from: boB on September 13, 2013, 09:16:03 PM
Right ! Lower power and slower sweep. Less surging. This is why I want to look closer at the Aux supply.
So you're thinking it's in effect a POR or (if the classic processor board has it) brownout detection?
But since the battery volts are not dropping, it can't be that... and I'd expect the problem to be far worse with only 500 watts of PV compared to 3600.
I guess what was in my mind was seeing if simply changing to "legacy mode" on another similarly affected system made the problem "go away", if that might help narrow down the possible cause.
Quote
OK, so, your R57 problem though is because there is a bad circuit on your power board so we will
have to work on that. I will work with Ryan and Mat and see what the best way is that
we can get that going. Board replacement or something since you are on the underside of
the planet.
That'd be great.
I had to jump in on this discussion. I have wondered (and maybe mentioned in IRC) that I thought it might be power throughput related.
When I had them they seemed to only occur at high power times and seemed to involve the Local App running at same time? "High Power" being about 1500 watts into 24 nominal volts max on Solar and perhaps 2 KW Max on the Wind but very rare.
I still see communication lockups requiring a reboot also apparently during high power throughput? Perhaps something involved with that is causing loss of power to other areas of the circuitry? Assuming (yeah I know what that does) there is a common power buss for internal circuitry from the battery perhaps high current flows disrupt the smooth DC they expect and perhaps require?
I really should keep notes on these things as I tend to reset to get things running again and forget the details. Luckily, or by design, the Classic keeps on chugging away doing what it is ultimately supposed to do.
I am doing some unusual things like accessing registers with Ross' script from a Pi before and a Linksys Slug now after the Raspbian OS ARM PI seemed to be part of the comms lockups. Still seeing some comms lockups on the Ubuntu OS ARM Slug but not once using an Ubuntu OS X86 laptop awhile before trying the Slug. Maybe the ARM processor's ethernet handling is the issue with the PI and Slug? I tend to be a lightning rod for odd equipment behavior. A jinx if you will. I digress.
I see 2 distinct but separate symptoms here with what appears to be a common cause? I would be looking at areas of the system that are common to communications and tracking the KWH? But I haven't done any serious troubleshooting in a decade plus.
Just some observations and opinion on this issue.
Tom
mine is in legacy mode, since I took out half the array and now the Imp is below batt volts. it now sweeps to about 1v below batt volts (boost) and locks in there.
Quote from: TomW on September 13, 2013, 11:13:12 PM
I still see communication lockups requiring a reboot also apparently during high power throughput?
... Still seeing some comms lockups on the Ubuntu OS ARM Slug but not once using an Ubuntu OS X86 laptop awhile before trying the Slug. Maybe the ARM processor's ethernet handling is the issue with the PI and Slug?
I dont know if ross mentioned it, but i figured out that the comms problem is directly related to cpu load. If can you get rid of all the unnecessary loads on the arm board, the problem goes away. I think what happens is that newmodbus is forced to run so slowly by a congested system that the classic locks the connection up somehow. I want to say this is a bug in the classic, but it can be avoided by keeping the load average down. Take a look at uptime see what it says. These arm boards only draw 1W, which means trying to run full blown linux on them is actually a fairly big ask.
Also can you describe your exact setup. How much cable do you run betw the classic and the rPi? what happens after newmodbus, post processing etc? xserver anything like will be a problem.
Quote from: zoneblue on September 15, 2013, 03:10:46 AM
I dont know if ross mentioned it, but i figured out that the comms problem is directly related to cpu load. If can you get rid of all the unnecessary loads on the arm board, the problem goes away. I think what happens is that newmodbus is forced to run so slowly by a congested system that the classic locks the connection up somehow. I want to say this is a bug in the classic, but it can be avoided by keeping the load average down. Take a look at uptime see what it says. These arm boards only draw 1W, which means trying to run full blown linux on them is actually a fairly big ask.
Also can you describe your exact setup. How much cable do you run betw the classic and the rPi? what happens after newmodbus, post processing etc? xserver anything like will be a problem.
Blue;
Yes, Ross mentioned this but it is definitely
NOT what I am seeing.
I tried it on an otherwise "unoccupied" Pi and it happened anyway. I have tried so many things it is not even remotely amusing.
No long runs of Cat5, there is a switch in the network. The Pi was "closer" than the laptop that had no problems.
I am still semi convinced the Classic is the choke point for several reported issues. Particularly the lockups and this arse pain of resets. I am leaning towards power starvation on circuits but without even a block diagram to go from there is no way I can say for sure from here. Chasing incompatible routers, long cables or other odd "maybes" just sidesteps some basic flaw that manifests itself in several ways and is probably related to multiple problems? Or not.
I just have about given up on communicating with the Classic locally which is the main reason I (and others) want the Classic in the first place. Cutesie pages on the internet is all well and good for folks that travel away from home a lot but not for us here.
I am not going to start using Windows so I can run a supported version of Adobe AIR or buy more hardware so I can monitor the Classic without using the internet and mymidnite which is not exactly rock solid on reliability for me, either.
Anyway, it is late Saturday night / early Sunday Morning so if this makes no sense I blame that.
Just from here, now.
Tom
Tom there is a really nice block diagram or more of a schematic for the classic. I will see if I can dig it up and post it. So on your units has the resetting gone away with the newer firmware and you are having communications issues?
I think most likely what we need is a list of issues and we will stop everything and put lots of brain power on this and see what we can do. There was a change to the aux power supply a ways back maybe 2-3000 serial that was supposed to help with idle draw some. Let me see if I have an old one here and "IF" I can update it and I will send it to you Tom and see if it acts better?
Ryan
Ryan;
My units are SN 1871 on solar (which seems to be the one with the majority of communication lockouts) and 7805 on wind both 150's both with an MNGP.
I think my resets have gone away, at least I have not caught one since I changed routers. There were FW updates at the same time so "what" made them appear to cease is a hard call.
My communications lockups are still there occasionally.They seem to be rPi related but I had seen them when no rPi was in the loop. Several FW revisions have occurred and I did not keep notes. And now that I decided to document better I haven't seen one. ;=<>
Ross can probably extract the times they occurred from our logs. So far his only access to an rPi has been via ssh to one of my units.
Did I ever mention I am a jinx on electronics?
If stuff can survive use by me then it is probably pretty bullet proof!
Ok, on to specifics.
If it either resets or locks up on communications happen what data should I write down before I use the old geek universal fix of power cycling? I believe the MNGP is still responding at those times so I can get some info that way.
Be nice to actually pin this down to one device.
I am not completely dedicated to the rPi but it is what I have for low power computing. If it is a hardware incompatibility with certain peripheral gear then the fix is "don't use that gear" so if the rPi is a bad choice I can move on. Ross had some interesting details on what happened when these communication issues came up and they implied the rPi was tossing a chksum error on the data as near as I can recall. Others seem to be using the rPi with no issues so that kind of made me think it was not the rPi?
I can do whatever is needed to help sort this out. I go slow but usually in a forward direction.
Its Sunday, shouldn't you be playing with the kids? ;D
Tom
Ok so it sort of sounds like it is the other way around from what I had in mind. The older one is the misfit. Hm I assume you are gathering info on the Pi over TCP/IP not serial right? Maybe an idiots guide on how to run that software here on my Pi may be in the works?
Ryan
Quote from: Halfcrazy on September 15, 2013, 01:49:58 PM
Ok so it sort of sounds like it is the other way around from what I had in mind. The older one is the misfit. Hm I assume you are gathering info on the Pi over TCP/IP not serial right? Maybe an idiots guide on how to run that software here on my Pi may be in the works?
Ryan
Yep, TCP/IP. Serial data is enabled but USB cable is not connected to anything. I tried that awhile but with no error checking on data streamed to USB it was tough to get viable data over time. It is a known issue that the rPi has a very busy job handling communications and, if I remember correctly its all on one chip. I assumed that was the issue with malformed data it recorded over USB and writing to a USB thumb drive. I don't want to confuse those 2 issues but they may be related?
Ross is better suited to explain how to use his app but for local logging you just need to cd to the newmodbus directory do a chmod +x newmodbus then execute it like this: ./newmodbus -l /pathto/logdirectory/ IP_of_classic and it will write a log file "XXXX.log" in that directory where "XXXX" is the serial number of the classic. I have entries in my /etc/hosts file for each Classic so I call them by name "solar" or "wind".
I run it from crond at one minute intervals:
(* * * * * /home/tomw/newmodbus/runit&>/dev/null)
"runit" contains:
#!/bin/bash
/home/tomw/newmodbus/newmodbus -wl /PI/ wind
/home/tomw/newmodbus/newmodbus -wl /PI/ solar
/PI/ is an NFS mount from the thumb drive on the PI mounted on the Slug that is running the app right now. The -w feeds data to RossW's server where he creates some graphs and statistics.
Hope that helps.
Tom
So, Tom, are you only having problems with the Classics and the rPi ?
And you have the latest code revision in your Classic(s)
Do you have a windows computer ?
One problem I have in trying to figure out the problems I see over the internet
(forums and/or email) is that I don't have a concise list of people's serial numbers,
battery voltage, firmware revisions, how the unit is set up, whether they are using
the Ethernet or not, is Web access enabled or not, are they using the Local App,
do they have a Lite or have an MNGP remote, are there more than one Classic
connected up in Follow-Me mode, etc.
All that information really helps. I could take all of the information in this forum for
people's Classics and make a list but I don't always know if parameters have changed from
one post to another.
Maybe what we need to do is to get a couple of Classics working in a similar setup as you
have here at the shop and then swap them out with yours and see if you still have the
same problems ?
boB
Quote from: boB on September 15, 2013, 05:26:36 PM
One problem I have in trying to figure out the problems I see over the internet
(forums and/or email) is that I don't have a concise list of people's serial numbers,
battery voltage, firmware revisions, how the unit is set up, whether they are using
the Ethernet or not, is Web access enabled or not, are they using the Local App,
do they have a Lite or have an MNGP remote, are there more than one Classic
Let me kick off the list!
Serial No: 5007
Nominal Battery Voltage: 48V
Nominal Battery Capacity: 1000AH
MNGP Firmware: 1370
Classic Firmware: 1401
Modbus Address 4101: 0x496 (HW Rev 4, Unit type 150)
Software Build Date: June 8th, 2013
Ethernet: yes
Web access enabled: no
Using Local App: no
Using MyMidnite: no
Standard Classic 150
MNGP: yes
MNGP Remote: no
More than one Classic: no
Nominal PV capacity: 3500W
Nominal PV voltage: 105V
Short Ethernet cable (1.8m): yes
USB connected: no
As I was checking the info for this list I noticed my solar Classic #1871 lost communication awhile ago with very low light, minimal charging and 25.5 volts at the battery or so. No reset.
Using the Slug for TCP/IP logging.
My specs:
Serial No: 7805 & 1871
Nominal Battery Voltage: 24V
Nominal Battery Capacity: 450 AH
MNGP Firmware: 1370
Classic Firmware: 1401
Ethernet: yes
Web access enabled: no
Using Local App: not normally
Using MyMidnite: no
Standard Classic 150
MNGP: yes
MNGP Remote: no
More than one Classic: yes: 2 with Follow Me enabled
Nominal PV capacity: 1500W
Nominal PV voltage: ~100V
Short Ethernet cable (1.8m): yes
USB connected: no
Anything else be of interest?
Tom
Bob/Ryan, just to be clear there are two issues here. The one Tom and I are talking about isnt a classic reset per se, the controller carrys on, never reboots, just the ethernet port shuts up shop under certain as yet undetermined circumstances.
Tom im with you, theres no point in having an ethernet monitoring interface if it needs a 100W computer to work with it.
On the rPi/, dont forget that the it has half the memory that cubieboard has and its memory controller is quite a bit slower aswell. Floating point math on both is not flash, but said to be quicker on the rPi. Slug has minimal resources too so i doubt that will help.
Ive had newmodbus running without fault on the cubieboard for a few days now, but it did lock up this morning again after i started putting some more load back on the board last night. Load average overnite was 0.15 overnite. Below 0.1 it appears stable.
Are you saying that the only thing running on that board is that bash script that calls newmodbus once each minute and appends a log file. Nothing else? Can you paste in the output of these:
dpkg -l
uptime
free
Other than cpu load (which doenst tell us all that much) the possibility of overlapping calls from newmodbus to the same device should be ruled out. With all the testing im doing trying to get this software out the door, i cant be certain that there are zero concurrent connect attempts. Ill be able to rule that out tomorow i think.
Heres mine:
Serial No: 4037
Nominal Battery Voltage: 24V
Nominal Battery Capacity: 400AH/c10 AGM
MNGP Firmware: na
Classic Firmware: 1370
Model: Classic 150 LITE Rev4
Software Build Date: ?
Ethernet: yes
Web access enabled: no
Using Local App: not usually/rarely.
Using MyMidnite: no
MNGP: no
MNGP Remote: no
More than one Classic: no
Nominal PV capacity: 1800W
Nominal PV voltage: 75V
Ethernet cable length (to first powered device): 10m
USB connected: no
zoneblue:
tomw@SLUG:~$ dpkg -l
343 packages
Too much text to post according to the forum software 20,000 character limit. I can mail it to you if you want
tomw@SLUG:~$ uptime
19:21:21 up 6 days, 6:40, 1 user, load average: 0.56, 0.17, 0.10
tomw@SLUG:~$ free
total used free shared buffers cached
Mem: 28844 26656 2188 0 336 3288
-/+ buffers/cache: 23032 5812
Swap: 29358068 8192 29349876
tomw@SLUG:~$
Not sure what you are looking for but this machine {SLUG} only runs the logging from crond. It has a load average of .2 to .3. The previous rPi was the same but load avg. was less.
Tom
Hi guys ! thank you for the concise list of settings !
OK, one thing I do not quite understand is this...
MNGP: yes
MNGP Remote: no
Does this mean that your MNGP/remote just has a short cable ?
the MNGP IS the remote so I don't quite follow that. follow-me ??
HA... get it ? follow me ??
boB
Quote from: boB on September 15, 2013, 09:31:05 PM
Hi guys ! thank you for the concise list of settings !
OK, one thing I do not quite understand is this...
MNGP: yes
MNGP Remote: no
Does this mean that your MNGP/remote just has a short cable ?
the MNGP IS the remote so I don't quite follow that. follow-me ??
You specifically asked about the MNGP Remote. I wasn't sure if you might have meant a remote (ie, away from the Classic) display. Also knowing that the Lite for example doesn't have the MNGP (which you refer to as the "MNGP") I took the literal interpretation that "MNGP" was the one in the Classic and "MNGP Remote" was some remote-reading version. If they're the same thing, fair enough.
Other thing just struck me - when I changed from my (failed) classic back to the FM80, I also moved the battery temperature sensor. I can't see it making any difference, but the fact that it's been unplugged from the Classic and plugged into the FM80 is something else co-incident with mine stopping resetting!
Quote from: RossW on September 15, 2013, 09:40:26 PM
Other thing just struck me - when I changed from my (failed) classic back to the FM80, I also moved the battery temperature sensor. I can't see it making any difference, but the fact that it's been unplugged from the Classic and plugged into the FM80 is something else co-incident with mine stopping resetting!
I don't quite understand what you're saying here. First, when you say failed Classic, do you mean one that is completely dead or one that resets ?
Also, what do you mean by you moved the temp sensor ? Does that mean you are using the Classic's temp sensor on the FM80 ?
That will probably work.
But if you changed a Classic over to an FM80 then I would expect that Classic to stop resetting because it is unplugged !
Sorry, must be a language translation ?
WoW ! Lightning and thunder here ! Power just went out for a few seconds and then heard a large boom !
There is went again ! WoW ! I love this but my dog doesn't She's up in my lap !
boB
boB;
I took "MNGP Remote" to mean a Classic Lite that displays to the MNGP on another Classic (remote)?
Tom
Quote from: boB on September 15, 2013, 10:23:46 PM
I don't quite understand what you're saying here. First, when you say failed Classic, do you mean one that is completely dead or one that resets ?
I'm talking about the one that stopped doing anything, we removed R57 and went to legacy mode to get "something" happening. Ie, the one that "failed".
Quote
Also, what do you mean by you moved the temp sensor ? Does that mean you are using the Classic's temp sensor on the FM80 ?
When the classic arrived here it didn't have a battery temperature sensor. In discussion with you and Ryan in IRC, I was assured the one that was on the FM80 was the same, and since I was decommissioning the FM80 to use the Classic, I "stole" its battery temperature sensor. When I reconfigured to go back to the FM80, I put its temp sensor back on it.
Quote
That will probably work.
It does :)
Quote
But if you changed a Classic over to an FM80 then I would expect that Classic to stop resetting because it is unplugged !
Sorry, must be a language translation ?
I currently have the FM80 connected to 3KW PV, and the Classic with a 500W array.
The FM80 doing "most of the work" until the Classic can be fixed.
RossW
Quote from: RossW on September 15, 2013, 11:27:39 PM
I currently have the FM80 connected to 3KW PV, and the Classic with a 500W array.
The FM80 doing "most of the work" until the Classic can be fixed.
RossW
We need to talk more about this but one thing that we will really want to test before you swap that failed Classic
out is to re-connect the 3KW PV array, still with legacy mode on and see if it still resets. That will be a BIG indicator
of what is going on with the resets. Changing two things at once makes it extremely difficult to tell
which one, or both made a difference. Is it somehow related to switching noise or the R57 circuit that who know,
maybe was going bonkers before it really went totally out ? Really hard to say. Then there is the Ethernet
connection but that didn't change of course.
One more great burst of a finale' of information waiting to show itself !
We'll make it right for you guys !
Thanks,
boB
Quote from: TomW on September 15, 2013, 10:52:17 PM
boB;
I took "MNGP Remote" to mean a Classic Lite that displays to the MNGP on another Classic (remote)?
Tom
Here I am trying to respond to the forum and I have similar problems that the Classic has.
My internet connection goes down, I have to reset the modem several times and my laptop's (Dell)
WiFi has a problem where I need to reset it and sometimes reboot the whole laptop to get it
all back again. So, we are not lonely for networking problems ! Where is the forum to talk
with Dell and Westell modem people ? Man, makes me want to just go live on a deserted island
with no electricity or communications or anything !
OK, so, I see what you're saying about the "remote" remote.... Cross Classic-Traffic ! Yes,
good point. I appreciate that part of your report, Tom.
this does not make sense of course that that Classic's MNGP AND Slave port have stopped
talking. I think I heard from Ryan that you tried both MNGPs on both ports and neither
works anymore but the Classic itself charges.
There is separate circuitry for the MNGP jack and the Slave jack so I don't think that
is the problem.
You have "Got Comm" so the power for the MNGPs are working from each jack.
Resetting the Classic doesn't help and changing to address 255 will not get them to talk
I hear...
Does the Local App still work on that low serial number Classic ?
One thing I was going to suggest was to connect the Master jack and the
slave jack on that same unit together, put it into Follow-Me mode and watch
to see if you get a long blue LED or short blue LED blinks indicating communication
BUT the Local App does not have LED mode adjustment on it yet so nevermind
trying that I suppose.
Time for an RMA and I NEED to see that Classic as soon as it comes in.
boB
boB you need to get some sleep.
RossW= Resets and then hardware failure (Resolution = I am sending Ross the Classic 150 off my wall as I know it does not reset now)
RoyB= Got Comm on both serial ports (Resolution=ot sure yet a bit more troubleshooting is in order)
TomW=Flaky Modbus when talking to the older of the 2 Classics. (Resolution=I am likely going to send Tom a newer Classic as an experiment)
Ryan
Quote from: Halfcrazy on September 16, 2013, 06:22:19 AM
boB you need to get some sleep.
Yeah, that after midnight Sunday post read like a Mandarin Chinese manual translated to French and then to English with an online translator. ;D The scary part is I kind of knew what he meant. Sort of.
Sleep is good.
I have to agree with boB on the desert island with no technology much beyond fire.
I think we are seeing progress on these issues.
Tom
Quote from: TomW on September 15, 2013, 08:36:57 PM
Not sure what you are looking for but this machine {SLUG} only runs the logging from crond. It has a load average of .2 to .3. The previous rPi was the same but load avg. was less.
Tom, ok the slug doenst have much to play with but looks like it is handling newmodbus.
Are you saying the slug is running better than the pi? That doesnt make sense unless other things were running on it.
Quote from: zoneblue on September 16, 2013, 06:04:40 PM
Tom, ok the slug doenst have much to play with but looks like it is handling newmodbus.
Are you saying the slug is running better than the pi? That doesnt make sense unless other things were running on it.
Zoneblue;
No, I probably was not clear.
The previous rPi was very lightly loaded had a load average in the teens or so whenever I checked it.
Been through many different methods from overloaded to hardly using any resources on the rPi's. The comms error followed through all the rPi's I tried it on (4 units) The Slug is a Dinosaur so I am only logging with it no other stuff running, no web server or anything just one NFS export from a USB stick. I had one comms error yesterday but I had been looking at it with the Local App at the time getting info for the firmware, etc about the time it it bailed so that may have caused it. I don't count that against the Classic locking out communications as it is known it can only handle one connection at a time.
Hope that makes sense.
Tom
Quote
Been through many different methods from overloaded to hardly using any resources on the rPi's. The comms error followed through all the rPi's I tried it on (4 units) The Slug is a Dinosaur so I am only logging with it no other stuff running, no web server or anything just one NFS export from a USB stick. I had one comms error yesterday ...
Tom
One thing to take into consideration Tom, is that the rPi's ethernet port is piggy backed off the usb bus. This makes it less responsive, but to make matters worse the usb chip in the rPi is also known to be buggy. So theres a collection of possibilitys there. The cubieboard, beagleboard and most newer A10 boards have dedicated 100M ehternet.
Now what i think is the thing for this application is a dual core chip such as the A20. Some day when im bored ill order one. Problem is... boredom is not much available at present.
I really hope midnite can reproduce this and solve it so we can get reliable monitoring. Ideally id like to increase the sample interval to something like 15 seconds. Add in the current sensor and presto, everything just perfect in life.
Quote from: zoneblue on September 17, 2013, 06:15:14 PM
One thing to take into consideration Tom, is that the rPi's ethernet port is piggy backed off the usb bus.
Pretty sure I mentioned the rPi has known issues because of the shared resources for communications (ethernet & USB). Why I figured it was an rPi centric problem at least here. However, in light of the fact that the Slug has had resets the past 2 days I am not exactly sure. Easiest to just dump it in the Aussie's lap and blame the application Ross wrote that I use. Or not.
Sure has not been an obvious "why" on this problem.
I really want local logging but not going to run a laptop to accomplish it so I guess I start looking at other options unless someone sorts out the issue. The X86 laptop had zero lockups on communicating with the rPi using the same code compiled for X86 hardware, if you missed that part. Lots of circumstantial evidence condeming the rPi's.
I can't find a pymodbus package for the Raspbian I am using on the rPi or I might try python to do it but if it is a rPi hardware limitation it is silly to waste effort on using them. Been trying to eliminate possible causes before I bail out on them, tho.
Anyway, kind of in stasis right now on the local logging. Maybe convince a Linksys WRT wireless router to do it. No idea how but I have a couple in the archive.
Watching with interest.
Tom
After I hit "Post" I had another weird thought I believe I floated past Ross once.
Hack your DNS so the mymidnite connection redirects to a local machine that sucks the data out of that stream?
Not sure at all how mymidnite works so probably not as simple as cgi "post".
Its probably not something for the average Joe.
Where is that Classic SDK link? :o
Tom
Yeah thats crossed my mind, but i think their update interval is quite long. And i think there will be some authentication layer in there as well.
Tom, i dont think this is rPi related, not at all. I have danced around this issue on various devices ever since the first day the classic was unboxed.
With the latest blackbox code, this morning im still losing about 1 connect per hour. So its by no mean solved. Andrew just posted on another thread that the latest firmware 1549, changed a timeout that allows it to keep the connection alive longer. It would be very interesting if both you and i tried 1549. Its been around a while so hopefully stable enough.
Quote from: zoneblue on September 17, 2013, 07:14:44 PM
It would be very interesting if both you and i tried 1549. Its been around a while so hopefully stable enough.
I just snagged that update. Pondering sticking it on the Solar Classic.
Remember, I have 2 Classic 150's and one seems immune to this issue so that appears to make it not the MNGP firmware? Or the rPi for that matter? Confusion is the main thing I have going on this issue.
Hard to remember to mention all the variations here.
Tom
It looks like there may have been a wrongly placed brace in the data abort debug portion of the code and the next beta
may further help to diagnose any resetting.
There is also now (in the beta code coming up) a reason for reset register that will tell if it reset due to
brown-out, power up, watch-dog etc.
Another thing or two that may also make a difference.
This beta code should be coming out within the next week or hopefully sooner and will have some Whizbang Junior
code in it as well. Still have not received our plastic covers for the WB Jr. which are supposed to be in this week.
boB
Today I notice after I logged onto the mymidnite webpage and I could see on the graphs that at 9:00 am this morning the total kwh for the day was at 3kwh and then it reset back to zero just after 9:00 am and started counting up again. The time is correct on my classic and its been working fine untouched for weeks.
Why could I now have this day time reset issue just happen by its self? My classic 150 Firmware is - Classic Rev: 1735 - Network Rev: 1674
should I just dismiss it as a random one off.
kurt
My Classic hasn't reset in many months but two days ago while I wss looking at the graph on the Classic display it reset on me. AH for the day went from 1.2 to zero and it didn't save the data. This was after dark so it was in the resting stage.
I am running the latest 2/20 firmware.
I have answers!!!!!!
I am able to reproduce this reset issue. Opening the local app (remote on my laptop) and going to (Data tab) then clicking on (Offline tab) the local app starts to download the data so you can export it (but export tab never becomes active) . 20 - 30 seconds later the classic app resets. Opening the app again the kwh total for the day shows zero and we start all over a gain in absorb. I have repeated it three times in a row to confirm this and it resets the kwh count and returns to absorb every time. (I will just avoid going to this offline data window for now)
The reason why it hasn't done it for weeks is that I haven't tried to load the offline data from the local app in that time. This morning though 9am tried to download the offline data that's when the first reset was triggered.Followed by me doing it 3 more times to confirm the outcome.
Edit: the 4th time I tried to repeat the issue the data finished loaded and I was able to export it and the kwh for the day didn't reset. But it did it three times in a row before so there is some link to it.
Kurt
M 150lite resets about once every couple of weeks. Random time of day, evening, morning, not as a recall during the middle of the day. Hardly ever use the local app, config only. It ought to be possible to collect the reason for reset, not sure what register it is tho.
Quote from: offgridQLD on March 06, 2014, 10:38:41 PM
I have answers!!!!!!
I am able to reproduce this reset issue.
Thank you Kurt !
This sort of makes sense..... Maybe... Try This...
Power off the Classic and back on again. Then, start reading the online logs as soon as you can and see if it starts
to reset again. It may be that reading the logs right after it boots catches the Classic as it is writing a new data log data point and resets at the same time it is doing that and reading the logs from the local app.
The Classic should be saving to those logs every 5 or 10 minutes. I think the latest firmware does it every 5 minutes but it used to be every 10 minutes. If the read and write coincide, that may reset it, but I am not positive that will happen unless those logs are being constantly read from the MNGP logs graph screen. At the moment, from the MNGP and writing logs in the Classic every 5 or 10 minutes will always reset from what I have found recently.
boB
Quote from: boB on March 09, 2014, 03:44:50 AM
Quote from: offgridQLD on March 06, 2014, 10:38:41 PM
I have answers!!!!!!
I am able to reproduce this reset issue.
Thank you Kurt !
This sort of makes sense..... Maybe... Try This...
Power off the Classic and back on again. Then, start reading the online logs as soon as you can and see if it starts
to reset again. It may be that reading the logs right after it boots catches the Classic as it is writing a new data log data point and resets at the same time it is doing that and reading the logs from the local app.
The Classic should be saving to those logs every 5 or 10 minutes. I think the latest firmware does it every 5 minutes but it used to be every 10 minutes. If the read and write coincide, that may reset it, but I am not positive that will happen unless those logs are being constantly read from the MNGP logs graph screen. At the moment, from the MNGP and writing logs in the Classic every 5 or 10 minutes will always reset from what I have found recently.
boB
Seem this thread died here. Time to bring it back to life. I had read in the readme-changes.txt for 1795 that you posted in another thread that this was fixed. Well boB the bad news is the RFR â€" 104 (Watch Dog Timer) Classic resets continue to happen with the latest 1795 â€" 03/17/2014. So I hope you haven’t stopped working on this!
I think we can eliminate hardware issues as this is a new Classic 150 that Ryan exchanged for me. It is very repeatable if you set the Classic up in the Daily Log â€" graph screen on the MNGP and the Local App is in the Offline Data window. From the readme-changes.txt for 1795 this shows up as fixed in 1789 : 3/10/2014.
3-10-2014
Classic build 1789 fixes a problem where sitting in the daily or minutely logs
graph or wind graph screens would reset the Classic when the Classic saves
its data logs to EEprom every 5 or 10 minutes, whichever the interval was set for.
Just wanted you to be aware that it is not fixed for me. Mat wanted me to capture the DB registers for the Local App Info screen the next time it happened. So for what they are worth to someone here they are.
Well, I didn't think that fix would fix ALL of the WDT resets... Just the ones where you are sitting in the MNGP LOGs Graph screen when the Classic writes to the logs.
Not sure what you mean about reading the graphs in the MNGP and also on the Local app. Are you saying that you have another repeatable reset ? How often does it repeat ? Is it every 5 minutes ?
I have a suspicion that those DB registers are not working properly yet unfortunately.
boB
Quote from: boB on March 22, 2014, 02:21:53 AM
Well, I didn't think that fix would fix ALL of the WDT resets... Just the ones where you are sitting in the MNGP LOGs Graph screen when the Classic writes to the logs.
Not sure what you mean about reading the graphs in the MNGP and also on the Local app. Are you saying that you have another repeatable reset ? How often does it repeat ? Is it every 5 minutes ?
I have a suspicion that those DB registers are not working properly yet unfortunately.
boB
I'm sitting in the MNGP Logs Graph screen on the Classic. I then go to the Local App and select Data Offline and with in a few seconds I get a reset with RFR 104. If the LA is in Data Offline and you do a New Day on the Classic it resets with RFR 104.
It does not appear to be reoccurring if you just let it set. At least not at 5 min.
It is repeatable in that if you re-initiate the sequence it will happen again. Does that make any sense. It appears to be what you have described but I don't know exactly when initiates a write while the logs are being read.
Hello I am new to the forum, I have a similar resetting issue with my classic 150. It randomly resets kilowatt hour during the day. It also turn the mode to off sometime, It used to worked perfect at first but as of recently constant resetting of kwh. I am in need of help.
mngp 1370 04/08/2013
classic 1370 04/08/2013
CL8997
24V
295 watt panel *8=2360 watt
no internet connection
Quote from: jah45 on July 04, 2014, 11:58:29 PM
Hello I am new to the forum, I have a similar resetting issue with my classic 150. It randomly resets kilowatt hour during the day. It also turn the mode to off sometime, It used to worked perfect at first but as of recently constant resetting of kwh. I am in need of help.
mngp 1370 04/08/2013
classic 1370 04/08/2013
CL8997
24V
295 watt panel *8=2360 watt
no internet connection
Your firmware is way out of date. Suggest you update the firmware as there have been some fixes for the Classic random reboots.
4 resets of my Classic in the past 10 days that I've noticed. Two this morning within 30 minutes. No buttons being pushed, not looking at any graphs at the time.
Latest firmware.
Quote from: Wxboy on August 23, 2014, 11:08:04 AM
4 resets of my Classic in the past 10 days that I've noticed. Two this morning within 30 minutes. No buttons being pushed, not looking at any graphs at the time.
Latest firmware.
You might try posting the RFR number for boB.
yes, reason for resting and approximate serial number of that classic ?
I'll have to check the RFR # next time I see it happen now that I know how to check it. Serial # is around 2050.
Quote from: Wxboy on August 24, 2014, 08:54:25 AM
I'll have to check the RFR # next time I see it happen now that I know how to check it. Serial # is around 2050.
Hmmmm... Not that new but should be decent with newer firmware.