Questions about the RS485 cable

[wrybread]

How are you connecting to the Tracer controller? Are you using the cable from Epsolar such as this:

https://www.amazon.com/ENZPOWER-Battery-Temperature-Monitoring-Controller/dp/B01INK1AOS/

Or making your own? If making your own, what hardware did you use?

I've been trying to connect to my Tracer 4210a to my Pi using a modbus cable I built using this:

https://www.amazon.com/gp/product/B00NKAJGZM

It works beautifully until the sun comes up high, and then my Pi won't connect to the Tracer for hours at a time, usually until the sun goes down again. Obviously sounds like some sort of interference issue, but I haven't been able to isolate it. I built the cable using Cat7 ethernet cable, not sure what else to try. The issue happens even with my inverter turned off.

I don't imagine you have any suggestions?

And I'd love to try your project once I know more about the interface cable.

[andres-leon]

Yes. I'm using the JBtek USB to RS485 Converter Adapter to connect the controller to the Pi. I made the cable from Cat6 and works pretty well. I know that the controller will sometimes stop sending data or the Pi just won't be able to connect. However I notice that connection is established well again after the Pi is rebooted. So my crude solution is the reboot the pi every 4 hours by a cron task.

Are you monitoring the temperate of the Pi? if the sun's up and the Pi is not protected from the heat then it will overheat and eventually hang. That's why I cool it with fans that trigger when the CPU tem reaches a threshhold of about 135f.

Also, if the temperature increases the cable connections may be coming lose. Have you checked that the cables are well attached to the adapter?

