Temp/Load Power/Load Current wrong

[Stalkk]

Hi,
thank you for the great work.

but you have small issue with Temp/Load Power/Load Current. Please take a look on jaminNZx/Tracer-RS485-Modbus-Blynk#2 to fix it.

[njordan77]

has this issue been fixed, or what do i need to do in order to fix it myself.....

Remove??? result = node.readInputRegisters(0x3100, 7);
and insert??? result = node.readInputRegisters(0x3100, 0x12);

[PhantomSage]

Yes, 0x12 will do the trick,
Works for ctemp/Load Power & Load current.

[njordan77]

OK. Thanks i did this already and it works... :-)
result = node.readInputRegisters(0x3100, 0x12);

BUT - maybe you can help me out - I naively believed that it could be simple to read registers based on the official tech doc, but i failed and i have no clue why....some ascii signs but useless...

Any help is highly appreciated as i sit for weeks now and all it tried failed the same way....

Generated energy today L --- 330C
Generated energy today H --- 330D

result = node.readHoldingRegisters(0x3300, 14);
  if (result == node.ku8MBSuccess)
  {
    pvenergytday = ((long)node.getResponseBuffer(0x0D) << 16 | node.getResponseBuffer(0x0C)) / 100.0f;
    dtostrf(pvenergytday, 2, 3, buf );
    client.publish("/EPsolar/PVenergytday", buf);
  } else {
    rs485DataReceived = false;
  }

[PhantomSage]

Those are on my todo list for my hacking, just haven't tested them yet.
You are sure that you read the correct topic? you have a / at the beginning above, and that is not the same path as the other topics.

[beercity]

Is anyone else getting some clipping of the MQTT strings after implementing this? I am seeing two characters at the beginning of the ctemp and lpower MQTT strings. I have been able to adapt but I am not sure why its happening. Before I implemented this fix I was not experiencing this clipping. I need to set up some more debugging to get a better handle on this.

[bearli97]

I replaced the result-line with result = node.readInputRegisters(0x3100, 0x12); and my lpower/lcurrent are correct, but btemp is showing 0, even though the display of the EPever is showing the correct temperature.
Any idea?

[beercity]

Can you share your entire code?

…

On Mon, Dec 21, 2020 at 4:09 PM bearli97 ***@***.***> wrote: I replaced the result-line with result = node.readInputRegisters(0x3100, 0x12); and my lpower/lcurrent are correct, but btemp is showing 0, even though the display of the EPever is showing the correct temperature. Any idea? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCPVX37MSDEWQJA4OQWYMTSV62R5ANCNFSM4F76EJYQ> .

[bearli97]

void AddressRegistry_311A() {
  //result = node.readInputRegisters(0x311A, 2);    // original
  result = node.readInputRegisters(0x311A, 0x12);    // new
  if (result == node.ku8MBSuccess)
  {
    bremaining = node.getResponseBuffer(0x00) / 1.0f;
    dtostrf(bremaining, 2, 3, buf );
    client.publish("EPSolar/1/bremaining", buf);
    
    btemp = node.getResponseBuffer(0x01) / 100.0f;
    dtostrf(btemp, 2, 3, buf );
    client.publish("EPSolar/1/btemp", buf);
    
  } else {
    rs485DataReceived = false;
  }
}

(0x311A, 2) returns 0
(0x311A, 0x12) returns nothing

But I was wondering, according to this PDF, battery temperature should be on address 3110. I tried just writing a new function AddressRegistry_3110() with result = node.readInputRegisters(0x311A, 0x12);, but that doesnt return anything neither.

[martgras]

I created a component for esphome some time ago and define the address ranges in python
https://github.com/martgras/esphome/blob/7a52216db878df0b4437207d3c243ee6d99f3346/esphome/components/epsolar/sensor.py#L191

Try 0x3110, 1

0x311A is the remote battery temp. (don't ask me what is the difference is 🤔).
Both show the same value on my controller

[bearli97]

0x3110, 1 and 0x3100, 0x10 (as in your Python file) returns 0. And yes, I have a temp sensor and the display shows BATT. 20°C :)

Device is a Tracer 1206AN.

[martgras]

I was replying from the smartphone yesterday so it was probably a bit brief

    cv.Optional(CONF_BATTERY_TEMPERATURE):
        modbus_sensor_schema('read_input_registers', 0x3100, 0x10, ALLBITS,
                             'S_SINGLE', 0.01, UNIT_CELSIUS, ICON_THERMOMETER, 1),

The format means 'read_input_registers': use function modbus function code 0x4 . 0x3100 is the base address and 0x10 is the offset from the base address so effectively the address for this register is 0x3110. S_SINGLE means it is a signed 16 bit value so it translates to node.readInputRegisters(0x3110, 0x1) . Well actually I use the equivalent of node.readInputRegisters(0x3100, 0x12) to read all registers from 0x3100 – 0x3111 ;

If you use node.readInputRegisters(0x3100, 0x10) you are missing the battery temperature register. node.readInputRegisters(0x3100, 0x11) would have it in getResponseBuffer(0x10)

node.readInputRegisters(0x311A, 0x12) fails because there are only 2 registers in that range (maybe 4 there is a gap between 0x311B and 0x311D)
So node.readInputRegisters(0x311A, 0x2) should return values.

When I developed my esphome component I had debug code to dump out the raw bytes over serial to find problems in my processing code . Something like

node.readInputRegisters(0x3100, 0x12);
auto p = (uint16_t*)&node.getResponseBuffer(0x00);
for (int i = 0 ; i < 0x12; i++) {
	Serial.printf("p[i] = %d (0x%x) \n",p[i],p[i]);
}

If you have an esp32 you can also try my esphome version. I started with the code from this repo but then found that writing an esphome component saves me from creating the code to handle wifi, mqtt, OTA etc.
It sends the battery temperature as a mqtt message like: solarstation/sensor/battery_temperature/state 10.3
https://github.com/martgras/esphome/tree/epever/esphome/components/epsolar has the instructions for running it .
Can be useful to compare if other software also return 0 for the temperature.

esphome in general (not my fork that just adds epever support) is a pretty impressive piece of work. I'm using it for a couple of other sensor nodes here and they work flawless for over a year now.