I got the local app. working 2 days ago and then all of a sudden last night I started seeing device not available on both the desktop and the laptop. I turned the Classic on and off about 4 times and did the same with the router but no luck. Anything else I can try? I was loving it while it was working.
NO! One cannot live without that local app ! I know I can't at least...
Is the Classic still getting a DHCP local IP address from your router ??
To test, you can change it to STATIC, change to some different IP address
and then set it back to DHCP and the IP address should change again.
That will tell if the Classic is still talking with the router at least.
I don't suppose you may have accidently change the port from 502 to
something else from the local app ?? If so, then it is possible the Classic
cannot be found because of that. With the MNGP (remote) go to the
MISC menu and then COMM sub menu and make sure the port is
set to 502.
Or, did you accidentally uncheck the Auto-Detect Classic in the local app
configuration menu ?
You can also type in the Classic's IP address and its port (usually 502) in
the configuration menu of the local app which you will want to try.
To get that IP address, again, go to the NET menu in the MNGP
and let it get an IP address from your router then set it to STATIC
so that the Classic stays with that IP address (something like 192.168.1.123
or 10.x.x.x etc.) nad it should not change from there on.
Let us know if that helps.
boB
You are the man boB! I had already tried just about everything you mentioned except one thing. I hadn't double checked the port on the Classic. I didn't think I had changed it so it wasn't something I was looking at but apparently I had accidentally changed it to 501. All is well in solar land again. Thank you!!
Excellent !
This thread is a little old. But I have noticed that after the last firmware update my Classics stop communicating with the Local Status Panel after 2-3 days. I can ping the Classic's static IP address and the ping responds fine. But the only way (that I have found) to get the Classic and Local Status Panel to talk to one another again is to reboot the Classic. Then it's good for another 2-3 days.
This only has happened here since the last firmware update.
Another thing I have noticed that is different, is that with the previous version of the Status Panel I was able to give each of my Classics names. I can't find that option in the latest version of the Status Panel. The Classics retained their names I had given them during the latest firmware update, but it appears I can't change it anymore.
--
Chris
Quote from: ChrisOlson on July 30, 2012, 10:20:13 AM
This thread is a little old. But I have noticed that after the last firmware update my Classics stop communicating with the Local Status Panel after 2-3 days. I can ping the Classic's static IP address and the ping responds fine. But the only way (that I have found) to get the Classic and Local Status Panel to talk to one another again is to reboot the Classic. Then it's good for another 2-3 days.
This only has happened here since the last firmware update.
Another thing I have noticed that is different, is that with the previous version of the Status Panel I was able to give each of my Classics names. I can't find that option in the latest version of the Status Panel. The Classics retained their names I had given them during the latest firmware update, but it appears I can't change it anymore.
--
Chris
Uh Oh ! I'll try to get the others to check out this thread, Chris.
Is the Classic set as STATIC or DHCP IP address ? Sometime static IP addresses can conflict with things. Not sure about the name though.
The name shouldn't have anything to do with things.
boB On the road but back to the office tomorrow.
The new local app has all the 2 way programming and the name is in that category. So to use those functions it requires the latest version of Classic firmware. The newest Classic firmware has some more tweaks as well that may help with the lost network function.
Ryan
You mean newer firmware than what I got from June 26 or 29, or whatever it was?
I got my router set up with a IP block that is used specifically for static IP's and is not in the DHCP pool. I run each Classic on one of the static IP's in that reserved block, and I run each one on a different port so I can port forward the ports for each one thru the router to the outside world. That way I can access them all from a remote location. This has worked fine for 6 months until this latest Firmware update.
When I'm on the LAN with the Classics, with the old Local Status Panel I used to have to tell it which ports to look on for each Classic that wasn't on port 502. But with the newest Local Status Panel it has found the other Classics running on ports 503 and 504 by itself.
When one drops off and won't communicate with the Local Status Panel anymore I just wait until it rotates its logs (so I don't lose the day's power production data), then reboot it. A reboot brings it right back online. When it drops off it won't communicate with the Local Status Panel either on the LAN, or thru the router from a remote location.
I could try to gather some more information and details on what I see it doing if it's not a known issue, as I just updated to the newest firmware roughly a week ago. I have noticed there must've been some "tweaks" to how the MPPT is done on solar because it used to run my panels at 105-108 volts in hot weather. With the new firmware I see it running the panels at up to 123 volts at times, and it seems to be squeezing a few more kWh out of them.
--
Chris
Chris
Is every thing else like the charging algorithm and screen working as planned?
Ryan
Quote from: Halfcrazy on July 30, 2012, 01:29:11 PM
Is every thing else like the charging algorithm and screen working as planned?
Yep. When it quits communicating, absolutely no problems with the controller itself, none of the menus, or anything else.
One thing I haven't tried it manually switching it to a different IP address to see if it comes back online without a reboot. In fact, I have one as I write this that isn't communicating with the Local Status Panel. I'll go try that and see if it works to bring it back online.
Nope - don't work. This is what I had (see attachments).
I changed the static IP to 192.168.0.5 and the communications port to 502 to see if it would communicate with the Local Status Panel. Nothing. I manually entered in the static IP and port in the Local Status Panel for it and it said it was trying to connect, but then comes up with "Busy".
But I think I may have stumbled upon something - I tried switching it to DHCP and it looks like the DHCP client in the controller is hung - it won't get an IP address from the DHCP pool. I went to another controller that's presently communicating OK, switched that one to DHCP, and it instantly got a DHCP lease from the router and a IP address from the DHCP pool.
So I'm going to conclude that there's a problem with the DHCP client in the controller crashing or hanging after awhile and tying up the IP networking when it crashes or hangs (just a theory).
Edit: Or the TCP/IP stack just crashes. Do these things have a Linux kernel running the OS in them?
--
Chris
Chris
Good stuff. Andrew thinks he must have introduced a timing error somewhere in hos code. He is going to go rooting around and see what he can find.
Ryan
Ryan, this doesn't seem to be consistent for some reason.
My solar controller dropped offline (with the networking) only once after the firmware update, and now it's been fine ever since. Both wind controllers have required two reboots to get them to communicate with the Local Status Panel since the firmware upgrade and I just rebooted both of them last night again (now three reboots). Almost like clockwork the wind controllers have been dropping offline after about 48 hours. But the one on the solar panels seems to have no problem.
I'll report back in two more days to let you know what happens after last night's reboot.
--
Chris
Hi, Chris,
Sorry about the disconnects, I'm checking through the code.
I have noticed that when I lose comms with the Classic using the Local App, closing the Local App for a minute or two and then bringing it back up seems to solve the disconnect problem.
I'm working on a better solution for this, but maybe that will help in the meantime?
Sorry for the troubles!
Andrew, it's really weird.
My solar controller has no problem at all after the last reboot, and it has been fine for over a week.
Both of my wind turbine controllers dropped offline at roughly 37 hours after the last reboot and neither will communicate with the Local App on either of two different computers. The initial message is "Busy" and then it drops off the list of controllers all together until I reboot them again.
There's nothing else in the controllers that appears to be affected. They work fine - only the networking part with the Local App. I can ping them (they have static IP's) and they respond to a ping fine.
But it's only the two controllers using Wind Track Mode that it appears to happen to after this last firmware update. I don't know if that means anything, but hopefully that info will help track it down. If there's anything else you would like me to try for diagnostic purposes before I reboot them again (while they're both not communicating), let me know and I'll do it.
--
Chris
I am having the same issue. I am no longer able to use the local app but can ping the static IP of my classic 150. I updated to the latest firmware a few weeks ago and all was well until this week.
Really strange - I can telnet to one of the controllers that's offline on port 502 and it responds. I'm not sure if the Classic has telnet capability but when I telnet to the solar controller (that's running on port 503 and working normally with the Local App) it comes up with the same response - "Press any key to continue".
So the networking adapter in the controller that is offline with the Local App is working and the port is open and communicating. Just that it won't talk to the Local App.
--
Chris
I have decided that something had to have gotten corrupted during the update of two of my controllers. It's impossible to have one that works flawlessly if there's something wrong in the code.
So I deleted everything on my computer (including the Status Panel .com folder in Application Data in my user account), redownloaded the firmware updat and status panel installer, and am going to re-install everything on both of the controllers I've been having problems with.
Hopefully it will fix the problem. I got to thinking about this and I had updated the Solar controller (which has continued to work with no problems) first, and didn't do the two turbine controllers until a day later because both turbines were running at the time. With the SNAFU with my com port, something may have gotten screwed up.
--
Chris
Quote from: ChrisOlson on August 12, 2012, 10:00:27 AM
I have decided that something had to have gotten corrupted during the update of two of my controllers. It's impossible to have one that works flawlessly if there's something wrong in the code.
If this is the case, and of course it can be, I would suspect the PC side if anything.
If it's XP, the directory where the settings and things are stored is in the Documents and Settings --- USER---
Local Applications directory I think.
On my new windoze 7 system it is here...
C:\Users\boBWin7\AppData\Roaming\com.midnitesolar.LocalStatusPanel\Local Store
You can just delete that directory which I have done in the past. I don't understand
how it would cause things to disconnect after a while though.
I would be surprised if it is in the Classic but you could try updating it too.
boB
boB, I think it just has to be. I've worked with computers and computerized systems long enough to know that you cannot have one unit operate flawlessly, and two that don't, all under the same conditions, and have something wrong in the code. I hate to have Andrew looking for something that's not wrong.
So I just updated both of those controllers again, plus the MNGP on both, deleted everything on my computer, including all the registry entries that remain, and re-installed it. And I'll see what happens. It's all working perfectly again right now after I re-did all of it.
With the com port issue I had I think I re-booted both of those controllers too fast and too many times trying to get it to work. Something may have gotten corrupted in the controllers doing that too. I think that because both of them, when rotating their logs, ended up with invalid dates on some of the days. The solar controller that has been working fine hasn't done that. I attached an example from one of them, and this is really weird because it logged .5 kWh on Day 23 on 2/22/2094 - and Day 22 shows as Invalid. The turbine was not even running on those days. It was off the tower for three days because I put up a new tower and moved the machine to the new tower. The controller was not powered down during that time frame, although the DC input breaker was shut off while I re-wired the service from the new tower. And this is what it stored in its logs.
That indicates to me that I screwed something up in the firmware updates on those units.
--
Chris
Quote from: ChrisOlson on August 12, 2012, 01:51:27 PM
That indicates to me that I screwed something up in the firmware updates on those units.
--
Chris
OK, we'll see. But, I DO see weird time/date stuff once in a while and so that may (or may not) be
a real problem. When you turn on the Classic/MNGP main battery switch, remember that the MNGP
sends the time/date to the Classic itself every minute or so.
Maybe the Classic tried to log while either the MNGP was sending data (highly unlikely) OR maybe before
the MNGP had sent the time/date info to the Classic for the first time after power up (Classic starts up
at year 2000 or 2003 I think it is), but I thought I remembered the Classic as not being able to log
until after the time/date had been set.
Also, realize that inside the MNGP code, it will sometimes increment/decrement the day number (the day
index) and the actual logging day may not inc/dec. That is something I need to look into, but the date/time
can pretty much be trusted. The index day number is there in addition to the time/date to tell where in
the 380 day or data point log you are at. But it should coincide !
It may be that you incremented the day index but it was trying to go to a day that had not been filled yet ?
I must admit that there have been some reports of bogus or double/redundant logging days which I have yet
to figure out but at least the time/date is usually there and not invalid.
Thanks for keeping us posted.
boB
Thanks boB. It's possible I'm wrong. But I felt, knowing what I did, that I should at least try a clean install of everything to rule out a corruption in the code caused by improper re-booting. I'm pretty sure that if you take a regular computer and just flip the switch on and off several times while it's booting up it's going to come up with something pretty bad in short order with corrupted files on the boot section of the disc. That's basically what I did with those two controllers when I had a com port conflict. ;D
I know on at least one of them I got too eager and flipped off the breaker before I got the message in the command window "Successfully Updated". It was at 100% but if you wait for a bit you get that message and THEN you reboot it. It can take 10-15 seconds for that message to appear, and maybe other folks have gotten too impatient and done the same thing, so they're having problems too.
I'll know in a couple days if it "fixed" it. ;)
--
Chris
Quote from: ChrisOlson on August 12, 2012, 03:16:59 PM
I know on at least one of them I got too eager and flipped off the breaker before I got the message in the command window "Successfully Updated". It was at 100% but if you wait for a bit you get that message and THEN you reboot it. It can take 10-15 seconds for that message to appear, and maybe other folks have gotten too impatient and done the same thing, so they're having problems too.
I'll know in a couple days if it "fixed" it. ;)
--
Chris
Maybe it's kinda like wondoze applications where it counts up to 100% but it's obviously still doing "something".
I could add a wait countdown timer after the 100% done shows up in the update application.
boB
Hi Bob,
I agree with the latest remark.
If you don't read the manual with a lot of attention, when you see in the update window, the 100% done information, you think that the update is finished.
You must wait one minute after, to have this window automatically closed!
Yann
Guys, I think it's been over 48 hours since I re-updated the controllers that were having a problem. I have not had a problem since, with either of them.
It was not the Local Application. It was the controllers. The reason I know it was not the Local Application is because I only replaced that in one computer and left it in the other one. The controllers have been communicating fine with the Local Status Panel ever since, on both computers. This is the longest those controllers have stayed communicating with it since the original update.
So I'm going to guess by not waiting for that final message and flipping the breaker off as soon as it says 100% screws something up. The controller still works, but it can have problems.
I don't think there's anything wrong with Andrew's code. It was my own screwup.
--
Chris
Quote from: ChrisOlson on August 15, 2012, 12:22:24 AM
Guys, I think it's been over 48 hours since I re-updated the controllers that were having a problem. I have not had a problem since, with either of them.
It was not the Local Application. It was the controllers. The reason I know it was not the Local Application is because I only replaced that in one computer and left it in the other one. The controllers have been communicating fine with the Local Status Panel ever since, on both computers. This is the longest those controllers have stayed communicating with it since the original update.
So I'm going to guess by not waiting for that final message and flipping the breaker off as soon as it says 100% screws something up. The controller still works, but it can have problems.
I don't think there's anything wrong with Andrew's code. It was my own screwup.
--
Chris
OK, thanks Chris !! Very interesting !
I will take a look at the update code and see if I can make that work a bit better. I can change the message ending to
make it say whatever it needs to say at the proper time to get things to work more consistently for you and others.
boB
Well, the real test is time. It's been a week and not a single problem with it.
So I can only conclude that my problem with communications with the Local App was being caused by a corrupted firmware update in the controller - caused by me. I'm sure that what I did was to flip off the breaker to power the controller down before I got that message in the command window that says it was successfully updated.
--
Chris