You could also try just send requests for the real time data only using the 0xA3 command instead
I use cheap 2 usd RS485 ttl modules like this without major issues:
I don’t think I’m certain of anything! LOL! I guess that is a good thing and I consider everything to be a cause of potential errors. The MPPT controller is set to address 1 and the docs confirm that it is acting as a slave so I’m pretty sure that the 0x01 address in the command is correct.
The board you show there is the one that @nikito7 recommends but is not the one I am currently using so I just finished up making a master with that one. Do you happen to know if pin 17 on the ESP32 (TXD) connects to TXD on that RS485 board or does it go to RXD on the RS485? I know that it can be trial and error. My install is on a building 300m away, not on the desk next to me.
I believe it’s tx to tx and Rx to Rx between the esp and rs485 module. I can check tomorrow as my production devices are also located outside my house. But at least not 300m away 
Confirmed.
ESP8266 Rx to RS485 Rx and ESP8266 Tx to RS485 Tx.
Update for today:
Rebuilt the hardware using the auto-flow RS485 but still get no response from the MPPT controller.
I have confirmed with the manufacturer that there is no deep sleep state and the RJ-45 pins I am using are the correct ones.
I am content that the command I’m trying to send to the unit are as correct as they can be.
I have confirmed the unit is set at address 001 and 9600 bps
Next steps:
Until I can get some response from the unit, I’m at a standstill. We are due a decent snowfall over the weekend so I think I’ll pull the controller and put it on the desk here and hook up to it with a PC or RPi and see if I can get it talking.
@htvekov - thank you for the wiring confirmation.
Good idea to verify the rs-485 is working in another config setup.
Perhaps you could wire up two esp8266 with rs485 modules and let them talk with eachother ?
Any rx/tx led indication when connected to the MPPT unit ?
I have only previously had one issue with the cheap rs485 modules. For some strange, unknown reason, only one of the pcb versions I got of the same module actually worked with my Delta Inverter.
I don’t believe that’s the case at your end (especially if tx led lights up when all is connected and you’re issuing a command), but you never know.
Link to my issue: RS485 to TTL - Difference in two visually identical devices
In an effort to move forward, I tried hooking up a Raspberry Pi 4 and using pymodbus but didn’t get anywhere. I also tried using an Arduino Uno but couldn’t figure that out either; I can get it to write commands but not show any feedback from the controller. I ordered a USB to RS485 cable so I can use some Windows tools for debugging but that won’t arrive for a week.
The Arduino foray caused me to think about the communication line and I started thinking that in the YAML code above, I am writing to the uart but not reading from it and if I’m not reading from it, how would it display in the log? A little research on uart reads in Esphome led me to the custome UART Text Sensor. A quick copy/paste and a couple of changes and I am now seeing responses in the log window. Progress at last!
I now need to make sense of the output but I confirmed the output is coming from the controller by changing the A3 control code to A1 (that delivers the full register dump so a much longer hex string than A3) and it does indeed change as expected.
Once I get this figured, I’ll go ahead and make it available for others as you guys have done.
1 Like
I’ve emailed the manufacturer for some help but I’ll share the challenge here too.
The string being returned by an 0xA3 query is 01:A3:01:00:0D:00:02:B2:05:15:00:F6:00:A8:00:00:00:20:00:00:3E
I know the first 3 bytes are address, command type and control code. The last is the checksum. That leaves 17 bytes but in the doc, it states that there will be a 37 bytes response. and I’m only getting 21 bytes unless I am missing something. At first, I thought that maybe I wasn’t reading all the output but the checksum is correct for the 20 bytes returned.
Am I missing something here?
Edit:
I noticed a few mistakes in the doc so I’m not at all confident that it is up-to-date, correct etc. Take the ‘Remarks’ section of byte 6/7 (PV Voltage): “Take 1 decimal place; 0x0C43=1219 means PV voltage is 121.9V”
I have no clue at all how they are deriving 1219 from a hex value of 0x0C43. The rest map out OK using INT16 but there are clearly errors in the doc.
I also don’t seem to be able to make sense of the values in terms of breaking out the bits for bytes 3, 4 and 5 or even figuring out the high and low bytes for the remainder.
1 Like
Take 1decimal places，such as：
0x0C43=1219，means PV voltage is
121.9V
Strange byte swap or docs mistake
1219 = 0x04C3
Edit:
Docs typo.
This is ok:
5372 = 0x14FC
edit2
About binary
So I was doing the right thing in breaking down the hex to binary to get the bit settings. Still didn’t make any sense but last night I think I found out why. This might make you smile…
Support is in China, I’m in MST zone so I don’t get responses until in the evening. They are largely pretty helpful after a rocky start. I send them the command from the master and the response from the controller and point out that it isn’t 37 bytes but 21 bytes. I ask them to match up the response string to their document. Clearly this proves a challenge for the L1 guys.
I get am email that simply asks “Is it OK if we send you the communication protocol in Chinese?”… Well, I guess so…I’ll figure it out. I run it through Google Translate and behold, I get a pretty perfect translation.
The thing is, the command codes in this (second) document state that it is 0xB3 (not 0xA3) for the real time data so I give that a try and get a perfect 37 byte response that makes more sense of the face of it.
I’m currently stuck trying to get an output of the ESP32 log as detailed in this thread. That is proving even more challenging than modbus or Chinese documentation translations.
You can use interval: and uart.write.
Once you have response in log,
adapt the other topic solution:
The main difference, you need active requests.
# Example configuration entry
interval:
- interval: 1min
then:
- switch.toggle: relay_1
It seems that the 0xB3 command code is the correct one and the bytes map directly to the protocol sheet. Now I can take a closer look at the work done by you guys and figure out how to interpret those into HA sensors.
The logging issue I mentioned was due to me being unaware that Esphome had switched tracks back at the start of 2022 and I was still on version 2022.3.1. I’ve updated now and logging is working so I have been able to gather a lot of the modbus responses to get a good picture.
I can see the conversion of negative temperature readings is going to be a challenge. I understand how it works, that the hex needs to be converted to binary and the first digit being one denotes negative but how to implement that in one calculation for positive and negative will be the hurdle I think.
I’m a little more informed than I was earlier but…that’s all relative. 
I’ve been through the solutions posted by @assembly and @htvekov and for the data that is coming in, I understand maybe 75% of what is going on with the processing. I see that the additional *.h file is handling the uart read and breaking out the bytes into individual data that are then sent to the sensor in the .yaml file. I’ve taken a ‘first pass’ at adapting the files created for my own data but my developer skills and knowledge leave much to be desired, especially in a language like C+.
Much like @assembly posted after his “Yahoo!” moment, my data coming from the controller to the ESP32 log file looks like this:
[18:40:01][D][uart_debug:114]: <<< 01:B3:01:00:00:00:02:41:04:C3:00:5D:00:39:00:00:10:20:00:00:00:00:00:22:00:00:05:6C:00:00:00:00:00:00:00:00:18
Mapped out, it looks like this:
Byte 1 > 37
MPPT Address - 1 byte (01)
Command Code - 1 byte (B3)
Control Code - 1 byte (01)
Operating Status - 1 byte (00) [uses 8 bits for status]
Charging Status - 1 byte (00) [uses 8 bits for status]
Control Status - 1 byte (00) [uses 8 bits for status]
PV Voltage - 2 bytes (02 & 41) **
Battery Voltage - 2 bytes (04 & C3) **
Charge Current - 2 bytes (00 & 5D) **
MPPT Temp - 2 bytes (00 & 39) **
Not used - 1 byte (00)
Not used - 1 byte (00)
Battery Temp - 2 bytes (10 & 20) ** !This will be tricky due to negative temps
Not used - 1 byte (00)
Not used - 1 byte (00)
Daily power - 4 bytes (00 & 00 & 00 & 22)
Total Power - 4 bytes (00 & 00 & 05 & 6C)
Not used - 1 byte (00)
Not used - 1 byte (00)
Not used - 1 byte (00)
Not used - 1 byte (00)
Not used - 1 byte (00)
Not used - 1 byte (00)
Not used - 1 byte (00)
Not used - 1 byte (00)
Checksum - 1 byte (18)
There is no timestamp in the data but I assume (read, hope) that I can add that in yaml code later. The ** denote the data that I want to focus on getting into HA first.
The adaptation of @htvekov solivia.h code is as follows:
#include "esphome.h"
class ampinvt : public PollingComponent, public Sensor, public UARTDevice {
public:
ampinvt(UARTComponent *parent) : PollingComponent(400), UARTDevice(parent) {}
// 37 bytes total - 25 bytes used, 12 bytes unused
// Sensor *time_stamp = new Sensor(); // from logging?
// Sensor *operating_status = new Sensor(); // binary (1 byte) - future implementation/low priority
// Sensor *charging_status = new Sensor(); // binary (1 byte) - future implementation/low priority
// Sensor *control_status = new Sensor(); // binary (1 byte) - future implementation/low priority
Sensor *pv_voltage = new Sensor(); // 2 byte
Sensor *battery_voltage = new Sensor(); // 2 byte
Sensor *charge_current = new Sensor(); // 2 byte
Sensor *mppt_temperature = new Sensor(); // 2 byte
Sensor *battery_temperature = new Sensor(); //2 byte
// Sensor *today_yield = new Sensor(); //4 byte - future implementation/low priority
// Sensor *generation_total = new Sensor(); //4 byte - future implementation/low priority
void setup() override {
}
std::vector<int> bytes;
int count = 15;
//void loop() override {
void update() {
while(available() > 0) {
bytes.push_back(read());
//make sure at least 8 header bytes are available for check
if(bytes.size() < 8)
{
continue;
}
if(bytes[0] != 0x01 || bytes[1] != 0xB3 || bytes[2] != 0x01) {
bytes.erase(bytes.begin()); //remove first byte from buffer
//buffer will never get above 8 until the response is a match
continue;
}
if (bytes.size() == 37) {
// OneByte operating_status;
// operating_status.Byte[0] = bytes[0x4B +6]; // Operating Status (binary)
// OneByte command_code;
// command_code.Byte[0] = bytes[0x4B +6]; // Command Code (binary)
// OneByte control_status;
// control_status.Byte[0] = bytes[0x4B +6]; // Control Status (binary)
TwoByte pv_voltage;
pv_voltage.Byte[0] = bytes[0x4B +6]; // PV Voltage high byte
pv_voltage.Byte[1] = bytes[0x4A +6]; // PV Voltage low byte
TwoByte battery_voltage;
battery_voltage.Byte[0] = bytes[0x4D +6]; // Battery Voltage high byte
battery_voltage.Byte[1] = bytes[0x4C +6]; // Battery Voltage high byte
TwoByte charge_current;
charge_currrent.Byte[0] = bytes[0x4F +6]; // Charge Current high byte
charge_current.Byte[1] = bytes[0x4E +6]; // Charge Current low byte
TwoByte mptt_temperature;
mptt_temperature.Byte[0] = bytes[0x5D + 6]; // MPPT Controller Temp high byte (Temp should always be positive)
mptt_temperature.Byte[1] = bytes[0x5C + 6]; // MPPT Controller Temp low byte
TwoByte battery_temperature;
battery_temperature.Byte[0] = bytes[0x5F + 6]; // Battery Temp high byte (Temp could be positive or negative)
battery_temperature.Byte[1] = bytes[0x5E + 6]; // Battery Temp low byte
// FourByte today_yeild;
// today_yeild.Byte[0] = bytes[0x61 + 6]; // Daily Power Generation Yield
// today_yeild.Byte[1] = bytes[0x60 + 6]; // Daily Power Generation Yield
// today_yeild.Byte[2] = bytes[0x60 + 6]; // Daily Power Generation Yield
// today_yeild.Byte[3] = bytes[0x60 + 6]; // Daily Power Generation Yield
// FourByte generation_total;
// generation_total.Byte[0] = bytes[0x63 +6]; // Total Power Generation Yield
// generation_total.Byte[1] = bytes[0x62 +6]; // Total Power Generation Yield
// generation_total.Byte[2] = bytes[0x62 +6]; // Total Power Generation Yield
// generation_total.Byte[3] = bytes[0x62 +6]; // Total Power Generation Yield
// TwoByte d_yield_data;
// d_yield_data.Byte[0] = bytes[0xB5 +6]; // Daily yield lsb
// d_yield_data.Byte[1] = bytes[0xB4 +6]; // Daily yield msb
// uint32_t t_yield_data = int(
// (unsigned char)(bytes[0x86 +6]) << 24 |
// (unsigned char)(bytes[0x87 +6]) << 16 |
// (unsigned char)(bytes[0x88 +6]) << 8 |
// (unsigned char)(bytes[0x89 +6])); // Total yield (4 bytes float)
// char etx;
// etx = bytes[37]; // ETX byte (last byte)
// Quick and dirty check for package integrity is done, in order to avoid irratic sensor value updates
// This effectively blocks out any erroneous sensor updates due to rx package corruption
// Check if ETX = 3. If not (invalid package), ditch whole package, clear buffer and continue
// if (etx != 0x03) {
// ESP_LOGI("custom", "ETX check failure - NO sensor update! ETX: %i", etx);
// bytes.clear();
// continue;
// }
// operating_status->publish_state(operating_status.UInt16);
// charging_status->publish_state(charging_status.UInt16);
// control_status->publish_state(control_status.UInt16);
pv_voltage->publish_state(pv_voltage.UInt16);
battery_voltage->publish_state(battery_voltage.UInt16);
charge_current->publish_state(charge_current.UInt16);
mptt_temperature->publish_state(mptt_temperature.UInt16);
battery_temperature->publish_state(battery_temperature.UInt16);
// today_yeild->publish_state(today_yeild.UInt16);
// generation_total->publish_state(generation_total.Int16);
// ESP_LOGI("custom", "ETX check OK: %i - ESPHome sensors updated", etx);
bytes.clear();
}
else {
}
}
}
typedef union
{
unsigned char Byte[2];
int16_t Int16;
uint16_t UInt16;
unsigned char UChar;
char Char;
}TwoByte;};
I have commented out the stuff that isn’t vital for a first stage implementation and I can circle back to that later when I understand more about what is going on. The code coming in from the Solivia is in a different format to the code that I have coming back; rather than individual registers, I have a string dump of hex values so I’m not sure how to adapt the byte locations used in the original file but I utilised the approach from @assembly as that made more sense.
And that leaves the 25% of code there that I don’t understand. If you guys could look it over and make suggestions, I’d be deeply grateful. Thanks so much for your help so far.
Looks good so far!
However the registers don’t seem to match.
For example:
0x4A + 6 would be 80, which can’t be because you have only 37 bytes to begin with.
The bytes for battery voltage are probably:
battery_voltage.Byte[0] = Bytes[4]
battery_voltage.Byte[1] = Bytes[3]
The link to your protocol is no longer working so I’m just guessing.
Ah yes, I actually figured that out from your C+ file. I didn’t understand how the byte references from Henning worked but I did understand that you were referencing byte positions.
Strange that the link is no longer working. Reposted again here:
Original modbus comms file with incorrect 0xA3 command code
Second modbus comms file translated from Chinese with correct 0xB3 command code
Ok so battery voltage should be:
battery_voltage.Byte[0] = Bytes[9]
battery_voltage.Byte[1] = Bytes[8]
And so on.
Personally I think it’s a bit easier to understand in decimal than in hex. But it’s the same thing.
Dammit! I was hoping to figure this out but I’m all out of ideas.
The files validate OK but when I try to install, I get some errors. I’ve eliminated most of them but these last ones (or last one as they are all the same, repeated) are beyond me. Here is my ampinvt.h file:
#include "esphome.h"
class ampinvtcomponent : public PollingComponent, public Sensor, public UARTDevice {
public:
ampinvtcomponent(UARTComponent *parent) : PollingComponent(600), UARTDevice(parent) {}
//37 bytes total - 25 bytes used, 12 bytes unused
Sensor *pv_voltage = new Sensor(); // 2 byte
Sensor *battery_voltage = new Sensor(); // 2 byte
Sensor *charge_current = new Sensor(); // 2 byte
Sensor *mppt_temperature = new Sensor(); // 2 byte
Sensor *battery_temperature = new Sensor(); // 2 byte
void setup() override {
}
std::vector<int> bytes;
void update() {
while(available() > 0) {
bytes.push_back(read());
if(bytes.size() < 37){
continue;
}
else {
}
if(bytes.size() == 37) {
TwoByte pv_voltage;
pv_voltage_value.Byte[0] = bytes[6]; // PV Voltage high byte
pv_voltage_value.Byte[1] = bytes[7]; // PV Voltage low byte
pv_voltage->publish_state(pv_voltage_value.UInt16);
TwoByte battery_voltage;
battery_voltage_value.Byte[0] = bytes[8]; // Battery Voltage high byte
battery_voltage_value.Byte[1] = bytes[9]; // Battery Voltage low byte
id(battery_voltage).publish_state(battery_voltage_value.UInt16);
TwoByte charge_current;
charge_currrent_value.Byte[0] = bytes[10]; // Charge Current high byte
charge_current_value.Byte[1] = bytes[11]; // Charge Current low byte
id(charge_current).publish_state(charge_current_value.UInt16);
TwoByte mptt_temperature;
mptt_temperature_value.Byte[0] = bytes[12]; // MPPT Controller Temp high byte (Temp should always be positive)
mptt_temperature_value.Byte[1] = bytes[13]; // MPPT Controller Temp low byte
id(mptt_temperature).publish_state(mptt_temperature_value.UInt16);
TwoByte battery_temperature;
battery_temperature_value.Byte[0] = bytes[16]; // Battery Temp high byte (Temp could be positive or negative)
battery_temperature_value.Byte[1] = bytes[17]; // Battery Temp low byte
id(battery_temperature).publish_state(battery_temperature_value.UInt16);
bytes.clear();
}
else {
}
}
}
typedef union
{
unsigned char Byte[2];
int16_t Int16;
uint16_t UInt16;
unsigned char UChar;
char Char;
}TwoByte;};
And here are the errors when I try to install:
In file included from src/main.cpp:46:0:
src/ampinvt.h: In member function 'virtual void ampinvtcomponent::update()':
src/ampinvt.h:31:9: error: 'pv_voltage_value' was not declared in this scope
pv_voltage_value.Byte[0] = bytes[6]; // PV Voltage high byte
^
src/ampinvt.h:33:19: error: base operand of '->' has non-pointer type 'ampinvtcomponent::TwoByte'
pv_voltage->publish_state(pv_voltage_value.UInt16);
^
src/ampinvt.h:36:9: error: 'battery_voltage_value' was not declared in this scope
battery_voltage_value.Byte[0] = bytes[8]; // Battery Voltage high byte
^
src/ampinvt.h:38:29: error: 'union ampinvtcomponent::TwoByte' has no member named 'publish_state'
id(battery_voltage).publish_state(battery_voltage_value.UInt16);
^
src/ampinvt.h:41:9: error: 'charge_currrent_value' was not declared in this scope
charge_currrent_value.Byte[0] = bytes[10]; // Charge Current high byte
^
src/ampinvt.h:42:9: error: 'charge_current_value' was not declared in this scope
charge_current_value.Byte[1] = bytes[11]; // Charge Current low byte
^
src/ampinvt.h:43:28: error: 'union ampinvtcomponent::TwoByte' has no member named 'publish_state'
id(charge_current).publish_state(charge_current_value.UInt16);
^
src/ampinvt.h:46:9: error: 'mptt_temperature_value' was not declared in this scope
mptt_temperature_value.Byte[0] = bytes[12]; // MPPT Controller Temp high byte (Temp should always be positive)
^
src/ampinvt.h:48:30: error: 'union ampinvtcomponent::TwoByte' has no member named 'publish_state'
id(mptt_temperature).publish_state(mptt_temperature_value.UInt16);
^
src/ampinvt.h:51:9: error: 'battery_temperature_value' was not declared in this scope
battery_temperature_value.Byte[0] = bytes[16]; // Battery Temp high byte (Temp could be positive or negative)
^
src/ampinvt.h:53:33: error: 'union ampinvtcomponent::TwoByte' has no member named 'publish_state'
id(battery_temperature).publish_state(battery_temperature_value.UInt16);
^
*** [/data/esp32-solar-monitor/.pioenvs/esp32-solar-monitor/src/main.cpp.o] Error 1
========================== [FAILED] Took 4.36 seconds ==========================
Both the .h files I’m referencing use a slightly different syntax so I have deliberately used the version from Henning in the first item (pv_voltage) and the version from @assembly for the rest, just to see if one worked where others did not.
I suspect that I an in the realm of inheritance issues but have no idea how to fix it. Any ideas?
Edit:
Ignore the typo in ‘charge_currrent’, I fixed that since posting.
Edit #2:
Nothing like making a post on a forum 2 minutes before realising that you have multiple typos in your code and some missing _value entries. Just one more to solve I think.
Yeah. Was just about to type when your edit2 came in. That’s definitely your problem. Either add “value” to all variables or leave it away for all variables.
I just added the “value” to distinguish them from the actual esphome sensor declarations, but there shouldn’t be any conflict even if you name them the same.
Also for pv voltage replace “->” with “.”
Great, you got it working 
Well, The response from my Solivia inverter is somewhat different than yours.
First I check for a 6 bytes response match (header), as my inverters response starts with the query command response, in total 6 bytes, followed by the actual data including CRC (255 bytes) + ETX (1 byte) = 262 bytes in total.
Your inverter just returns data without any prefixes or trailing data.
So you should alter the uart buffer check for correct amount of bytes from 262 to 37 in the line:
if (bytes.size() == 262)
In my case the actual inverter data byte starts at byte 0x06h, hence my code adding 6 to all the indexes. Simply to make it more readable. You should delete this completely and reference directly to the index byte number from your list, as your inverter data start at byte 0x00h
1 Like
Well, I’m to slow it seems 
Didn’t read the entire thread to the end before answering.
One note though.
I have a semi ‘CRC check’ on the prefixed 6 bytes + my ETX at fixed positions.
This ensures, to some extend, that data is actually valid and not just some random bytes used to update all the sensor values.
You have to rely on only three prefixed bytes and no ETX at a fixed byte position. So if you experience issues with the uart data quality (random spikes on the sensors) it might be worth the hazzle to actually implement the correct CRC check on the last byte. If not a match, scratch all bytes before you update the sensors.