I’m working on reading data from a Sol-Ark inverter over the modbus connection. Things are going pretty smoothly, but I’ve hit a snag where a single 32bit value is spread over two registers that are not sequential.
Here’s a snippet of the PDF describing the registers:
The U_DWORD_R instructs the modbus sensor to properly read “unsigned 32 bit integer from 2 registers low word first” which is how I read the docs.
However, “Total Grid Buy Power” is the problem. It’s another UINT32, but it’s on register 78 and 80 – register 79 is Grid Frequency.
How can I get this oddly split value into ESPHome and back to HA?
There are configs for pulling values from odd offsets, or for modbus implementations that store values in odd manners (like offsets, etc). Nothing I found in the docs, however, deals with values which are stored in non-sequential registers and cobbling it back together.
I imagine there’s a lambda that could be done which reads from 78 through 80 and then combines the values back to the single 32bit int, but that’s kinda beyond my skill level at the moment; aside from seeing the potential in doing that.
It’s so idiotic that I doubt esphome has option to read that. The good point is that you have time to practice with lambdas until you reach 6553.5 kWh on reg 78.
Modbus controller component has example to unite two registers with lamda code, for 32bit float though.
Very much feels like at one point they only supported up to that six thousand’ish kwh and someone came along and said “that’s too small, we use a bunch!” and so they had to make it 32bit, but people were already using 78, so they just “extended it” somewhere else. Backwards compatible!
I used an online compiler and some ai code helpers to cobble together this C++ code to demonstrate what I suspect I should see:
#include <iostream>
#include <iomanip>
#include <cstdint>
#include <vector>
int main()
{
// dummy object to emulate the item and data objects I would expect
class Itemer {
public:
int offset;
};
Itemer* item = new Itemer;
item->offset = 0;
// The value, bajillions of kwh:
// 2294967294 => hex 88CA6BFE
// register 78 (low word) would be 0x6B 0xFE
// register 80 (high word) would be 0x88 0xCA
// so the data should be:
//
// data[item->offset + 0] = 0x6B;
// data[item->offset + 1] = 0xFE;
// data[item->offset + 2] = N/A; // ignore, is the grid frequency
// data[item->offset + 3] = N/A; // ignore, is the grid frequency
// data[item->offset + 4] = 0x88;
// data[item->offset + 5] = 0xCa;
std::vector<unsigned char> data = { 0x6B, 0xFE, 0xAA, 0xBB, 0x88, 0xCA };
// to get that back into a regular uint32_t, we bitmath the values as such:
// high word in 4/5, ignore 2/3, low in 0/1
uint32_t result = data[item->offset + 4] << 24
| data[item->offset + 5] << 16
| data[item->offset + 0] << 8
| data[item->offset + 1];
std::cout << "back together: " << result << std::endl;
return 0;
}
I took a spare esp32 and created a dummy modbus server which has this absurd “int split over non-contiguous registers” issue – this code does the trick when reading it back:
That whole union thing…did not do what I had expected it to do, nor what the modbus examples implied it would do. Returning an int, despite the docs saying you have to return a float, works just fine. One must suspect the docs are…perhaps not totally accurate.
I’ll stick with this method so that, from the esp device, the data is accurate.
(Granted, I originally started with a really big number, and converting that to a float, which then got rounded in fun “Computers Suck at Floating Point Math” ways was a super cool rabbit hole to fall in…I’ll just leave that for future me problem when I hit the absolutely absurd KWH numbers.)
Yep, 32bit float conversion is much more complicated.
To put together low-word and high-word UINT is simple, basically you have two counters from 0-65535. When low-word counter arrives to max, it adds 1 to high-word counter and roll over to 0.