Lastly, I also bought the MPPT remote meter (https://www.amazon.com/gp/product/B00YAB0UVO/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1). This helps you configure the controller to use the correct type of batteries and their rated amp/hours. I would suggest you get this and connect it to the controller to see if it stops functioning when the sun is up. If so, then you may have gotten a bad controller.

Good luck!

[wrybread]

Strange, I'm using the same JBtek adaptor, tried 2 of them, same issue with both. Tried multiple ethernet cables with different ratings from Cat5 to Cat7. Rebooting the Pi doesn't help when I lose the connection unfortunately.

Cables are soldered directly to the unit so certainly tight. No heat issues since everything is indoors, and there's no difference between day and nighttime temperatures.

I have a system rigged up where after my 4 Trojan T-105 batteries are fully charged by my 600 watts of panels, my Pi trips a relay that powers a refrigerator. It works beautifully until the Tracer stops responding. So frustrating that it's still happening.

Interestingly, even when the Tracer stops responding to my Pi, it works just fine if I plug in the MT50 monitor box. Instantly, and always. No idea why the difference.

I just ordered the wifi box from Epever with hopes of being able to scrape it's HTML pages:

https://www.youtube.com/watch?v=uFURiLmQds0

If you or anyone has any other ideas, I'd love to hear them.

[wrybread]

I tried wrapping the communication cable in tin foil for extra shielding, but no improvement. Here's my iPhone app showing this morning's sun rise. The output gets up to 520 watts:

And then the usual dropoff as the sun gets high enough and the charge controller stops responding.

So frustrating. I've emailed Epever support about it, but I've never heard a peep back from them.

The strange part is that the MT50 remote monitor box never ever loses communication. I can't think of what the difference could be.

[danieloneill]

I'm a bit curious..

Two questions, first is are you able to see any errors on your dmesg output when this happens?

Second question, when you reboot the pi, are you also powering down your rs485 adapter chip itself?

What I'm getting at, is if it's just the serial adapter not resetting after it gets "stuck", or if it's indeed the controller itself.

Moreover, you say that via the mt50 it works fine? That's telling a lot, really. At the very least it's doing something your software or cable should be doing.

I'll add that it seems unlikely to me that it's interference, since rs485 is designed for long range serial.

Actually if it's not thermally caused it seems more likely a software issue. I'm also curious is swapping to the mt50, then back to the pi, when this happens, "wakes it up" or if the pi stays unresponsive. It could simply be values under those conditions that the software isn't able to parse, which could under some circumstances stop all readings altogether. For example, trying to read a register, failing, and trying it until it succeeds, ad infinitum, until the state of data is back within expected parameters and only then can it continue reading as expected.

On Jul 31, 2017 12:06 AM, "wrybread" notifications@github.com wrote:

I tried wrapping the communication cable in tin foil for extra shielding, but no improvement. Here's my iPhone app showing this morning's sun rise. The output gets up to 520 watts:

[image: img_3693] https://user-images.githubusercontent.com/10524548/28764630-55e0fd88-757b-11e7-95ef-6f8bbb115383.PNG

And then the usual dropoff as the sun gets high enough and the charge controller stops responding.

[image: img_3697] https://user-images.githubusercontent.com/10524548/28764677-95497356-757b-11e7-93dd-e3ecdb3ba2ba.PNG

I've emailed Epever support about it, but I've never heard a peep back from them.

The strange part is that the MT50 remote monitor box never ever loses communication. I can't think of what the difference could be.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/danieloneill/EpsolarServer/issues/1#issuecomment-318976505, or mute the thread https://github.com/notifications/unsubscribe-auth/AKDVjVBKCF91TLstvA6O_AjF7g_PLl3jks5sTW7ugaJpZM4Om-pf .

[wrybread]

Thanks for your response.

No errors in dmesg, my script simply fails to connect. A stripped down version of my script is:

!/usr/bin/python

from pymodbus.client.sync import ModbusSerialClient as ModbusClient

client = ModbusClient(method = 'rtu', port = '/dev/ttyUSB0', baudrate = 115200)
client.connect()

result = client.read_input_registers(0x3100,6,unit=1)
solarVoltage = float(result.registers[0] / 100.0)
solarCurrent = float(result.registers[1] / 100.0)
batteryVoltage = float(result.registers[4] / 100.0)
chargeCurrent = float(result.registers[5] / 100.0)

print solarVoltage
print solarCurrent
print batteryVoltage
print chargeCurrent

client.close()

In the above, client is None when the controller is unresponsive.

Interesting about powering down the rs485 adaptor. I just tried that too, and no improvement.

Moreover, you say that via the mt50 it works fine? That's telling a lot, really. At the very least it's doing something your software or cable should be doing.

Agreed, but I can't think of what. And it sounds like your script is having the same problem? You mentioned having to reboot? The MT50 doesn't have to do that, for example.

I'm also curious is swapping to the mt50, then back to the pi, when this happens, "wakes it up"

Alas no.

Today it just became unresponsive again, and interestingly the battery SOC was, like yesterday, up above 90%. I'm wondering if it's something about that condition that's making it unresponsive. In the manual for the charge controller describing the registers:

http://www.solar-elektro.cz/data/dokumenty/1733_modbus_protocol.pdf

There's a section on reading the "charging equipment status". I haven't been able to figure out how to read that register, have you? I'm wondering if it's becoming unresponsive when it goes into float.

Also, does anyone know if there might be firmware updates available? I've contacted Epever about it, but have never heard back. Who knows, maybe I'll get lucky and a firmware update will fix it.

[danieloneill]

I don't use a script, my program is written in c++ and communicates via libmodbus.

In my case, the driver itself (in the kernel) crashes, and produces a big block of junk I don't understand in my dmesg output, which is what I wondered might be happening in your case.

I haven't played with that python library much, as I'm not very skilled with python, but it could certainly be a bug in the library.

It appears that you're attempting to read 6 registers from a starting address. Have you considered or tried reading them one at a time?

On Jul 31, 2017 2:20 PM, "wrybread" notifications@github.com wrote:

Thanks for your response.

No errors in dmesg, but my script can no longer connect. A stripped down version of my script is:

!/usr/bin/python

from pymodbus.client.sync import ModbusSerialClient as ModbusClient

client = ModbusClient(method = 'rtu', port = '/dev/ttyUSB0', baudrate = 115200) client.connect()

result = client.read_input_registers(0x3100,6,unit=1) solarVoltage = float(result.registers[0] / 100.0) solarCurrent = float(result.registers[1] / 100.0) batteryVoltage = float(result.registers[4] / 100.0) chargeCurrent = float(result.registers[5] / 100.0)

print solarVoltage print solarCurrent print batteryVoltage print chargeCurrent

client.close()

Interesting about powering down the rs485 adaptor. I just tried that too, and no improvement.

Moreover, you say that via the mt50 it works fine? That's telling a lot, really. At the very least it's doing something your software or cable should be doing.

Agreed, but I can't think of what. And it sounds like your script is having the same problem? You mentioned having to reboot? The MT50 doesn't have to do that, for example.

I'm also curious is swapping to the mt50, then back to the pi, when this happens, "wakes it up"

Alas no.

Today it just became unresponsive again, and interestingly the battery SOC was, like yesterday, up above 90%. I'm wondering if it's something about that condition that's making it unresponsive. In the manual for the charge controller describing the registers:

http://www.solar-elektro.cz/data/dokumenty/1733_modbus_protocol.pdf

There's a section on reading the "charging equipment status". I haven't been able to figure out how to read that, have you? I'm wondering if it's becoming unresponsive when it goes into float.

Also, does anyone know if there might be firmware updates available? I've contacted Epever about it, but have never heard back.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/danieloneill/EpsolarServer/issues/1#issuecomment-319184775, or mute the thread https://github.com/notifications/unsubscribe-auth/AKDVje5Xd4TM4aJ0FbgSeKvtRo9-hGF4ks5sTjcegaJpZM4Om-pf .

[wrybread]

Yup, have read one at a time as well. Also tried inserting long pauses between reads.

I should mention I also tried communicating via Arduino in C, and same result (controller won't accept connections once the sun is high).

[danieloneill]

You have me thinking about it a lot now!

I don't even know a lot about rs485 but I do know it uses a floating variable voltage. Is your pi powered or grounded with the controller?

On Jul 31, 2017 2:42 PM, "wrybread" notifications@github.com wrote:

Yup, have read one at a time as well. Also tried inserting long pauses between reads.

I should mention I also tried communicating via Arduino in C, and same result (controller won't accept connections).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/danieloneill/EpsolarServer/issues/1#issuecomment-319190326, or mute the thread https://github.com/notifications/unsubscribe-auth/AKDVjefsNr_bjzImoTvw5s_Lretf71qPks5sTjw1gaJpZM4Om-pf .

[wrybread]

Is your pi powered or grounded with the controller?

Wow, I just grounded the cable to the Pi and it's working perfectly now. I literally can't thank you enough. I've been working on this on and off for a good two months.

For anyone else who comes this way: connect the ground pin (pin 7 or 8) from your cable shown here:

https://youtu.be/r3LrWeYYtnQ?t=3m11s

To one of the ground GPIO pins on your Pi.

Phew.

[danieloneill]

Awesome, glad to hear it! Nice fix too.

[wrybread]

Well it's much better than before, but I'm still getting occasional disconnections. Interestingly, if I connect the MT50 box for even a moment, everything works great again.

I don't imagine you have a theory as to why that would be?

I wonder if I should try grounding the other ground wire to another ground pin on the Pi?

Or can you think of anything else to try?

[geekmystique]

Hi @wrybread Did you ever figure out what the issue was with the broken communication?

I have a ESP module setup with a 485 connector, and also face full breakdown in communication with the Tracer. When it works it works great, but it just stops and then sometimes comes back 8 hours later. Also I can confirm that every time I connect my MT50 all is fine so it does not appear to be a hardware issue.

I tried switching ESP pins and stopped powering the module from the Epever directly, but it makes no difference. I am pretty convinced it is a software issue; possibly somehow "locking" the Tracer in some way. If I ever figure it out I will post here.

[danieloneill]

ESP32 or 8266?

This could be a grounding (earthing) issue. If both sides don't share ground, there's no reference voltage for 0.

It should be easy to fix by ensuring both the client and server share a ground, or close to.

In my case, a caravan, I had to use DC- on both sides as ground, but on a terran installation it shouldn't be too picky so long as the delta between high and low on your 422 line is at least 3v. This depends a lot on your transciever, but if you're doing it on an ESP by bit banging you could bodge it.

With respect to this program, though, libmodbus itself works independently from the driver so it can't handle floating voltage variance with any authority.

I'll leave this topic open even though it seems unrelated to the project, simply because it's people doing it themselves and there's no better place to discuss and fix things!

If grounding doesn't help, please post more info with regard to what you've checked, what's helped, and what hasn't.

Cheers!

On Sun., Mar. 21, 2021, 11:20 p.m. geekmystique, @.***> wrote:

Hi @wrybread https://github.com/wrybread Did you ever figure out what the issue was with the broken communication?

I have a ESP module setup with a 485 connector, and also face full breakdown in communication with the Tracer. When it works it works great, but it just stops and then sometimes comes back 8 hours later. Also I can confirm that every time I connect my MT50 all is fine so it does not appear to be a hardware issue.

I tried switching ESP pins and stopped powering the module from the Epever directly, but it makes no difference. I am pretty convinced it is a software issue; possibly somehow "locking" the Tracer in some way. If I ever figure it out I will post here.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/danieloneill/EpsolarServer/issues/1#issuecomment-803794190, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQNLDNJALOR32GWLKESIN3TE3ORHANCNFSM4DU35JPQ .

[danieloneill]

Sorry, where I say RS422 I mean it interchangeably with RS485. The issues between them aren't the same, but the problems typically are!

On Mon., Mar. 22, 2021, 7:51 p.m. Daniel O'Neill, < @.***> wrote:

ESP32 or 8266?

This could be a grounding (earthing) issue. If both sides don't share ground, there's no reference voltage for 0.

It should be easy to fix by ensuring both the client and server share a ground, or close to.

In my case, a caravan, I had to use DC- on both sides as ground, but on a terran installation it shouldn't be too picky so long as the delta between high and low on your 422 line is at least 3v. This depends a lot on your transciever, but if you're doing it on an ESP by bit banging you could bodge it.

With respect to this program, though, libmodbus itself works independently from the driver so it can't handle floating voltage variance with any authority.

I'll leave this topic open even though it seems unrelated to the project, simply because it's people doing it themselves and there's no better place to discuss and fix things!

If grounding doesn't help, please post more info with regard to what you've checked, what's helped, and what hasn't.

Cheers!

On Sun., Mar. 21, 2021, 11:20 p.m. geekmystique, @.***> wrote:

Hi @wrybread https://github.com/wrybread Did you ever figure out what the issue was with the broken communication?

I have a ESP module setup with a 485 connector, and also face full breakdown in communication with the Tracer. When it works it works great, but it just stops and then sometimes comes back 8 hours later. Also I can confirm that every time I connect my MT50 all is fine so it does not appear to be a hardware issue.

I tried switching ESP pins and stopped powering the module from the Epever directly, but it makes no difference. I am pretty convinced it is a software issue; possibly somehow "locking" the Tracer in some way. If I ever figure it out I will post here.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/danieloneill/EpsolarServer/issues/1#issuecomment-803794190, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQNLDNJALOR32GWLKESIN3TE3ORHANCNFSM4DU35JPQ .

[wrybread]

Sorry I wish I had more info, but a Morningstar MPPT60 fell in my lap, so I switched over to that. I may be helping a friend install a tracer and he wants to monitor data, so maybe I'll have new info in a bit.

[danieloneill]

No worries!

Does it have any support for monitoring in an EPSolar way by chance?

On Mon., Mar. 22, 2021, 8:09 p.m. wrybread, @.***> wrote:

Sorry I wish I had more info, but a Morningstar MPPT60 fell in my lap, so I switched over to that. I may be helping a friend install a tracer and he wants to monitor data, so maybe I'll have new info in a bit.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/danieloneill/EpsolarServer/issues/1#issuecomment-804548959, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQNLDNA7CZCGPPTKNO4KLLTFABAHANCNFSM4DU35JPQ .