Local App software

[Tinman]

If you happen to have an extra telephone cable that you can cut one end off of, and you
short ALL of the wires together, Plugging it into the battery temperature sensor phone jack
should make all the fans turn on and the display should show 100 degrees C.

As long as you cut the unused end of that cable off, cut off the locking tab from the
test plug end so you don't have to use a screw-driver to un-plug it, or just to make
it easier to pull back out again.

boB

I have enough cabling to re-wire New York. 

I PM'd Halfcrazy about the display and not remembering the time/date between reboots. Everytime thing. Goes to 00/00/2000 and time of battery breaker disconnect.

[atop8918]

Tinman, you rock! Thanks for trying out so many configurations. You probably just saved Ryan hundreds of hours of service calls with folks who are running Win7 without SP1.

Here is some more general info for folks who are trying to connect directly to the Classic either with a crossover cable or through a switch on a dedicated network/subnet. (Note that if you use a ROUTER with DHCP capabilities on this private network then you can skip the rest of this).

The Classic has DHCP enabled by default. If you plug it straight into your PC chances are it will NOT work unless you are running a Linux or Windows server on your machine. The following is the recommended way to handle this case:

First setup your PC:
Set your LAN IP address to your desired subnet. I recommend something like 192.168.13.1. Set your subnet mask to 255.255.255.0. Gateway and DNS are not required in this case.

Now on the Classic set the NET series of menus set the following:
MODE: STATIC
IP: 192.168.13.100
SN: 255.255.255.0
GW: 192.168.13.1 (same as your PC)

You can skip D1 and D2. If you are on a private network/subnet you can also disable web access to reduce the traffic on your network.

Now you and the Local App should be able to access the Classic using a crossover/private network.

To test, open a console window (Windows Start->run->cmd, Mac Applications>terminal, Linux -- really?) and run:

ping 192.168.13.100

You should see the pings returning with a time value in the millisecond range otherwise you will see an error indicating that the IP address could not be reached.


Note that before you go mucking about changing LAN IP settings on your machine, at the very least write down all the settings that where there BEFORE you changed them. I am unable to guide you in re-setting up your personal network if you change it according to these instructions.

[boB]

I PM'd Halfcrazy about the display and not remembering the time/date between reboots. Everytime thing. Goes to 00/00/2000 and time of battery breaker disconnect.

I just realized that you are talking about the time and date in the MNGP/Remote itself where the main time and date should be held,
even when the power goes down.  I would check the clock battery (3V coin cell) in the MNGP.  Maybe it is dead or there is
still an insulator between it and the battery holder ??  It should be higher than about 2.0 volts to keep the internal clock/calendar running
when the power goes out.  You can measure POSITIVE at the TOP of the battery holder with respect to GND or NEGATIVE.  Battery negative is one place for the multi-meter reference, or, if you have a steady hand, the left most pin on the LCD connector of 20 pins (pin 1) is GND.

We put the insulator on every MNGP battery so that if the Classic is sitting on some distributers' shelf for a year, it doesn't run the
battery down.  When the Classic is powered up, the coin cell battery in the MNGP ~should~ not have to power the clock.

Now, here is my explanation for the Classic (control board PCB) and how its internal clock works without an internal battery which was my
first response to your question, Tin Man..........

The time is held in the MNGP itself which has the battery.  When the Classic boots up, or re-boots, it tells the MNGP that it needs its time set.
The MNGP responds but only when the MNGP is in the MAIN STATUS menu (this will be able to be done in other places eventually).
It may be that if the Classic is unsuccessful that it gets set to year 2000 maybe.  Also make sure the time and date is set correctly in the MNGP.

You can also set the time and date in the Classic to the MNGP's time/date by going to the MNGP's MISC menu, time,
and pressing ENTER from the MNGP time/date setup screen.  That sends the time/date to the Classic itself.
If the Classic's power did NOT go off during the reboot, then the time and date ~should~  be still good, as the processors'
internal clock and calender were still powered up in that case.  The Classic booting will still request the time and date from the
MNGP though, so it may be that the MNGP isn't responding.

Another thing may be that this is older software where time and date issues were not handled as well as they are now.
The next release, coming up in a few days will be better.  What the Classic will do is to set its internal date to 05/04/2003 so we
know that it just didn't get initialized.  Otherwise, the Classic will be all 00000s and would show  00/00/2000 like you are seeing
now I think.

It's a lot to remember, but I figure its as good a place as any for me to write this down so I know where to copy this info from as well.

boB

[Tinman]

Thanks. The controller is handling solar harvest just fine and verified by the condition of my batteries. These little things aren't show stoppers and knowing there is continued work everything is stellar.

We have rain tomorrow and Friday, possibly Friday so that is inside work time, getting the remote mounted properly, ordering new batteries and so on.

The Classic 150 is tops in my book and glad I have it.

[Tinman]

The issue of the Date/Time not carrying over after a reboot/power off is resolved. It was the grunge on the back of the battery, the battery was fine.

