My Classic is at a very remote mountain top, where it powers a communication site. It takes 2 1/2 hours to get to the site with a 4 wheel drive. The site has internet in the form of a wireless link, which is on the ISP's backbone so it is very reliable. The charge controller often communicates fine for months at a time to both the local panel and the MyMidnite site. However, when any glitch occurs in the communication, the communication is broken, sometimes for days stretching to a week.
One such occurrence happened a couple days ago. We had a large winter storm, which caused the batteries to drain a little too much, and the ISP backbone link went down. The, without the load, the voltage went up, and the backbone went up. It did this on/off every couple of minutes for several hours, until we could get to the site. We turned on the generator, which charged the batteries and all is fine. However, when I got home, there was no communication with the Classic. I went back up there the next day, during a snow storm, and rebooted the Classic. That was about 18 hours ago, and still NO communication.
In this instance, not having a robust ethernet port on the classic is killing me. All of the other equipment brings their working ethernet port up within seconds of powerup. I dont understand why the Classic cant do that. It is very frustrating, not knowing what the system is doing.
By the way, I can ping the Classic (between 7 and 21mS), but it will not communicate with either the local panel or the MyMidnite.
Please, make some upgrades to the ethernet port. I have been struggling with this issue since the beginning. It is bad enough that I had to buy an independent telemetry system to monitor the system.
It is VERY important to me, and probably to a lot of other users!
Tracy
In your case, I would go to the tweaks menu and enable A-Rst so that the Classic resets at midnight.
That will at least keep you from having to reboot the Classic. However, if the network messed up during the
day, you would have to wait until midnight when the Classic resets in this way and you would have access
again.
Sorry about this. We are making it better and better but at the moment, for mountain top sites, the A-Rst
is a good thing to have enabled. Even if the Ethernet were more robust, it is a good idea.
Computers and software/firmware aren't 100%. I wish it were and we are working towards making it perfect.
That is the goal.
boB
Hi Bob, Thanks for the reply. I believe the A-rst is set to on. The last time I upgraded the firmware (maybe Sept or Oct) I had to go back and turn it back on. It has been working fine since then, but now the system doesn't want to talk to me!
Quote from: thooker on January 03, 2015, 03:31:10 PM
Hi Bob, Thanks for the reply. I believe the A-rst is set to on. The last time I upgraded the firmware (maybe Sept or Oct) I had to go back and turn it back on. It has been working fine since then, but now the system doesn't want to talk to me!
If the Classic was running, other than the Ethernet had stopped talking (not just the ping which worked), then the A-Rst should have fixed it in a day...
Maybe it did its auto reset during times of other bad network happenings and it needed another day to reset ?
The other parts of the network can also affect how the Classic talks if it tries to open lots of connections after network drops, etc.
Hopefully A-rst is on. It should come back up by itself if that is the case. Might give it another day or two ? I don't suppose you can view other things having to do with battery voltage to make sure all is OK ?
boB
boB
My secondary TM system is a Bogart Engineering unit using PMComm software. It was showing 28.5V during charging today, at a charge current of around 38 amps. The battery is 24v at 1200 A-hrs. The sun is down here now, and its at 24.5V with a draw of 12.8 amps.
Rereading your reply, you may be correct. The issue was happening last night during midnight. I arrived at the site around 10PM, and I left at 3AM, and I think I reset the Classic sometime between 1 and 2 AM (kind of blurry events, it was also snowing heavily).
Hopefully it will come back tonight. Any way you can get the system to respond quicker, like within an hour? Also, why does it rely so heavily upon the midnight reset?
Cheers,
Tracy
I hate to make a disparaging remark, but it's because the Ethernet code is junk. I've never seen a device so prone to crash the Ethernet!
Is there some jumper on the board that when closed will initiate a reboot? This way, you could use a remotely closed relay to reset the CLassic, without the expense of a SSR on both the panel input and the battery output..
I know you can reset from teh MNGP, but is there a HARDWARE pin header that will cause a reboot?
boB will be better to answer this but I know simply grounding the positive lead in the serial jack (MNGP or Follow me Jack) will reboot the controller as will grounding the Aux out if it is active. Basically anything that would over load the Aux supply will reboot the classic but I don't know if that's the proper way to go or not.
Ryan
Well, the midnight (midnite?) reset brought the unit back to life. I am now able to see and control the unit with the local app and see the data at Mymidnite.
One irritating issue is that I dont have any data during the outage: it does not download the logged data, only the current data. Therefore, I dont know how the system responded yesterday, or the day before.
Another very odd issue is the on board clock. The Local App is yellow, and the alert says the Classic clock is more than 10 minutes different from the PC clock. Indeed, it is 1 hour off. When I correct it, it goes back to green for a couple minutes, then goes back to yellow. My clock drifts, and I have corrected it many times before. But now, I cant. Another little issue that changed without me changing it!
Tracy
Do a search for 'clock battery' and you will get about 30 hits. Sometimes it has been some residual glue on the battery that was the culprit or maybe the battery is weak..
hth
Quote from: 2twisty on January 03, 2015, 10:22:22 PM
I hate to make a disparaging remark, but it's because the Ethernet code is junk. I've never seen a device so prone to crash the Ethernet!
Is there some jumper on the board that when closed will initiate a reboot? This way, you could use a remotely closed relay to reset the CLassic, without the expense of a SSR on both the panel input and the battery output..
I know you can reset from teh MNGP, but is there a HARDWARE pin header that will cause a reboot?
Yes, there actually is a way to reboot the classic via Aux 1 connection to ground.... If you simply set Aux 1 to "Manual On",
and had a relay that grounded that Aux 1 output for a second or two, the Classic should reset. This is not a "function" but
is like Ryan/Halfcrazy was mentioning..... The PTC resettable fuse opens up but before it does, the Aux supply is momentarily
overloaded and the processor resets. Since the processor itself resets and the PTC is open because the supply is satisfied
because it is not not overloaded, the Classic will reboot. Simply remove the Aux 1 short to ground and it will run.
As for data logging, you should have plenty of data from the minutely logs for things like battery voltage, input voltage, power,
charging stage, kW-hours produced that day, etc. This data logs every 5 or 10 minutes every day.
boB
Well, grounding AUX1 is not an option for me since I use AUX1 to start my generator. The idea of grounding the positive line from one of the serial ports is intriguing, but since it's a hack, I would be concerned about the possibility of damage to the Classic.
Is using that method a "supported" action? Would Midnite Solar refuse a warranty repair if they found out that someone was using this method to reset their classic remotely?
It would be easy enough to set that up, since phone cords are pretty common (or, rather, they *used* to be!).
Quote from: 2twisty on January 04, 2015, 10:34:34 PM
Well, grounding AUX1 is not an option for me since I use AUX1 to start my generator. The idea of grounding the positive line from one of the serial ports is intriguing, but since it's a hack, I would be concerned about the possibility of damage to the Classic.
Is using that method a "supported" action? Would Midnite Solar refuse a warranty repair if they found out that someone was using this method to reset their classic remotely?
It would be easy enough to set that up, since phone cords are pretty common (or, rather, they *used* to be!).
The serial port power output is actually another option. All of the 9 volt power outputs are protected by a PTC.
It'll be fine as long as you just short the +9V to negative for a second or so every time you need to reset.
But what do you have connected that can remotely trigger a relay or something to do this ? Will the Bogart do that ?
boB
I would use a relay triggered from a RasPi. Remotely connect to the Pi, reboot the Classic, and wait for it to come back online.
If the Ethernet code on the Classic was fixed, none of this would be necessary, lol
Quote from: 2twisty on January 05, 2015, 03:01:00 PM
I would use a relay triggered from a RasPi. Remotely connect to the Pi, reboot the Classic, and wait for it to come back online.
If the Ethernet code on the Classic was fixed, none of this would be necessary, lol
If youre going that far, then you will be better off looking at blackbox or similar. Blackbox seems to connect in a more robust way than the local app, at least for me i no longer get any classic coms lockups at all. The difference is in keeping the modbus link open permanently.
Well, It happened again. I am super frustrated. After the successful midnight reset, I used the local app a couple of times in quick succession, and it locked up. I then logged into mymidnite ,and it stopped updating.
I REALLY need this to work. I wanted good telemetry from the system remotely. I am not getting it.
I purchased the Classic because at the time, it was about the only game in town with a native ethernet port. They may still be about the only ones with a native port, but now there are several that have add on boxes. I am going to start looking into that.
You mentioned the Blackbox solution, I will do a search on it too.
Frustrated,
Tracy
Tracy,
Blackbox project on this site, here:
http://midniteforum.com/index.php?board=47.0
Good Luck, Vic
Quote from: thooker on January 05, 2015, 10:28:19 PM
Well, It happened again. I am super frustrated. After the successful midnight reset, I used the local app a couple of times in quick succession, and it locked up. I then logged into mymidnite ,and it stopped updating.
I REALLY need this to work. I wanted good telemetry from the system remotely. I am not getting it.
I purchased the Classic because at the time, it was about the only game in town with a native ethernet port. They may still be about the only ones with a native port, but now there are several that have add on boxes. I am going to start looking into that.
You mentioned the Blackbox solution, I will do a search on it too.
Frustrated,
Tracy
Tracy
In an act to find the trigger. You mentioned you used the Local App a couple of times in quick succession? Can you email me so we can get as much info as possible. Ethernet has just become Andrews ONLY project and he will get to the bottom of this. The problem is we can not reliably recreate your issue so more info via Email will help tons ryan@midnitesolar.com
Thank you
Ryan
also I should ask are you using the Local App for Android, iPhone or the PC?
FWIW, my Ethernet connection crashes almost every day. My midnight reset fixes it (and thanks to the new firmware, I can do this without starting my generator - THANKS).
How can I help with tracking this down?
Quote from: 2twisty on January 06, 2015, 05:28:14 PM
FWIW, my Ethernet connection crashes almost every day. My midnight reset fixes it (and thanks to the new firmware, I can do this without starting my generator - THANKS).
How can I help with tracking this down?
Thanks 2twisty.
Crashing every day is unusual nowadays except for certain systems evidently.
What does the rest of your system consist of ? What kind of Routers, bridges, etc.
Classic is connected to an 8-port TrendNet gigabit switch.
Switch is connected to an Amped Wireless wireless extender.
The Extender connects over Wifi to an Apple Time Capsule (this is the internet router and DHCP server)
Classic is set via Static IP.
Laptop connects to wireless extender via WiFi, and gets its IP via DHCP.
It is important to note that the Classic is the only device on my network that has any network performance issues at all.
I would ask anyone with classics that lose coms email me. A description of the network would be helpful also if you can ping it or not.
What I know for a fact is there is a bug int he Classic where the Modbus watches and if it sees no activity for say 30 seconds it closes the connection. The issue is the TCP?IP stack never gets the message and leaves that connection open.
So in conclusion what I suspect is on networks that are slightly busy or maybe have packet losses do to wireless extenders etc that they end up having that 30 seconds of quiet needed to cause this.
So 2 solutions I see
1- Raise the time out to say 2 minutes this way it will ignore a few lost packets
2- Fix the bug
Andrew's only project is to fix this so any and all info you want to email me would be super helpful
Email sent.
For my vote, I say do both fixes. Do #1 as a bandaid while you track down the real bug.
My local app is now losing communication with the Classic about 20+ times a day and about every 3 days I have to power cycle it because it disappears altogether. Nothing changed with my setup or the network in my house. Kind of stinks.
Quote from: Tons001 on January 07, 2015, 04:12:22 PM
My local app is now losing communication with the Classic about 20+ times a day and about every 3 days I have to power cycle it because it disappears altogether. Nothing changed with my setup or the network in my house. Kind of stinks.
What does your system consist of for routers, etc ?
Getting this information will be somewhat important.
boB
This is the equipment I am currently using with my Classic 150.
http://www.radiolabs.com/products/wireless/USB-Omni-Repeater-client.php (http://www.radiolabs.com/products/wireless/USB-Omni-Repeater-client.php)
The Classic 150 is hardwired to the WiJacker - USB Wifi Router Repeater with a 6 ft Cat5 cable. The CaptiFi Wi-Fi antenna is mounted outside and connects to the router with a 30ft USB cable and is not currently connecting to any Wi-Fi Hotspots due to low lake levels. So there is no Internet activity on this router. The latest Local App V 0.3.61 is on a Lenovo T540 Thinkpad Laptop running Win 8.1 and accesses the Classic by wireless G or N using the internal Intel Dual band Wireless AC-7260 Network Adapter. I have also run the LA on a Thinkpad T61 running Win 7 with the same results. The Laptop wireless distance from router is approx. 35-40ft. with almost straight line of sight. There are no other hardwired or wireless device on the local network. The Classic is set to Static IP. It is about the simplest network you can have.
I have also used a Linksys WRT54G for the router with the same disconnects. In reality the network disconnects with the Local App have existed since I purchased the original Classic 150 in early 2012. I have been waiting for MidNite to resolve it since then. Hopefully, we see some results from this effort.
The Local App will usually disconnect when dumping the OFFLINE Data. It is not 100% repeatable but this function seems to cause the most disconnects. You cannot get 10 consecutive dumps of the Offline Data without a disconnect occurring. It will at other time disconnect just monitoring the Live Data with the Local App. Most of the time the LA will generate the Reconnect and I can click the reconnect message and be back on line. I’ve had a few times that it required a reboot of the Classic.
My current Classic is using the latest firmware and is serial number CL11612.
• Classic 1849
• MNGP 1821
• NET 1839
Let me know if I can provide any additional information to help resolve this issue.
Quote from: Resthome on January 07, 2015, 08:28:59 PM
This is the equipment I am currently using with my Classic 150.
• Classic 1849
• MNGP 1821
• NET 1839
Let me know if I can provide any additional information to help resolve this issue.
Well dang ! YOU are using the latest and greatest firmware !
And the rest of your network is probably OK... But, as far as
the drops when you are downloading the daily logs data could
possibly be resetting the Classic at times...
We do know that the Classic will reset if more than one thing is reading
the logs data (graphics) at the same time... for instance, if you have two
MNGPs both graphing the daily or recent (minutely/hourly) history logs
OR a MNGP graphing those AND the Local App downloading the data
at the same time. This is due to multiple accesses of the internal EEprom
which stores the logging data and the way that it is being read.
The MNGP text data doesn't seem to mind multiple accesses AFAIK.
So, if that MNGP is not sitting on one of those graphing screens when your
LA stops/disconnects, then I"m not sure what that is exactly.
Next time you are up there, you might try unplugging the MNGP and see
then if you can dump the daily logs 10 times in a row without things
disconnecting.
Still, the problem is being worked on as we sleep.
boB
Quote from: boB on January 07, 2015, 08:35:44 PM
Quote from: Resthome on January 07, 2015, 08:28:59 PM
This is the equipment I am currently using with my Classic 150.
• Classic 1849
• MNGP 1821
• NET 1839
Let me know if I can provide any additional information to help resolve this issue.
So, if that MNGP is not sitting on one of those graphing screens when your
LA stops/disconnects, then I"m not sure what that is exactly.
Next time you are up there, you might try unplugging the MNGP and see
then if you can dump the daily logs 10 times in a row without things
disconnecting.
Still, the problem is being worked on as we sleep.
boB
Yeah, I'm well aware of that reset problem and the MNGP in the Daily Log window. My MNGP is always left in the main status window or the WBjr screen. You and I verified that repeatable bug earlier this year. So no these are NOT 104 RFR Watchdog Timer resets. They are straight network disconnects. The Classic is up and running during these disconnects. I'm pretty sure that Andrew uses the FTP transfer function for the OFFLINE data Transfer. So just another piece of the puzzle.
QuoteThe Local App will usually disconnect when dumping the OFFLINE Data. It is not 100% repeatable but this function seems to cause the most disconnects. You cannot get 10 consecutive dumps of the Offline Data without a disconnect occurring. It will at other time disconnect just monitoring the Live Data with the Local App. Most of the time the LA will generate the Reconnect and I can click the reconnect message and be back on line. I’ve had a few times that it required a reboot of the Classic
I couldn't have said it better myself. I actually avoid going to the offline Data section of the local app now as I know there is always a risk if I do so I will trigger a disconnect. The worst part about it is after the event the daily KWH count resets back to 0kwh :-[ and you can see it plan as day in the my midnight logs your at 12kwh then all of a sudden 0kwh in the middle of the day.
I'm running the latest firmware to and my network is very simple to. just a TPLink - modem / 4 port ADSL wifi router combo unit. I have cat 5 cable connected to one the routers ports going 30m to a simple Tplink 4 port switch in the power room with my two classic 150's connected to the that 4 port switch with 3 foot of cat 5 lan cable. So its all hard wired.
Just the same I have lots of other devises, weather stations, security camera's, inverters and PC's, laptops , tablets no other device or gadget has any issues with that network locally or remotely it's rock solid.
With the latest firmware I'm not getting the issues of the past where I loose all connection and cant reconnect. That's improved a lot and it always reconnects again reasonably fast if not strait away
Just this one little niggle / bug with the classic .... the resets has been around for a while . I have just learned what things to avoid doing on the local app to avoid triggering it . usually just let the app run in the main screen and don't mess about with changing tabs or downloading offline data .
Kurt
OK, I sent an email detailing my setup. In the interest of open communication, I have included it here.
Hi Ryan,
This is Tracy, and I am on the Midnite forum. I was asked to send you all the info I can on my ethernet crashes.
Frankly, lately it is like I have been walking on egg shells when I communicate with the Classic. I am very careful to not ask it 'too much'. I always tried to wait several minutes between turning on the local app.
My system is running a mountain communication site, which feeds a town of ~10,000 residents with internet. The wireless ISP uses my site to make the jump to the other town. A couple of days ago we had a cold snap and lots of clouds, so the battery voltage went a little below what the inverter could support. We lost AC power from the inverter, which took down their backhaul link. When the backhaul went off, the load on the batteries was lessened, which allowed the voltage to go up, and the inverter came back on. The ISP said that it was about a 2 minute on / 2 minute off cycle, which lasted for several hours before we could make the trip to the mountain top.
I have auto reset turned on, so it reset the charge controller at midnight, however, the up/down of the inverter was still going on at that time. Around 1 AM I reset the charge controller by turning it off, then back on. When I got back to my house at 4:30 AM, I tried the local app, and it did not connect. I tried to connect using the local app AND the mymidnite.com site throught the next day, and got nothing. I could ping the port correctly.
The following day I tried again using the PC local app, and it worked. Apparently the CC reset itself at midnight, and all was well. I noticed that the local app background was yellow, due to the clock being different from the PC clock. I dont remember the exact order, but within 1 minute I started and stopped, and restarted the local app on my PC, and from that point on, I had no contact with the Classic again. I tried on my android phone, same result. I looked at the mymidnite.com, and it was no longer updating. I could still ping the Classic.
I had to wait for it to reset again at midnight, which it did. The next morning (which was Jan 6) it was OK again. I have just tried to use the local app on both my PC and on android, in various combinations, to attempt to break the communications. It, of course, is working fine! I can not get it to break now. However, that does not mean that it is fixed!
I am pinging the port, and I get returns between 30 ms and 80 ms. My configuration is the following:
Both the site with the Classic and my home are serviced by the wireless ISP. At the site with the Classic, the Classic (static IP) is connected to a switch, then to the backbone radio 5.8 GHz link. It goes about 11 miles to the WISP headquarters. From there it goes to the internet, and also spreads out in a star configuration. One of those spokes goes about 5 miles to a tower, which then goes about 2 miles to my house via a Ubiquity RF link. At my house I have a Linksys WRT54G wireless router (static IP), which connects to my PC (Dynamic IP). Please see attached drawing.
Firmware: Classic 1849, Net 1839. S/N CL246. Local App version 0.3.61.
If there is anything else I can do, please let me know. It is VERY important to me to be able to see what the unit is doing. I have been (I believe) very patient with this process, but I dont like emergency trips to the mountain at 11PM!
A good sighn the little 3v lithium coin cell-watch battery size (1216) needs replacing in the classics display unit is when you get a yellow local app screen after a power cycle of the classic. As it looses it's date and time setting.Often overlooked preventative mantanance . I have mine down in the calander now for a watch battery change every 12 months.
Not the answer to the network issues but will help eliminate one variable.
Kurt
Quote from: offgridQLD on January 08, 2015, 03:32:00 PM
A good sighn the little 3v lithium coin cell-watch battery size (1216) needs replacing in the classics display unit is when you get a yellow local app screen after a power cycle of the classic. As it looses it's date and time setting.Often overlooked preventative mantanance . I have mine down in the calander now for a watch battery change every 12 months.
Not the answer to the network issues but will help eliminate one variable.
Kurt
Realize that the midnight auto-restart does not power-off and power-on the classic so the clock and calendar
will stay the same. Not sure what to say if the time/date changes after a reboot without power to the
Classic/MNGP going off and back on again ? That would be pretty weird but anything can happen.
Also, OffgridQLD, which inverter do you have with Ethernet ?
boB
All I know is I was getting lots of (yellow local app) time out of whack . Every time I would reset the time again it wouldn't last. So I went and replaced both the clock batterys in my two classics and Its been fine.
I was getting the yellow local app at times without fully power cycling the classics on the breaker. Im not saying it was happening after a 12pm reboot but it was happening some time through the day .....why how I diddn't investigate just changed the two batterys that were both low voltage- dead and its been all good. So I can only guess for some reason i was getting a power cycle of the classic over the day. The rest of the system never shut down so the classics always had DC power to them.
The inverter I have is a locally made.... (Australia) Selectronic PS1 6000w 48v inverter/charger. I just have it connected to my local network so I can dial in to its monotoring/logging software remotely.
Kurt
In the name of getting to the bottom of this (or just prove I am not crazy ;)
I took a small 2 min video and uploaded it on my you tube channel. I logged into my (house) classic 150 that has the WBJR on it using the android monitoring app. The system starts out in float around 11AM everything happy I then switch the screen to show the WBJR data and shortly after I get a small dropout in communication that quickly recovers (not so concerned about thisfast dropout & recovery but thought I would mention it anyhow)
Then I go to the (offline data screen) and within a second or two it loads the calender view with the offline data for each day. Then BINGO! you can see in the top left hand corner of the screen my classic is showing status is showing (Resting) then absorb and shortly after float . So by me going to view the (offline data) has triggered the full reset my classic. Because of this reset the classic cycles back to resting/absorb/float like its starting a new day. I then go to the total KWh for the day and it's been reset back to 0kwh :o
Like others have mentioned it doesn't happen 100% of the time but I got lucky this time while recording it and it did it first go for me. It's the same when using the (local app by midnite) on any platform. Going to the offline logs isn't the only way to trigger it but it seems like a good/reliable way to upset it.
So I use the local app very tentatively not to upset/reset my charge controllers.
I hope this helps in some way .
Anyhow link to the video showing what I explained above....https://www.youtube.com/watch?feature=player_detailpage&v=2DokCstXyQY (ftp://www.youtube.com/watch?feature=player_detailpage&v=2DokCstXyQY)
Kurt
So here is a big question. Is everyone that is having this issue using My Midnite also? Andrew has found a couple things already and they relate to My Midnite, Well they relate to the fact that if the Local app and My Midnite request data at the same time it overloads the memory
ok, interesting. Reading some of the folk above, there does seem to be a thread of 'first i tried local app on pc, then android, then mymidnite'. You have to wonder how about all those opens and closes and possible overlaps.
Since ive been using the single connection blackbox (only, use local app maybe 3 or 4 times a year for config), i havent had a single ethernet issue. My only observations are that in general modbus reads over ethernet are slightly slower than the previous firmware, and that the classic self reboots (lots) more often than the previous.
However seeing as Andrew is having a push on this i will reconfigure blackbox back to 1 minute, open, read and close. That setup would previously show up any issues within 14 hours.
I am using MyMidnite now, but had the problem before I started using it.
Quote from: Halfcrazy on January 09, 2015, 09:34:08 AM
So here is a big question. Is everyone that is having this issue using My Midnite also? Andrew has found a couple things already and they relate to My Midnite, Well they relate to the fact that if the Local app and My Midnite request data at the same time it overloads the memory
No MyMidNite in my configurations. So that isn't my disconnect issue.
Might want to note the comments by Graham on TCP traffic here.
http://midniteforum.com/index.php?topic=2136.msg21395#msg21395 (http://midniteforum.com/index.php?topic=2136.msg21395#msg21395)
Quote from: Resthome on January 10, 2015, 07:20:32 AM
Might want to note the comments by Graham on TCP traffic here.
http://midniteforum.com/index.php?topic=2136.msg21395#msg21395 (http://midniteforum.com/index.php?topic=2136.msg21395#msg21395)
Just want to mention a couple of things about my android app related to Kurt's video
when you slide over to the day log calendar, you are not triggering a read request for the logs from the classic at that point, the app has a background service that polls the classic and broadcasts the information to the rest of the app, each tab has a listener that receives the info related to itself.
+ the app maintains (up to) 3 tabs or views in memory at any time, the viewed tab and the one to the left and right, so when you slide over to the calendar, you are actually loading the chart etc.
the charts take longer to load than other views (the hour chart has 60 X 24 minute entries to load for 5 arrays of values) , that takes some cpu time away from the modbus service and that's when I see comms errors in wireshark.
Quote from: offgridQLD on January 08, 2015, 10:15:51 PM
In the name of getting to the bottom of this (or just prove I am not crazy
Then I go to the (offline data screen) and within a second or two it loads the calender view with the offline data for each day. Then BINGO! you can see in the top left hand corner of the screen my classic is showing status is showing (Resting) then absorb and shortly after float . So by me going to view the (offline data) has triggered the full reset my classic. Because of this reset the classic cycles back to resting/absorb/float like its starting a new day. I then go to the total KWh for the day and it's been reset back to 0kwh :o
Like others have mentioned it doesn't happen 100% of the time but I got lucky this time while recording it and it did it first go for me. It's the same when using the (local app by midnite) on any platform. Going to the offline logs isn't the only way to trigger it but it seems like a good/reliable way to upset it.
So I use the local app very tentatively not to upset/reset my charge controllers.
I hope this helps in some way .
Anyhow link to the video showing what I explained above....https://www.youtube.com/watch?feature=player_detailpage&v=2DokCstXyQY (ftp://www.youtube.com/watch?feature=player_detailpage&v=2DokCstXyQY)
Kurt
Kurt, are the MNGP in the Daily Log display window by any chance? Having the Classic MNGP in this window and doing and OFFLINE DATA export from the LA will reboot the Classic 100% of the time. It's a know bug. The RFR code is 104 I believe which is the Watchdog Timer reset. You might want to record and post the RFR code here the next time it Reboots like that. Also there were some Debug register on one of the LA status pages you might want to also post. They were suppose to help troubleshoot these reboots. That is if they ever got set to be the correct registers. boB, Andrew or Ryan will have to verify if that is still useful information.
Good news, sorta... Andrew has duplicated the problem and knows what is happening.
It's a packet memory re-allocation problem. When this happens, the Classic can not fill
the requested packet with data but it can ping, etc. since that doesn't require packet memory.
So, we are well on our way to finally getting this fixed. Not sure exactly when but this
is the highest priority at the moment so sooner rather than later I expect.
boB
John,
I don't think that would be my issue as both My classics MNGP are just in the home window or the screen they default to (I guess thats what you could call it) I avoid using the MNGP. As they are with the two classics out in the power room away from the house with the snakes and spiders ;D. All l monitoring and control and tweaking is over the the network.
Bob thats great news. Just being able to point to the problem is 99% of the challenge well done.
Kurt
Quote from: boB on January 11, 2015, 03:16:13 AM
Good news, sorta... Andrew has duplicated the problem and knows what is happening.
It's a packet memory re-allocation problem. When this happens, the Classic can not fill
the requested packet with data but it can ping, etc. since that doesn't require packet memory.
So, we are well on our way to finally getting this fixed. Not sure exactly when but this
is the highest priority at the moment so sooner rather than later I expect.
boB
boB, is this going to fix just the disconnects we have been seeing or is it going to fix the reset/reboot issue Kurt showed in his video also?
Quote from: Resthome on January 11, 2015, 09:15:12 AM
Quote from: boB on January 11, 2015, 03:16:13 AM
Good news, sorta... Andrew has duplicated the problem and knows what is happening.
It's a packet memory re-allocation problem. When this happens, the Classic can not fill
the requested packet with data but it can ping, etc. since that doesn't require packet memory.
So, we are well on our way to finally getting this fixed. Not sure exactly when but this
is the highest priority at the moment so sooner rather than later I expect.
boB
boB, is this going to fix just the disconnects we have been seeing or is it going to fix the reset/reboot issue Kurt showed in his video also?
Not exactly sure about reboots. This is mainly for the problem of disconnects. Reboots kind of fix the disconnect problems
by rebooting but you don't want rebooting either. We want to eliminate all reasons for rebooting the classic, either automatically
or manually.
Try doing THAT with Microsoft windoze !
boB
Dangit, boB, where's the LIKE button when you need it!
I think this thread has brought up at least three different issues that relate to data logging. Here is what I have heard in this thread and experienced myself.
1. The OP had brought up the issue when the Classic Ethernet disconnects and you can not reestablish the connection with the LA or MyMidNite without rebooting/resetting the Classic. While Auto-Reset may reestablish the connection after mid night, downloadable data is lost.
2. Disconnects that occur with the LA that with manual intervention can be reestablish.
3. The non initialed in day reboot/reset (Watchdog timer resets) that lose daily downloadable data and Lifetime accumulate data.
It sounds like there maybe a fix coming for #1. Not sure if the fix will address #2. And #3 is not part of this ethernet disconnect fix.
I consider the Classic a process computing device that needs to dependable and reliable. I don’t classify it as a home/business computing device therefore I don’t compare the Classic to a Windows device.
MidNite is a great company that offers excellent support. I look forward to having MidNite resolve these three issue that effect accurate recording and downloading of the Classic data.
Quote from: 2twisty on January 11, 2015, 07:57:57 PM
Dangit, boB, where's the LIKE button when you need it!
I have wanted to do that several times here !
Quote from: Resthome on January 12, 2015, 12:32:16 AM
I think this thread has brought up at least three different issues that relate to data logging. Here is what I have heard in this thread and experienced myself.
1. The OP had brought up the issue when the Classic Ethernet disconnects and you can not reestablish the connection with the LA or MyMidNite without rebooting/resetting the Classic. While Auto-Reset may reestablish the connection after mid night, downloadable data is lost.
2. Disconnects that occur with the LA that with manual intervention can be reestablish.
3. The non initialed in day reboot/reset (Watchdog timer resets) that lose daily downloadable data and Lifetime accumulate data.
It sounds like there maybe a fix coming for #1. Not sure if the fix will address #2. And #3 is not part of this ethernet disconnect fix.
I consider the Classic a process computing device that needs to dependable and reliable. I don’t classify it as a home/business computing device therefore I don’t compare the Classic to a Windows device.
MidNite is a great company that offers excellent support. I look forward to having MidNite resolve these three issue that effect accurate recording and downloading of the Classic data.
#1... If it gets fixed by auto-restarting at midnight, then that days' logs (downloadable data) will still be available because
auto-restart/reset saves the data first. If you manually reset or it resets somehow during the day then right, the data
won't save to EEprom.
#2. Depends on what is meant by manual intervention. If it is manual reset of the Classic, then that would be like #1 manual reset.
#3. During the day reboot/reset (WDT) is sort of understood, in that we know a scenario or two where this watchdog reset can happen
when two computers (2 MNGPs or MNGP and Local App), access a lot of EEprom, like daily or minutely logs at the same time. That one is easily understood.
But what about other WDT issues that are from something else ? Well, I/We have not seen this happen lately, BUT, there is
a debug method that was put into place in the Classic to save some of the states and information after one of these WDT
resets. In the Local App, it is shown in the "info" screen (I think) under Debug05 I think it is. After a reset during the day,
this number should be noted so we can figure out what happened. The more of those informational numbers we have,
the closer we will be to a fix for that. This number is also accessible by reading a modbus register but the LA is easy.
Also, remember that in the "secret screen" on the MNGP you can tell if the Classic did a WDT reset by going to the
secret screen (as I call it) from main status and looking at the RFR or Reason For Resting. At normal boot up it will
be 111 but WDT it will show 104 at the top middle of the LCD.
boB
Which regisister/address is debug5?
Quote from: boB on January 12, 2015, 02:09:38 AM
#3. During the day reboot/reset (WDT) is sort of understood, in that we know a scenario or two where this watchdog reset can happen when two computers (2 MNGPs or MNGP and Local App), access a lot of EEprom, like daily or minutely logs at the same time. That one is easily understood.
But what about other WDT issues that are from something else ? Well, I/We have not seen this happen lately, BUT, there is a debug method that was put into place in the Classic to save some of the states and information after one of these WDT resets. In the Local App, it is shown in the "info" screen (I think) under Debug05 I think it is. After a reset during the day, this number should be noted so we can figure out what happened. The more of those informational numbers we have, the closer we will be to a fix for that. This number is also accessible by reading a modbus register but the LA is easy.
Quote from: zoneblue on January 12, 2015, 02:49:20 PM
Which regisister/address is debug5?
wdt=`grep "^4131 " classicdata | /usr/local/bin/gawk '{print and($2, 128)}'`
if [ $wdt -eq 128 ]; then
mail -s "Midnight watchdog reset $$" rossw@*obfuscated.com* < classicdata
# and now clear the reset flag.
./newmodbus `cat classic.addr` 4131=12800
fi
Quote from: RossW on January 12, 2015, 03:47:21 PM
Quote from: zoneblue on January 12, 2015, 02:49:20 PM
Which regisister/address is debug5?
wdt=`grep "^4131 " classicdata | /usr/local/bin/gawk '{print and($2, 128)}'`
if [ $wdt -eq 128 ]; then
mail -s "Midnight watchdog reset $$" rossw@*obfuscated.com* < classicdata
# and now clear the reset flag.
./newmodbus `cat classic.addr` 4131=12800
fi
The last LR register contents before the WDT reset are in kept in these two modbus register addresses...
4386 DabtU32Debug05 (low 16 bits)
4387 DabtU32Debug05 +2 (high 16 bits)
These values will read the last LR registers' contents right after the Classic reboots from the WDT.
boB
Quote from: boB on January 12, 2015, 02:09:38 AM
#2. Depends on what is meant by manual intervention. If it is manual reset of the Classic, then that would be like #1 manual reset.
No it would be more like closing the LA and then restart the LA. Some folks have said they may restart Windows. Then the connection is reestablished.
#3. During the day reboot/reset (WDT) is sort of understood, in that we know a scenario or two where this watchdog reset can happen when two computers (2 MNGPs or MNGP and Local App), access a lot of EEprom, like daily or minutely logs at the same time. That one is easily understood.
But what about other WDT issues that are from something else ? Well, I/We have not seen this happen lately.
boB .. Does not sound like you noticed one of these reset in the video Kurt posted earlier in this thread using the Android app. So the resets are not just with the LA. I’m glad you brought up posting the debug info, so more people are aware of it and will report that info but they would have to be using the LA. If I remember correctly they show all zero when things are working fine.
https://m.youtube.com/watch?v=2DokCstXyQY (https://m.youtube.com/watch?v=2DokCstXyQY)
Are we talking about this (debug info?) below from the info tab of the local app on both classics.
From my shed classic
DB1: 0x-604b092d
DB2: 0x110d244b
DB3: 0x3a18e3a9
DB4: 0x3a18e3a9
DB5: 0x0
From my house classic
DB1: 0x30b2e0c0
DB2: 0x-5070000
DB3: 0x43d04000
DB4: 0xdfa000
DB5: 0x0
Kurt
Quote from: offgridQLD on January 12, 2015, 11:40:56 PM
Are we talking about this (debug info?) below from the info tab of the local app on both classics.
From my shed classic
DB1: 0x-604b092d
DB2: 0x110d244b
DB3: 0x3a18e3a9
DB4: 0x3a18e3a9
DB5: 0x0
From my house classic
DB1: 0x30b2e0c0
DB2: 0x-5070000
DB3: 0x43d04000
DB4: 0xdfa000
DB5: 0x0
Kurt
Yes.... And they are 0x0 so either no WDT reset or very old code
My local app also says 0x0, appears to always have done so. However the last reboot was a WDT reboot, 5 days ago.
peter@cubie:$ ./newmodbus 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 20:23:14 08/01/2003
4380 10 (0xA)
4381 378 (0x17A)
4382 57 (0x39)
4383 0 (0x0)
4384 0 (0x0)
4385 576 (0x240)
4386 193 (0xC1)
4387 31720 (0x7BE8)
4388 2 (0x2)
4389 0 (0x0)
4390 64599 (0xFC57)
Quote from: zoneblue on January 13, 2015, 01:48:23 AM
My local app also says 0x0, appears to always have done so. However the last reboot was a WDT reboot, 5 days ago.
peter@cubie:$ ./newmodbus 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 20:23:14 08/01/2003
4380 10 (0xA)
4381 378 (0x17A)
4382 57 (0x39)
4383 0 (0x0)
4384 0 (0x0)
4385 576 (0x240)
4386 193 (0xC1)
4387 31720 (0x7BE8)
4388 2 (0x2)
4389 0 (0x0)
4390 64599 (0xFC57)
That should be it ! Are these addresses or register numbers ?
What version of software too ?
boB
For me it's.....
classic Firmware:
- Classic Rev: 1849
- Network Rev: 1839
Local app Version 0.3.61
Kurt
Im also 1849. Latest local app. Newmodbus uses registers, ie starting at 4101.
Quote from: boB on January 13, 2015, 04:02:09 AM
Quote from: zoneblue on January 13, 2015, 01:48:23 AM
My local app also says 0x0, appears to always have done so. However the last reboot was a WDT reboot, 5 days ago.
peter@cubie:$ ./newmodbus 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 20:23:14 08/01/2003
4380 10 (0xA)
4381 378 (0x17A)
4382 57 (0x39)
4383 0 (0x0)
4384 0 (0x0)
4385 576 (0x240)
4386 193 (0xC1)
4387 31720 (0x7BE8)
4388 2 (0x2)
4389 0 (0x0)
4390 64599 (0xFC57)
That should be it ! Are these addresses or register numbers ?
What version of software too ?
boB
Zoneblue,
4387 31720 (0x7BE8)
4388 2 (0x2)
0x00027BE8
Well, unfortunately this one wasn't too enlightening.... The WDT timed out
in the middle of clearing the Whizbang Junior Amp-Hours to zero. Just an
instruction in the main() area of code.
Please keep noting this value if it is convenient and you see it happen again.
Much appreciated !
boB
This mornings reset, appears to yeild the same debug5 data.
peter@cubie:/home/www-data/html/blackbox/modules/midnite_classic$ ./newmodbus.1.0.18-ARM 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 08:49:05 02/01/2003
4380 10 (0xA)
4381 369 (0x171)
4382 79 (0x4F)
4383 0 (0x0)
4384 0 (0x0)
4385 601 (0x259)
4386 171 (0xAB)
4387 31720 (0x7BE8)
4388 2 (0x2)
4389 0 (0x0)
4390 913 (0x391)
Hmmm... Interesting. Let's see if Andrew sees something that I don't here.
Thanks again for the info !
boB
I finally figured out where you were getting the debug info:
DB1: 0x-3534788
DB2: 0x-190c6aa5
DB3: 0x5c4a8fb6
DB4: 0x5c428f96
DB5: 0x0
Quote from: thooker on January 19, 2015, 09:25:48 AM
I finally figured out where you were getting the debug info:
DB1: 0x-3534788
DB2: 0x-190c6aa5
DB3: 0x5c4a8fb6
DB4: 0x5c428f96
DB5: 0x0
Yes, correct. This tells me that you did not have a Watchdog reset at least.
That is, if your firmware is not too old. The original DB5 error codes were
either 0x0 or incorrect. They have been at least approximately correct for the
last year or so.
boB
Firmware:
- Classic Rev: 1849
- Network Rev: 1839
Latest FW version is 1933
Hm, OK. Next time I make the 3 hour trip to the site I will update it. Sure would be nice if I could update it remotely, or it could update itself.
Do you really want to leave your system open to being hacked ? That is a real possibility boB mentioned when asked, and recommended against...
I too have a 3 hr drive and would like to be able to do it but don't like someone screwing with my system
Any update on this? It sounded like a firmware update was imminent, and then is just all went dark.
It's in the mail? ???
Hi, everyone. I've been banging away on the Ethernet stack and communications with my full attention. I am almost at the point for a new ALPHA test release for anyone who is interested in testing. I'd especially like those who have been having a bad time getting to MyMidNite as well as folks who have had to resort to the forced DNS fix (DNS override). I'd like to bang on this for another week and then I should be ready to get it out for testing. Thanks again for your patience on this.
Ethernet progress :) good to read you are spending time improving robustness... any chance of getting a second TCP connection on the stack :P
dgd
No, I'm afraid a second connection will never be part of the Classic. The code was designed entirely around only one listen connection, for better or worse.