No values reported

[jonesPD]

Hi Niels,
I'm trying to masquerade my ESMR5 smart meter as a Import/Export meter. SetApp shows a working connection ('OK') but no values are indicated, and I can't read them back through the TCP_MODBUS interface as well (which I also use to read out the production).

My implementation is as follows: I receive an MQTT message from the smart meter (actually via Beeclear), this is parsed by a Node-Red flow to an MQTT message (the flow was largely already there):

{"Vmains":233,"Imains":2.1,"Pin":404.7,"Pin_min":401,"Pin_max":411,"Pout":0,"Pout_min":0,"Pout_max":0,"Ein":0.0011298999,"Eout":0,"sumEin":4785344,"sumEout":3958941,"Po":404.7,"En":0.0011298999,"timestamp":"1614979040701"}

Some of these values are used in the return DICT from the 'values' call. I don't get any errors running the scripts.
All this is running on a Raspberry with an RS485 connection to the SolarEdge inverter.

What I am doing wrong?

jonesPD_metering_proxy_0305.zip

[jonesPD]

dump_all_modbus_registers_export+import2.txt

Wondering if there is an Endian issue, since the serial number shows up wrong. Conf file is at default setting 987654, reading back via Modbus shows 18176...

[nmakel]

Looks like I had a typo in the configuration examples. serial_numer instead of serial_number. Fix that and see if the serial number shows up correctly.

I will have a longer look at your code tomorrow. My first thought is that the number of values you provide might be less than what is required. Have you tried matching the number of fields to that of the sdm120 example? Even filling them with dummy data can give you an idea of whether the entire pipeline is working or not...

[jonesPD]

Hi Niels, Thanks for your reply. And thanks for offering to have a look at the code, that’s really great. I’ve corrected the typo, but no difference. In fact, for some reason the serial number now reports as 0 (zero). I’ve also added (realistic dummy) numbers for the field I hadn’t used yet (following your sdm120 example), but also this doesn’t seem to make a difference. I’ll tinker around with other values to see if that makes a difference. Do the values provided in the DICT need to be a specific type? (float/int/…) Do the values provided in the DICT need to comply to a specific sign convention? I use negative numbers for power when it is delivered to the grid, positive when drawing from it. How is ‘demand power’ defined? Related question in a different direction, when configuring in SetApp I didn’t know what to set the CT to, so I just left it with the proposed default (5 I believe). Do I need to use that number anywhere? Thanks for your help.

[nmakel]

I’ve corrected the typo, but no difference. In fact, for some reason the serial number now reports as 0 (zero). I’ve also added (realistic dummy) numbers for the field I hadn’t used yet (following your sdm120 example), but also this doesn’t seem to make a difference.

That's weird.

Can you set your config to log_level = DEBUG? Here are the setValues that happen in my situation:

block_1601:

[1234, 0, 5, 5, 5, 5, 0, 0, 0, 15, 1, 10000, 10000, 10000, 64536, 64536, 64536, 1500, 120, 0, 0, 20000, 0]

block_1651:

[0, 2, 4, 0, 0, 5]

block_1701:

