Easun (and others) 6048 charger smart interface

[profesor79]

Hello,
I am in the process to add monitoring to easun mptt 6048 charger. As I have a few of them running my 550 panels (two panels connected to one charger due to location and shading) x6, then I was thinkig that it can be possible to hook an esp32 to the board an intercept the communication.
I think there is 9600 baud transmission between the panel (that stores all the user settings) and the board.

Did someone had a simiar idea or experience in this area?
Do you think it is worth it? (i think there is many simiar devices that are lack of monitoring).

 

[Crowz]

Haven't seen anything posted for that one but people are always wanting was to monitor what they have and the lesser supported via monitoring options the more people need it. Good luck with it!

 

[profesor79]

Today I was able to connect two serial readers to the device and sniff the transmission.
when device is not charging the data is sent in a kind of easy packet, but when charging then there is a lot of traffic.

 

[profesor79]

message decoding in progress.
found PV voltage, battery voltage, temp and chariging current.

now need to decode this in the ESP so the sensor will send a nice data to mqtt for home assistant (or others)

 

[profesor79]

Sniffer in the test phase
below is code that is used to read particular communication datagram.
SoftwareSerial chasisTx(5, 0); // RX, TX // no need for soft serial but I needed hardware serial for sniffing int tmout = 2; int speed = 9600; const int BUFFER_SIZE = 24; char buf[BUFFER_SIZE]; void setup() { Serial.begin(115200); chasisTx.begin(speed); } char bufbyte[60]; int bufferCountr = 0; float current; float batV; float PvV; int temp; void CopyBuffer(int rlen) { memcpy(bufbyte + bufferCountr, buf, sizeof(buf)); bufferCountr += rlen; if (bufferCountr >= 20) { bufferCountr = 0; if (bufbyte[0] == 125 && bufbyte[1] == 16) { current = float(bufbyte[12] * 256 + bufbyte[13]) / 10; batV = float(bufbyte[8] * 256 + bufbyte[9]) / 10; PvV = float(bufbyte[10] * 256 + bufbyte[11]) / 10; temp = bufbyte[14]; mqtt_client.publish((mqtt_base_topic + "/current").c_str(), (String(current)).c_str()); mqtt_client.publish((mqtt_base_topic + "/batV").c_str(), (String(batV)).c_str()); mqtt_client.publish((mqtt_base_topic + "/PvV").c_str(), (String(PvV)).c_str()); mqtt_client.publish((mqtt_base_topic + "/temp").c_str(), (String(temp)).c_str()); } } } void loop() { if (chasisTx.available()) { int rlen = chasisTx.readBytes(buf, BUFFER_SIZE); CopyBuffer(rlen); } }

 

[profesor79]

it looks like we have a coms issue here, and unfortunately after ESP reset no more data is comming.
back to data sniffing but this time with an extended port cortrol.

 

[profesor79]

I'm thinking that the ESP is not able to go over EMI noise that is generated by equipment. Added rs232 and I'm hoping that I will get a cat5 cable connected tonight.
Also will check if the ESP will be able to send data at night.

 

[profesor79]

Esp is sending data nat normal rate, when the chargers are on standby.
Connected rs232 to Arduino and got an interesting output, when some data is having different size that on ESP (just wondering if it is connected with CPU speed, or other factor)
As I'm not the best at programming micro controllers, I will try to cover that with a string magic transform...

 

[profesor79]

so the ESP which is directly attached to the charger controller is giving shitttttty data...
But the other controller when we use RS232 with an arduino nano is going great.
So now I need to do my RS232 aggregator (on the Arduino MEGA platform as it can have at least 8 software serial interfaces defined), and then will use ESP to push data over WiFi to mqtt server.
A bit complicated but still worth the effort in my case.

 

[jv16bar]

What about using something like a Raspberry Pi Zero? What causes the ESP reading wrong data?
What are the logic levels on the communication port?

 

[profesor79]

What about using something like a Raspberry Pi Zero? What causes the ESP reading wrong data?
What are the logic levels on the communication port?

• com port is 3.3 V
• ESP is 32bit and arduino is 8bit, so that could be a reason for decoding the data in a different way (see the spread sheet above in red)
• you can use PI 0 directly as it is a 3.3V device
• In my case Wifi connection is droping on my mobile phone due to EMI

Now when I am decoding using Arduino (8bit) then all data is fine - espcially that I have 6 devices and plannig to run 2 more, then soultion with RS232 on each device and an agregator is more robust, as having 8 ESP with wifi will allow me to lost somedata during the peak time.

 

[profesor79]

form other side it could by lack of understanding some communication aspects and not validating control field :D

 

[jv16bar]

I also set up a test environment with the following equipment: Easun 6048 MPPT, a weak 12V gel battery, 24V power source (as PV), and a Nodemcu connected with 2 wires to the display panel: ground + Chassis TX. I'm using your code, slightly modified it to send values on serial port instead of MQTT.
I'm getting the following results:


What is strange, when i turn on the PSU (aka solar panel), there is a 30-40 sec gap in the data flow. See the above, i have a data set at 34 sec, then i turn on the PSU and the next data set is at 69 sec. After that the data comes at around 5-8 sec interval.
At what interval are you getting data with the Arduino?

 

[profesor79]

Congrats on the results!
Honestly I did not spot this behavour.
What is my problem is that when the charge starts, the timing is a bit off. As we can see on the attached screenshot, rs232 is timing-out, and starts listen again, so instead of one line of data, we receive multimple chunks<millis, who, data>.
So tha gap that you can observe could be the odd-timing as those two microcontrollers begin to be busy during charge process.

edit: attached raw file from sniffing process

 

[profesor79]

Data flow is around 1 set of messages per second.

 

[jv16bar]

Question: do we need to listen to the LCD? Isn't it enough to connect just to the Chassis_TX? All the data we need (vbat, vPV, current) is coming from the charger.

 

[profesor79]

no need for LCD as it is not providing values, but I was not avare how the coms goes on, so decided to listen to both.

 

[jv16bar]

Are you using softwareserial on Arduino Nano too? I'm thinking to try to use ESP's hardware serial port maybe Softwareserial is causing the issues and it works better on HW TTL.
My experience is the same as yours: as the charging process is started (and i guess the EMI noise appears) ESP is not reading reliable data anymore from the chassis.

 

[profesor79]

I will be using 8 software serial ports on NANO, tests are done, now assembling hardware( that will take some time..)
But you can try my workaround that is converting readed byte to hex and then truncate it to last 2 chars.

full solution here:

easun6040reader/readerWip.ino at main · profesor79/easun6040reader

a hardware and software hack to read easn 6048 data - profesor79/easun6040reader

github.com

 

[jv16bar]

So, i tried to use ESP hw serial port (GPIO3 as RX) and it works much better than SW serial. I'm getting valid data almost every second. In my test setup max charging current is around 6A and in this interval (0A - 6A or 0W - 70W) the readings are ok. I will test it later in real world scenario where i have 48V battery and 1600W solar panel.
I see there is a 3.3V on the LCD, do you know if it is enough to power the ESP?