Epever Tracer 4215BN charge controller status fault bit is on

[bobself]

I'm logging data from the controller's rs485 interface to see how it works. It seems to be doing the right stuff but there is one thing that doesn't make sense.
According to the documentation this is the definition of the status bits:

D15-D14: Input volt status. 00 normal, 01 no
power connected, 02H Higher volt input, 03H
Input volt error.
D13: Charging MOSFET is short.
D12: Charging or Anti-reverse MOSFET is short.
D11: Anti-reverse MOSFET is short.
D10: Input is over current.
D9: The load is Over current.
D8: The load is short.
D7: Load MOSFET is short.
D4: PV Input is short.
D3-2: Charging status. 00 No charging,01 Float,02
Boost,03 Equlization.
D1: 0 Normal, 1 Fault.
D0: 1 Running, 0 Standby.

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

Before the sun comes up the value is 0000000000000001 (running).
When the PV voltage gets to about 15 volts it reads 0000000000001011 (running, boost, and fault bit)
Later in the day (after boost) the value is 0000000000000111 (running, charging, fault)
Then it goes back to 0000000000000001 at night.

My question is why is the fault bit on when there is sunlight? Does anyone else have this controller and can see these bits?
The MT50 shows the controller status as normal. Maybe the documentation above is wrong?

 

[z92ioSQUPqLd]

I see the same thing on my system. Did you ever figure it out?

 

[cv8r]

Old thread but I found the same issue for anyone else stumbling on this fault bit.

 

[v_green57]

Learned from other weird EPEVER symptoms:

Even if you are not using it, you need to manually set LOAD to ON. If LOAD is OFF, you cannot access the 485 registers at night. That crap drove me crazy when first learning about the TRACER.

Try switching states on LOAD and see if things are different.

And you can try setting the various "Local Load Modes" (see manual) to different values and see what that does. "117" is what the default is.

Personally, I think it's just another incomplete/poorly executed RS-485 implementation. I see them all the time. The important ones on EPEVER stuff are all OK, I just ignore the ones that don't make sense or spout inappropriate values.