classic resetting during day

[zoneblue]

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.

[TomW]

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

[zoneblue]

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.

[TomW]

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

[TomW]

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? 

Tom

[zoneblue]

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.

[TomW]

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

[boB]

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

[offgridQLD]

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

[Wxboy]

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. 

[offgridQLD]

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

[zoneblue]

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.

[boB]

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

[Resthome]

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.

[boB]

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