[4614, 15, 0, 0, 0, 0, 0, 25, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

block_1001:

[27441, 17880, 22036, 17761, 27441, 17880, 22036, 17761, 62259, 50059, 62259, 50059, 0, 0, 0, 0, 58982, 17260, 58982, 17260, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 52429, 16967]

block_1101:

[27441, 17880, 0, 0, 0, 0, 22036, 17761, 0, 0, 0, 0, 32846, 17743, 32846, 17743, 32846, 17743, 0, 0, 0, 0, 24946, 17941, 24946, 17941, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 13705, 48852, 13705, 48852, 0, 0, 0, 0, 42598, 50201, 42598, 50201, 0, 0, 0, 0, 56372, 17448, 56372, 17448, 0, 0, 0, 0, 12059, 16453, 0, 0, 0, 0, 26152, 17480, 0, 0, 13366, 17745, 0, 0, 26152, 17480, 0, 0, 0, 0]

I’ll tinker around with other values to see if that makes a difference. Do the values provided in the DICT need to be a specific type? (float/int/…) Do the values provided in the DICT need to comply to a specific sign convention? I use negative numbers for power when it is delivered to the grid, positive when drawing from it. How is ‘demand power’ defined?

A working example is worth a thousand words, here are my meter values this morning with +-280W being fed back into the grid:

{
    'voltage': 236.89999389648438,
    'current': 3.0810000896453857,
    'power_active': -279.8999938964844,
    'power_apparent': 675.440673828125,
    'power_reactive': -614.5999755859375,
    'power_factor': -0.41447094082832336,
    'phase_angle': 0.0,
    'frequency': 49.95000076293945,
    'import_energy_active': 3605.3798828125,
    'export_energy_active': 3320.01904296875,
    'import_energy_reactive': 0.09000000357627869,
    'export_energy_reactive': 9560.271484375,
    'total_demand_power_active': 801.59619140625,
    'maximum_total_demand_power_active': 3347.26318359375,
    'import_demand_power_active': 122.04130554199219,
    'maximum_import_demand_power_active': 3347.26318359375,
    'export_demand_power_active': 679.5548706054688,
    'maximum_export_demand_power_active': 2310.420654296875,
    'total_demand_current': 4.683725833892822,
    'maximum_total_demand_current': 14.968546867370605,
    'total_energy_active': 6925.39892578125,
    'total_energy_reactive': 9560.361328125,
    'energy_active': 6925.39892578125,
    'import_energy_active': 3605.3798828125,
    'power_active': -279.8999938964844,
    'p1_power_active': -279.8999938964844,
    'voltage_ln': 236.89999389648438,
    'p1n_voltage': 236.89999389648438,
    'frequency': 49.95000076293945,
    'p1_energy_active': 6925.39892578125,
    'p1_import_energy_active': 3605.3798828125,
    'export_energy_active': 3320.01904296875,
    'p1_export_energy_active': 3320.01904296875,
    'energy_reactive': 9560.361328125,
    'p1_energy_reactive': 9560.361328125,
    'power_factor': -0.41447094082832336,
    'p1_power_factor': -0.41447094082832336,
    'power_reactive': -614.5999755859375,
    'p1_power_reactive': -614.5999755859375,
    'power_apparent': 675.440673828125,
    'p1_power_apparent': 675.440673828125,
    'p1_current': 3.0810000896453857,
    'demand_power_active': 801.59619140625,
    'maximum_demand_power_active': 3347.26318359375,
    'p1_demand_power_active': 801.59619140625
}

Related question in a different direction, when configuring in SetApp I didn’t know what to set the CT to, so I just left it with the proposed default (5 I believe). Do I need to use that number anywhere?

The current transformer (CT) value has no discernible impact as far as I'm aware. I have mine set to 50A (in SetApp), in case some sort of output limiting happens based on this value.

If you suspect an endianness issue, you can play around with the byteorder and wordorder parameters on line 161, 186 and 195 of your semp-rtu.py file.

[jonesPD]

Thanks for responding. Using the meter data you provided, I’ve checked the block setValues and they match up. Attached is zip are two log files. One using your meterdata (non-changing message), and one using my own livedata. Also there are a few setapp screenshots, all showing an ‘ok’ connection to the meter, but with varying serial number (for some reason, I didn’t play with it). Hope you have suggestion where else to look. Thanks for your time.

[nmakel]

Attached is zip are two log files.

I think you forgot the attachment.

[jonesPD]

Mmmm…my outlook shows they’ve been included. Let’s just try again. Did you get the pictures?

[nmakel]

Mmmm…my outlook shows they’ve been included. Let’s just try again. Did you get the pictures?

No. Be aware these replies are being posted to github, including your actual e-mail address.

[jonesPD]

Indeed. Removed that.
Did you get the zip file? The images are just to show setapp indicates the connection to meter is ok although no values are being shown (na)

[nmakel]

Did you get the zip file?

The first zip file, yeah. After that, nothing.

[jonesPD]

jonesPD_metering_proxy_0306-2.zip

[nmakel]

Can you provide a bit more details about your installation? What inverter do you have, are there any other devices connected to the RS485 ports? Is the meter configured as described in the readme?

Looking at your log -- in which you provide the values I gave you -- the inverter looks to be doing its thing. Requesting values, and the responses look right.

[jonesPD]

I have a SolarEdge SE5000H inverter (no display), the 'meter' is the only thing connected to the RS485 bus. I've toggled the RS485-1 switch inside the inverter, and also added the termination resistor on the RS485Pi board mounted on top of the RPi 3. I've followed your configuration instructions for the inverter. The connection only seems to work at 9600baud.
Attached is the output of the '--json' switch of your solaredge_modbus script - obtained over TCP/IP.
dump_all_modbus_registers3.txt

As you can see in that file, serial-number is not listed, nor is any measurement. On the otherhand, in the two SetApp screen shots, the meter-version and serial number are shown correctly.

[nmakel]

As you can see in that file, serial-number is not listed, nor is any measurement. On the otherhand, in the two SetApp screen shots, the meter-version and serial number are shown correctly.

This actually looks pretty good. The meter is registering properly. Were the screenshots taken when you were supplying values through mqtt, or the dict I gave you?

I had similar issues with the Modbus TCP output -- I suspect the serial number, among other values, are not updated real time. Ignore that, and focus on getting values to show up in the SetApp interface. NA energy makes me suspect invalid or empty variables in your values dict.

[jonesPD]

It was when supplying live data through MQTT. Unfortunately switching back to your dict does not make it show them. It should show up more or less instantaneously I suppose?
I spend most of saturday evening replacing the RS485 cable, to ensure it is how it should be (CAT5e cable now), but alas, that didn't make any difference. I've also cut out all of my own code, making a special metertype that always returns your dict. After a night long sending your dict, SetApp still reports NA.
jonesPD_metering_proxy_0307.zip

Which pymodbus version are you on? Which inverter CPU version are you on?
Other suggestions?

[nmakel]

Looking more closely at one of your previous debug logs the one odd thing is that the inverter keeps trying to write to register 1608. I don't see this in my logging. The exact formatting also differs, might be a version difference, or the result of differences between the pymodbus RTU and TCP handling.

I am using pymodbus 2.4.0 and python 3.7.3. The inverter is on version 4.10.25.

Can you provide screenshots of the SetApp /#/commissioning/communication/rs485-1 and /#/commissioning/communication/rs485-1/meter-1 pages?

[jonesPD]

I'm also on python 3.7.3. I initially was at pymodbus 2.5, but have downgraded (with local copy of library) to 2.3. The zip contains logs for both pymodbus 2.3 and 2.4 (for completeness sake). The first entry in the log shows which pymodbus was used (using pymodbus.version.version). Both logs are created sending out your dict (meter2 = setdata = your dict).
The zip also contains the screen shots you asked for. Sometimes the serial number, meter version number, or CT value are not updated (correctly). Sometimes the CT number is also reset to 0 (zero), despite the entry in the semp-rtu.conf file.
jonesPD_metering_proxy_0307-2.zip

I find one hit on ['SolarEdge MODBUS registers 1608'] (https://www.onetemp.com.au/Attachment/DownloadFile?downloadId=1399). Which shows this register sets the averaging of the meter. Setting one means fast (default) average over 5 seconds periods and a measurement update every 1 second. Might the inverter be expecting this update rate?

[nmakel]

Thanks for the screenshots. All of that looks fine. There shouldn't be a difference between SolarEdge or Wattnode as Meter Protocol, but I have mine set to Wattnode.

Get rid of serial_number and ct_current in your configuration. Defaults should be fine.

Have you ever tried connecting to the inverter over Modbus? Not Modbus TCP, but by setting RS485-1 to Non Sunspec Logger? If that works it should rule out any hardware or cabling issues. Doing this will also force you to set the inverter Modbus ID to 1, which might also be an issue at the moment.

The registers can be found in the Wattnode documentation.

[jonesPD]

It is no problem to read out the Modbus inverter values via RS485.
modbusRTU.txt
So no connection issue, adding the meter back (WattNode) does not make a difference, still set at NA.
Is there a simple way to downgrade the inverter firmware?

[nmakel]

It is no problem to read out the Modbus inverter values via RS485.

Ok, so that's not something to worry about.

Is there a simple way to downgrade the inverter firmware?

No :)

There must be a reason the inverter is sending write holding register messages. Perhaps it isn't happy with the defaults provided in the block_1601 section. Try updating the line 170:

block_1601.add_16bit_int(1) # measurement averaging

Edit: I can elicit similar write messages by setting the default measurement averaging to 1. However, this doesn't stop the meter from working.

It is clear that the inverter isn't getting beyond the identification stage, because you're only seeing requests for the 1601 and 1701 register blocks. When I look at my verbose output I see multiple requests for the 1011 register block every second, and regular requests for 1001. So either the inverter is unhappy about what it is receiving, or it isn't receiving the messages at all.

[jonesPD]

That makes sense, but doesn't fix the issue yet. Log file attached. I'll go through some of the other registers and the Wattnode documentation to see if I can find another something
semp-rtu_1608=1.txt
.

[nmakel]

That makes sense, but doesn't fix the issue yet. Log file attached. I'll go through some of the other registers and the Wattnode documentation to see if I can find another something
semp-rtu_1608=1.txt
.

The response now shows register 1608 as 1, but the inverter is still sending messages to set it to 0. This most likely means the inverter is not parsing the messages correctly, or simply not receiving them. Is it reliably showing the correct serial number at this point? Did you modify any endianness settings?

[jonesPD]

It is showing the serial number (and version number) properly when I set Meter Protocol to SolarEdge, but it is flaky. FOr example when CT, serial and version don't show, I can re-add the Meter and the CT number shows up properly (from the semp-rtu.conf file), version and serial sometimes come along, sometimes not properly. Best chance is to start a fresh according to your instructions (first SunSpec (Non-SE Logger), than add Meter).

I haven't modified the endianness (so it remains at byteorder=Endian.Big, wordorder=Endian.Little - the wordorder I confirmed in the Wattnode documentation). I think you're right, the inverter keeps repeating the 1601, 1701 requests as if something is misconfigured. I've checked the Wattnode manual a couple of times, there are a number of registers that could be configured differently, but this doesn't make a difference:

• 1601: power scale to 1 (rather than auto at 0)
• 1601: phase angle correction to 0 (rather than -1000)
• 1601: phase offset to 0 (for a single phase system) rather than 120 (the default)
• 1651: parity to even (add parity='E' to StartSerialServer)
• 1701: uptime and total uptime larger than 0 (I even experimented with an increasing uptime)
• 1701: wattnode model 202
• 1701: wattnode options 2 when parity enabled

What I noticed though, also when the 1608 is configured as 1, it sends a request to modify the register:
2021-03-07 19:59:11 DEBUG: [1234, 0, 50, 50, 50, 50, 0, 1, 1, 15, 1, 10000, 10000, 10000, 0, 0, 0, 1500, 0, 0, 0, 20000, 0]
2021-03-07 19:59:11 DEBUG: setValues[3] 1601:23
2021-03-07 19:59:13 DEBUG: Getting Frame - 0x3 0x6 0x40 0x0 0x17
2021-03-07 19:59:13 DEBUG: Factory Request[ReadHoldingRegistersRequest: 3]
2021-03-07 19:59:13 DEBUG: Frame advanced, resetting header!!
2021-03-07 19:59:13 DEBUG: validate: fc-[3] address-1601: count-23
2021-03-07 19:59:13 DEBUG: getValues fc-[3] address-1601: count-23
2021-03-07 19:59:13 DEBUG: send: [ReadRegisterResponse (23)]- b'02032e04d200000032003200320032000000010001000f000127102710271000000000000005dc0000000000004e20000065b8'

--> after a while <--

2021-03-07 19:59:15 DEBUG: Getting Frame - 0x6 0x6 0x47 0x0 0x0
2021-03-07 19:59:15 DEBUG: Factory Request[WriteSingleRegisterRequest: 6]
2021-03-07 19:59:15 DEBUG: Frame advanced, resetting header!!
2021-03-07 19:59:15 DEBUG: validate: fc-[6] address-1608: count-1
2021-03-07 19:59:15 DEBUG: setValues[6] 1608:1
2021-03-07 19:59:15 DEBUG: getValues fc-[6] address-1608: count-1
2021-03-07 19:59:15 DEBUG: send: [WriteRegisterResponse 1607 => 0]- b'0206064700003964'

--> is it writing to the correct register here? it now says 1607, where 1608 was requested?

--> subsequent requests for the whole of 1601
2021-03-07 19:59:16 DEBUG: Getting Frame - 0x3 0x6 0x40 0x0 0x17
2021-03-07 19:59:16 DEBUG: Factory Request[ReadHoldingRegistersRequest: 3]
2021-03-07 19:59:16 DEBUG: Frame advanced, resetting header!!
2021-03-07 19:59:16 INFO: return set data set from NMakel
2021-03-07 19:59:16 DEBUG: validate: fc-[3] address-1601: count-23
2021-03-07 19:59:16 DEBUG: getValues fc-[3] address-1601: count-23
2021-03-07 19:59:16 DEBUG: send: [ReadRegisterResponse (23)]- b'02032e04d200000032003200320032000000000001000f000127102710271000000000000005dc0000000000004e200000f478'
--> now the particular bit seems to be set to 0! (where it was requesting it to be set to 1!

--> likewise i also have a log file that starts with 1608 set to 0, receiving a write request to set it 1, but the actual bit is not changed.

Is it true that the pymodbus server is supposed to handling these type of read/write actions itself?

Do you think it makes a difference if I try RS485-2 input?

[nmakel]

It is showing the serial number (and version number) properly when I set Meter Protocol to SolarEdge, but it is flaky. FOr example when CT, serial and version don't show, I can re-add the Meter and the CT number shows up properly (from the semp-rtu.conf file), version and serial sometimes come along, sometimes not properly. Best chance is to start a fresh according to your instructions (first SunSpec (Non-SE Logger), than add Meter).

I appreciate all your efforts. So far it has been a bit of a struggle getting things to work for everyone, but in the end we get there nonetheless. When trying to get semp-rtu to work with another person we saw similar debug output to yours, but the only difference was that they were also seeing requests for block_1651. You seem to stop short, only getting requests for block_1601 and block_1701. In your case it may just be as simple as letting the inverter restart and start its Modbus processes fresh with the current settings and meter configuration in place.

What I noticed though, also when the 1608 is configured as 1, it sends a request to modify the register:

Be careful when reading the debug output and translating register addresses. The actual request specifies 0x647, 1607 in decimal, which is the offset. Register 1608 is the location of the corresponding logical address. You'll notice the request for register 1601+23 bytes specifies 0x640, 1600 in decimal, in the message.

--> likewise i also have a log file that starts with 1608 set to 0, receiving a write request to set it 1, but the actual bit is not changed.

That's odd if true, but check your logs. The write request, for example 0x6 0x6 0x47 0x0 0x0 means write holding register (0x6), at offset 0x647, with value 0x0. Set 1608 to 0, in other words. If it wants a 1 there you would expect 0x6 0x6 0x47 0x0 0x1.

Is it true that the pymodbus server is supposed to handling these type of read/write actions itself?

I tried to find this in the documentation but couldn't. I'm assuming it does.

Do you think it makes a difference if I try RS485-2 input?

Stranger things have worked in the past.

[nmakel]

Stranger things have worked in the past.

You have probably been trying this, but I've modified the list of block_1601 and block_1701 defaults. Might as well give it a try:

block_1601, modified passcode, measurement averaging to factory defaults.

                block_1601 = BinaryPayloadBuilder(byteorder=Endian.Big, wordorder=Endian.Little)
                block_1601.add_32bit_int(0) # config passcode
                block_1601.add_16bit_int(confparser[meter].getint("ct_current", fallback=default_config["meters"]["ct_current"])) # ct rated current
                block_1601.add_16bit_int(confparser[meter].getint("ct_current", fallback=default_config["meters"]["ct_current"])) # ct rated current l1
                block_1601.add_16bit_int(confparser[meter].getint("ct_current", fallback=default_config["meters"]["ct_current"])) # ct rated current l2
                block_1601.add_16bit_int(confparser[meter].getint("ct_current", fallback=default_config["meters"]["ct_current"])) # ct rated current l3
                block_1601.add_16bit_int(confparser[meter].getint("ct_inverted", fallback=default_config["meters"]["ct_inverted"])) # ct direction inversion
                block_1601.add_16bit_int(1) # measurement averaging
                block_1601.add_16bit_int(0) # power scale
                block_1601.add_16bit_int(15) # demand period
                block_1601.add_16bit_int(1) # demand subintervals
                block_1601.add_16bit_int(10000) # power/energy adjustment l1
                block_1601.add_16bit_int(10000) # power/energy adjustment l2
                block_1601.add_16bit_int(10000) # power/energy adjustment l3
                block_1601.add_16bit_int(-1000) # ct phase angle adjustment l1
                block_1601.add_16bit_int(-1000) # ct phase angle adjustment l2
                block_1601.add_16bit_int(-1000) # ct phase angle adjustment l3
                block_1601.add_16bit_int(1500) # minimum power reading
                block_1601.add_16bit_int(confparser[meter].getint("phase_offset", fallback=default_config["meters"]["phase_offset"])) # phase offset
                block_1601.add_16bit_int(0) # reset energy
                block_1601.add_16bit_int(0) # reset demand
                block_1601.add_16bit_int(20000) # current scale
                block_1601.add_16bit_int(0) # io pin mode
                slave_ctx.setValues(3, 1600, block_1601.to_registers())

block_1701, modified the model to 203.

                block_1701 = BinaryPayloadBuilder(byteorder=Endian.Big, wordorder=Endian.Little)
                block_1701.add_32bit_int(confparser[meter].getint("serial_number", fallback=default_config["meters"]["serial_number"])) # serial number
                block_1701.add_32bit_int(0) # uptime (s)
                block_1701.add_32bit_int(0) # total uptime (s)
                block_1701.add_16bit_int(203) # wattnode model
                block_1701.add_16bit_int(25) # firmware version
                block_1701.add_16bit_int(0) # wattnode options
                block_1701.add_16bit_int(0) # error status
                block_1701.add_16bit_int(0) # power fail count
                block_1701.add_16bit_int(0) # crc error count
                block_1701.add_16bit_int(0) # frame error count
                block_1701.add_16bit_int(0) # packet error count
                block_1701.add_16bit_int(0) # overrun count
                block_1701.add_16bit_int(0) # error status 1
                block_1701.add_16bit_int(0) # error status 2
                block_1701.add_16bit_int(0) # error status 3
                block_1701.add_16bit_int(0) # error status 4
                block_1701.add_16bit_int(0) # error status 5
                block_1701.add_16bit_int(0) # error status 6
                block_1701.add_16bit_int(0) # error status 7
                block_1701.add_16bit_int(0) # error status 8
                slave_ctx.setValues(3, 1700, block_1701.to_registers())

[jonesPD]

That didn't help either unfortunately.
I tried switching to RS485-2 this morning no difference. At first I forgot to toggle the terminator switch, so I had to re-open and restart the inverter again. Before the Meter1 data via the modbus read out actually showed the correct serial number (987654), after restart to set the terminator switch properly, it shows the incorrect serial (18176). I mention this, because the modbus read out via TCP had never shown the correct serial number before.
But alas, none of the above mods, or your suggested ones make the inverter request 1001 or 1100 blocks.

I'm considering to try another RS485 device, for when sending to the inverter, probably you can also set up a loop with that. Any suggestions?

[nmakel]

I tried switching to RS485-2 this morning no difference. At first I forgot to toggle the terminator switch, so I had to re-open and restart the inverter again. Before the Meter1 data via the modbus read out actually showed the correct serial number (987654), after restart to set the terminator switch properly, it shows the incorrect serial (18176).

Are you saying that with the terminator set to OFF the correct serial number is displayed?

[jonesPD]

yes indeed, the modbus register is still not properly updated after several hours and a restart of semp-rtu script (in SetApp and the ModBus TCP report out) - i can try later today to turn the terminator back off and see if it returns to the correct setting.

[jonesPD]

It seems to random, turning the termination off, I get the same wrong serial number, even after adding the meter back once again. I've ordered a different RS485 converter, USB this time, let's pick this up in a few days time.

[jonesPD]

Tested the connection again using the SolarEdge_modbus script at 9600 baud to retrieve inverter status information (rather than over TCP). This has now been running for several hours without hickups. So connection and hardware seems fine.
Also received the alternate RS485 USB dongle, and tested it. Both RS485 devices yield the same result though, where the inverter keeps sending 1601/1701 read requests, but no read from the meter registeres. So this in my mind confirms your earlier statement that there seems to be something amiss with the information the inverter receives from the virtual meter, and suggests some changes have been made in de inverter 4.11.30 firmware.
Since I have two RS485 devices now, we could have them talking to one another. Does that help in assessing the problem? The Wattnode manual links to some tools they have on their website. Do you have experience with any of these or a suggestion what to try next?
Attached a long log file using the USB RS485 device while i'm configuring the inverter as per instruction. The XLS version is nice to find spurious messages that might be irregular (in your experience).

semp-ttyUSB1.txt
semp-ttyUSB1.xlsx

[jonesPD]

Again confirmed over the past days that the hardware seems fine. I have the two RS485 devices talk to each other, where one is using the meterProxy and the other is requesting meter registers (a nodeRED flow with dashboard).
I've also found some 'real' Wattnode serial numbers, in case there some smartness in the number.
Would you be willing to share a DEBUG log file showing the messages that show normal behavior? Thx

[nmakel]

Sure, see the attached debug output.

debug_output.txt

Your semp-ttyUSB1.txt shows quite a range of register addresses that are being polled. The data source you're using is not returning any values, however.