MyMidnite Classic 150 Stops Responding

[TeslasPigeons]

Hey All -

I have been working on connecting to a Classic 150 for a preserve to be able to display the data.  I first used the newmodbus utility via LAN and a raspberry pi with internet access disabled on the Classic 150.  That worked for about 2 weeks and then the classic stopped responding.  The only way to fix it was to power cycle the Classic 150.  Figuring it was a local network issue I put together a RS-232/RJ-11 cable and connected to the modbus port on the Classic 150 and read the holding registers directly with the Pi and Python libraries.  That worked perfectly for about 10 days.  Now the charger is not responding again and I'm really not sure what the issue is... anyone ever run into anything like this?

And I have midnight reset turned ON, but it doesn't seem to do anything once the classic 150 goes into this failed state.

[ClassicCrazy]

What version of the firmware is it ?
Did you ever try to see your data on Mymidnite website ?

[TeslasPigeons]

What version of the firmware is it ?
Did you ever try to see your data on Mymidnite website ?

According to the MyMidnite website it is:
FW Revision:   1849
It's a pretty remote property but I can definitely update the firmware next time I'm out there. 

We did originally try to see the data on the MyMidnite website and it's a similar issue, it works for a while then falls offline.  The internet is really bad satellite internet, so the latency is about 1 second. 

[ClassicCrazy]

I think some of the firmware updates may have resolved some of the problems you are having - worth updating to find out anyway.

Larry

[TeslasPigeons]

I think some of the firmware updates may have resolved some of the problems you are having - worth updating to find out anyway.

Larry

OK, I will try that.  My next step is going to be to put a microcontroller controlled relay between the Charger and the panels/battery bank.  That way if the RPi doesn't get a response it can trip the relays and remotely reset it.  I'd rather solve it in software than with something like though.

Yikes, yes looks like my firmware version (1849) is quite a bit older than the current 2054.

[ClassicCrazy]

Guess I am out of date too.  I didn't know about that newest 2054 update - not sure if it was ever announced on the forums . Next time I am out I will update my system too !

Larry

[zoneblue]

1849 should be ok. There are a long standing bug in the ethernet stack, for which a fix is promised, actually about to be released anyday.

I currently have a fairly stable setup using a daemon version of newmodbus, it maintains a single open RTU connection. When and if the classic reboots, the daemon opens a new connection. This arrangement is stable in that it never refuses a connection, however i do get more frequent watchdog reboots. What doesnt presently work for any one for any period is open, read and close. If you do this regularly, the controller network stack will stop responding after anywhere from hours to days. On the other hand people have been using rs232, and havent had issues.

1849 dicusssion here http://midnitesolar.com/Forum/index.php?topic=1814.5
The april alpha for network fixes http://midnitesolar.com/Forum/index.php?topic=2364.0

[TeslasPigeons]

1849 should be ok. There are a long standing bug in the ethernet stack, for which a fix is promised, actually about to be released anyday.

I currently have a fairly stable setup using a daemon version of newmodbus, it maintains a single open RTU connection. When and if the classic reboots, the daemon opens a new connection. This arrangement is stable in that it never refuses a connection, however i do get more frequent watchdog reboots. What doesnt presently work for any one for any period is open, read and close. If you do this regularly, the controller network stack will stop responding after anywhere from hours to days. On the other hand people have been using rs232, and havent had issues.

1849 dicusssion here http://midnitesolar.com/Forum/index.php?topic=1814.5
The april alpha for network fixes http://midnitesolar.com/Forum/index.php?topic=2364.0

My setup is completely RS-232 at this point. I don't even have the ethernet cable plugged into the Classic 150 anymore. I guess there is a remote possibility that someone went into the battery box and knocked my cable loose, but I really liked the firmware answer as that's easy to fix.    I'll check things out on Tuesday and update the firmware.

My RS-232 code is basically:

#!/usr/bin/python

import minimalmodbus

midnite = minimalmodbus.Instrument('/dev/ttyAMA0', 10) # port name, slave addr

# Read Batt Voltage
try:
       print(mindnite.read_register(4114))
except IOError:
       print("Failed to read from midnite")

# Read PV Term V
try:
       print(mindnite.read_register(4115))
except IOError:
       print("Failed to read from midnite")

And so on for each register of interest

[Resthome]

Apparently we are waiting for the new MY Midnite web site to come on line before we see the firmware that is suppose to fix the network issues.

An no there was no announcement of the new firmware but there has been a lot of discussion on 2050 and 2054. They was a bug with 2050 and winXP installs. boB suggested using 2054 which was not on the web site it may be there now.

Looks like 2054'is there now

[dgd]