As I said in another post, it is the residue from packaging or that insultaor pull strip that caused the problem. It sorta burned onto the back of the battery, forgot to take pictures. Anyway, all is well with date time now.

[Tinman]

Now the Local App isn't retaining the scale for power (watts). I had set it to the lowest value since I have a smaller system. Today, fired up the tablet and after the sync, that scale is back to the maximum (5 kw). Strange. The Classic hasn't been rebooted. It went to rest last night but that is all.

I still have no readings for amps on the status either for daily or lifetime. Is that not functional? It would be really nice to know what I'm putting into the batteries or my harvest without running calculations. When I chart it the values presented are exactly the same if I choose hourly. There is no way the same amount of amps are going into the battery or coming down from the panels every hour, just not possible.

Let me know if those measurements are not yet working, I'll stop looking for them to show up until a future application release.

[attachment deleted by admin]

[Halfcrazy]

TinMan
The Power scale is remembered on the PC but if the Local App is Updated it loses that setting. I will mention to Andrew that user settings need to be retained during an upgrade.

As for the  Amp Hours I understand that is not functional in the Classic yet so the Local App does not have that Data I will ask boB today when we should expect that to be functional.

Ryan

[Tinman]

No worries. Completely understandable that not all features will work on a first out application (ask me how I know). It isn't critical and the app is pretty stable. It's one of those things, you get a taste of the goodies and then you get the wants. You should have seen me begging and badgering ASW to get the 150 Classics. Gotta have the best you know. 

[Tinman]

Local app starting to be unstable. Several days in a row now, the local app simply stops working. The remote monitor works as it should but the local app freezes and even after close and restart (the app) the data is not maintained.

Pictures attached. For example, today at around 1pm the local app stopped functioning. You can see the flatline of data in the chart and all the gauges also freeze. Until a few days ago it was running ok. This is a closed network, just the router, the Classic and a TabletPC running Windows Xp are on it, no internet connection, no other clients. The next two posts will have the other pics showing nearly identical timed pics of the remote and the local app.

Not sure what is going on. Not messing with the settings or charts at the time. This has happened both when displaying a chart for extended periods and just showing gauges.

[attachment deleted by admin]

[Tinman]

Here is a pic of the remote monitor, next is the local app, frozen. Notice the difference in information even though the pics are taken at the same time (within seconds). The difference is not attributable to actual panel/system performance as the local app stayed that way until it was restarted.

No data is logged when the local app freezes. The data is then missing completely from the local app.

[attachment deleted by admin]

[Tinman]

And now the local app. The remote monitor operates normally, the local app stop recording/displaying data.

This seems pretty consistent now. The result are some pretty significant gaps in recorded data.

[attachment deleted by admin]

[Halfcrazy]

I will bring this to Andrews attention today.

Ryan

[dapdan]

I can concur with everything that tinman has said about the local app locking up. I just chalked it up to bugs in the app and I am waiting patiently for you guys to sort it out, for now I have to reset classic when the app locks up. I would love to see the internet version up and running so I can visit my classic via a smart phone.

Cheers...
Damani

[Tinman]

Instead of rebooting the Classic try closing the application, dropping your connection to the client (PC) and then connecting and running the application. I found that works well instead of re-booting the Classic.

My comments on Internet access to the Classic.

While I would welcome an Internet app for accessing data via Smartphone (I do this for a number of my own applications) I wouldn't use a cloud service based application host, no matter who runs it.  Having gone that route for Enterprise class services the complexity and reource demands are very significant. Even if the solution is hosted via third party, no one has been able to get it right yet, Apple, Google, RIM you name it. Much rather have a rock solid local app that can be accessed via a VPN or a native one just pulling or getting pushed data right from the Classic or even an application running on the LAN. I ran the data center for a statewide government agency having a whole team of sys and net admins working for me and maintaining even 3 9s of service is a huge undertaking. Just my 2 cents but I can deal with my connection and solid applications running locally but accessible remotely. Connecting to cloud services for access to my Classic will create a huge resource drain for Midnight when it doesn't work. When the whole "all eggs in one basket" is really figured out I'm all in but until then, even a small glitch in that infra  structure can bring a company to it's knees in short order. Let the remote smartphone app call home, not a cloud service. My solar install is now mission critical. No way am I going to sit there wondering if someone else got through a data center or server sitting somewhere. Realistically, cloud services for mission critical applications are off 5 years and anything else is marketing.

[Tinman]

Temporary solution. If you set a task to run once an hour then close and restart you can most likely avoid the application hang. Use task Scheduler to do this. You can probably set it to run/close/run more frequently but I don't know if that will make any difference or add benefit. Unknown is if this will corrupt any data stores for the local app. Perhaps someone can answer that?

If no data corruption is likely then this is a quick fix. The question then is: are the data stores closed at commit or do they remain open? If the application is closed via task scheduler, does the application roll back for any reason? If the answer is no then using Task Scheduler is a nice quick fix for us.

I've tried it and so far no issues but it will take a day or so to prove this all out.