My setup is completely RS-232 at this point. I don't even have the ethernet cable plugged into the Classic 150 anymore. I guess there is a remote possibility that someone went into the battery box and knocked my cable loose, but I really liked the firmware answer as that's easy to fix.    I'll check things out on Tuesday and update the firmware.

1849 is very stable when reading serial port modbus registers.
I have had one Classic 150, in the #6100 range, with 1849/1839 firmware running a simple webserver on an UNO since March 5th this year. It reads a block of registers once a second from rs232 port and updates a web page.
No ethernet connected to Classic.
Has not failed or reset or hung up in any way.
I could never get my Rpi mod B to run any more than about 3 weeks before something crapped out. It just did not seem stable using ethernet.
If you are trying to do a log file download from the Classic via serial port then the Classic can go dead, there seems to be a known bug when two devices try to access the log file - this may be in the 2054 fix list.

dgd

[TeslasPigeons]

1849 is very stable when reading serial port modbus registers.
I have had one Classic 150, in the #6100 range, with 1849/1839 firmware running a simple webserver on an UNO since March 5th this year. It reads a block of registers once a second from rs232 port and updates a web page.
No ethernet connected to Classic.
Has not failed or reset or hung up in any way.

Yes it is rather puzzling to me.  It seems it's failing in the same way as when I was using ethernet, but it's hard to diagnose without some kind of more specific error than the device simply not responding to my modbus commands. 

I could never get my Rpi mod B to run any more than about 3 weeks before something crapped out. It just did not seem stable using ethernet.

I agree, I know RossW has had success with it, but I went away from it for two reasons: the network there is really bad so I wanted to isolate the system away from it and since I didn't write the newmodbus utility it made it difficult to troubleshoot when it stopped working.  The RPi still runs the rest of the script that is controlling an IP camera and databasing some other data things connected to the network, so it's not the RPi losing connection.

If you are trying to do a log file download from the Classic via serial port then the Classic can go dead, there seems to be a known bug when two devices try to access the log file - this may be in the 2054 fix list.

I am polling the holding registers directly using the modbus protocol through the serial port, however... the way it is failing the same as with ethernet makes me think something else is going on.

[dgd]

So you are not actually sure if the Classic is not responding or the rPi is misbehaving?
The rs232 shield I use has RX and TX LEDs so its easy to see if the Classic is responding. TX when Arduino requests data snd RX when Classic sends data. No RX=dead Classic, no TX=Arduino stuffed.
Since your rPi has a script thats doing other things it could be just the part of the script dealing with serial modbus that is crook. Do you have rx and tx serial port leds?
I have seen some code someone sent me for a modbus serial port reader. It went about a week then stopped.
It turned out to be  memory problem with aan array that just kept growing

dgd

[TeslasPigeons]

So you are not actually sure if the Classic is not responding or the rPi is misbehaving?

I don't believe the rpi is misbehaving.  I can remotely reboot it and the problem still persists.  I have another rpi at my house that runs my weather station and its serial port has never given me any issues.  With that said, I cannot prove it is not the rpi as its at a remote location and all I can do is SSH into the device.  Previously with the ethernet issue, rebooting the rpi did nothing, but rebooting the classic (temporarily) solved the issue... so it seems like the classic is falling into some kind of fault mode.  I just don't understand how the ethernet and modbus issues are related.

It turned out to be  memory problem with aan array that just kept growing

I don't think that's the case here.  I am not saving the data on the rpi. I am creating a text file, using a shell script to read and database the text file and then deleting the text file. Rebooting the rpi would clear out the RAM and I can do that with no resolution. I am using the same method for another script I am running and it is still running successfully. However, the classic is the only thing connected to the UART port of the rpi.

It could be that the rpi goes haywire and sends a signal that violates the modbus protocol and trips the classic 150. So I guess what I am really trying to figure out is how to find out what kind of error state the classic is in.  I couldn't see anything specific in the datasheet.

[dgd]

Its probably the Classic then.
However, I would use an rs232 breakout box with activity leds just to be sure its the Classic not responding.

Or you could just add two leds to the ttl side of the port with resistors. Something like in this circuit:

https://arduinodiy.wordpress.com/2012/03/19/serial-connection-for-your-arduino-atmega/

dgd

[zoneblue]

Another thought is the python modbus module, when i tried is very slow, at least compared to a custom rolled solution. The reason Ross's newmodbus works for him is his sample rate is 5mins. Its only when you go faster than that when issues arise. It also seemed to make a difference how fast the computer was.... timing, memory who knows. My intel atom worked better than the cubie at the same sample rate. Fingers crossed for the next firmware.

Dgd,  still curious to know if you close your serial connection each second, or keep it open.