No success with StorEdge SE7K-RWS48BNN4 and SDM630MCT-RC + 3pcsESCT-RC100 about solaredge_meterproxy HOT 26 OPEN

Did some more testing. No success but found something that seems a bit odd to me, but might have some explanation.
The issue seems a bit like the other issue #8
Found some logs from both @jonesPD and @nmakel.
I only receive getValues for 1601 and my responses does not look like the ones from @nmakel that has a working example.
Logs from me:

2021-04-29 14:34:20 DEBUG: getValues fc-[3] address-1601: count-23
2021-04-29 14:34:20 DEBUG: send: [ReadRegisterResponse (23)]- b'02032e000000000005000500050005000000010000000f0001271027102710fc18fc18fc1805dc0078000000004e2000000a36'

Log from @nmakel :

2021-03-28 15:31:50 DEBUG: getValues fc-[3] address-1601: count-23
2021-03-28 15:31:50 DEBUG: send: [ReadRegisterResponse (23)]- b'02030000003102032e04d200000032003200320032000000000000000f0001271027102710fc18fc18fc1805dc0078000000004e200000'

Looking at the bytes:
From me:
02032e000000000005000500050005000000010000000f0001271027102710fc18fc18fc1805dc0078000000004e2000000a36
From nmakel:
02030000003102032e04d200000032003200320032000000000000000f0001271027102710fc18fc18fc1805dc0078000000004e200000

Some of the data is diffrent due to some differences in settings. But why does the log from nmakel have 020300000031 in the beginning and after that almost matchning data?
Sorry of there is a natural explanation to this. But I wanted to point it out since i noticed the same in the logs from the other issue.
The data there was:
02032e04d200000032003200320032000000000000000f0001271027102710fc18fc18fc1805dc0000000000004e200000ca71

from solaredge_meterproxy.

I'm setting up a new StorEdge inverter and already had a SDM630 so this code would fit perfect!

Great, thanks for trying this project out.

The setup might be a bit different since I don't have normal CT:s, but rogowski coils.
https://www.aliexpress.com/item/32994844856.html

Therefore i'm not 100% sure what CT value I should set and how it affects. Since the meter is reporting correct values I don't understand what exactly this setting does.

Shouldn't matter. I don't have CTs either, and everything works fine.

I have tried this config:

[server]
device = /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_0106F08D-if00-port0
meters = import_export

[import_export]
type=sdm630
device=/dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_010D5A07-if00-port0
baud=9600
src_address=1
dst_address=2
refresh_rate = 5
ct_current = 5

Looks good.

2021-04-29 09:26:05 DEBUG: Frame check failed, ignoring!!
2021-04-29 09:26:05 DEBUG: Resetting frame - Current Frame in buffer -
2021-04-29 09:26:06 DEBUG: Getting Frame - 0x3 0x6 0x40 0x0 0x17
2021-04-29 09:26:06 DEBUG: Factory Request[ReadHoldingRegistersRequest: 3]
2021-04-29 09:26:06 DEBUG: Frame advanced, resetting header!!
2021-04-29 09:26:06 DEBUG: validate: fc-[3] address-1601: count-23
2021-04-29 09:26:06 DEBUG: getValues fc-[3] address-1601: count-23
2021-04-29 09:26:06 DEBUG: send: [ReadRegisterResponse (23)]- b'02032e04d200000005000500050005000000000000000f0001271027102710fc18fc18fc1805dc0078000000004e2000007700'

Those first few frame check errors might be due to an incomplete message still in the serial buffer. The last few lines look fine, though.

The difference in logged requests might be due to me using the TCP version. The last few bytes are crc checks, and the first few bytes are RTU to TCP encapsulation.

Still, you're running into similar issues as #8, so I'm wondering whether you can post the inverter firmware version you have.

from solaredge_meterproxy.

Hello!

Thank you for the quick response. Too bad the thing i found wasn't an error.

The "Not a valid unit id - 112, ignoring!!" errors I actually get constantly. It might have something to do with the fact that there seems to be something connected to the bus since there is a small pcb with a cable on it, in the RS485-1 port of the communication board of the inverter. Like a RS485 splitter. I was thinking it had something to do with the battery communication, even if the actual battery is connected to Canbus.

Here are my versions:
CPU Version: 4.12.28
DSP1 Version: 1.13.1781
DSP2 Version: 2.19.1440
DCDC Version: 22.91
WSA Version: 4.12.7

If it seems to be hard to find the issue for this problem we have, I might give it a try to find the modbus registers for the Inepro pro380 meter instead and try to fork your code to implement it's registers instead.

from solaredge_meterproxy.

I've managed to find a workaround to #8 by implemented a Janitza compatible metering proxy. With that I get actual powers reported, but the energy reporting is still off (whether I report all zero energy values or actuals). Pretty sure I'm using the right registers with the right values (any helpful ideas here might be helpful).

I've had a version update since starting #8 and am now at version:
CPU Version: 4.12.28
DSP1 Version: 1.0.1159
DSP2 Version: 2.0.1011
WSA Version: 4.12.7
Haven't yet tried if an SE metering proxy now works again.
I will share the Janitza implementation when I get around to it :-).

from solaredge_meterproxy.

The "Not a valid unit id - 112, ignoring!!" errors I actually get constantly. It might have something to do with the fact that there seems to be something connected to the bus since there is a small pcb with a cable on it, in the RS485-1 port of the communication board of the inverter. Like a RS485 splitter. I was thinking it had something to do with the battery communication, even if the actual battery is connected to Canbus.

Interesting. What model battery do you have connected?

CPU Version: 4.12.28
DSP1 Version: 1.13.1781
DSP2 Version: 2.19.1440
DCDC Version: 22.91
WSA Version: 4.12.7

Thanks. Just like @jonesPD you're on a newer firmware version than I am.

If it seems to be hard to find the issue for this problem we have, I might give it a try to find the modbus registers for the Inepro pro380 meter instead and try to fork your code to implement it's registers instead.

You can find the register map at the end of this document. It should be fairly simple to adapt the current script to the Inepro. Please share your results if you decide to try this!

from solaredge_meterproxy.

I will share the Janitza implementation when I get around to it :-).

Please do!

from solaredge_meterproxy.

``> Interesting. What model battery do you have connected?

It's actually a DIY battery but it's reporting data over canbus with same protocol as the LG Resu battery.

Thanks. Just like @jonesPD you're on a newer firmware version than I am.

Ok!

You can find the register map at the end of this document. It should be fairly simple to adapt the current script to the Inepro. Please share your results if you decide to try this!

Thank you. I actually already started and also found another document that better explained the settings registers better. I will report back with the results. So far no luck since it seems to get stuck at getting settings registers even here.

Also a note.. I have actually confirmed that the battery has 112.

 "batteries": {
        "Battery1": {
            "c_manufacturer": "48V_LG",
            "c_model": "LGC RESU 10",
            "c_version": "48V DCDC 2.2.91 BMS 0.0.0",
            "c_serialnumber": "7E043FB3",
            "c_deviceaddress": 112,
            "c_sunspec_did": 0,
            "rated_energy": 9800.0,
            "maximum_charge_continuous_power": 5000.0,
            "maximum_discharge_continuous_power": 5000.0,
            "maximum_charge_peak_power": 3200.0,
            "maximum_discharge_peak_power": 3200.0,
            "average_temperature": 22.0,
            "maximum_temperature": 0.0,
            "instantaneous_voltage": -1.224738359451294,
            "instantaneous_current": 0.0,
            "instantaneous_power": 0.0,
            "lifetime_export_energy_counter": 0,
            "lifetime_import_energy_counter": 0,
            "maximum_energy": 9800.0,
            "available_energy": 8800.0,
            "soh": 100.0,
            "soe": 56.0,
            "status": 65535,
            "status_internal": 13,
            "event_log": 0,
            "event_log_internal": 0
        }
``

from solaredge_meterproxy.

@jonesPD Thank you for the details. Is your Janitza implementation based on this code or a completely new project?
I have been trying to use the registers for the PRO380 meter for a while now, but ends up stuck in the same way as the original code, where it only pulls the settings registers and after that complains with communications errors.

So I have also been trying the Janizta now. With that setting, the inverter seems to start pulling data from the measurement registers right away, (19021 with a length of 24) but I still don't get it to work. I would be very happy if you could share your code and I can give that a go. You said you has issues with energy registers. One thing i noticed is that they should be stored in Wh in the Janizta but I get them in kWh from the SDM630. I'm not sure how yours are stored?

Another thing that is on my mind is that the configuration in the setapp for me is missing the sunspec protocol in the menu for RS485-1. That might be a big deal? But I still can choose the other brands of meters like the PRO380 and Janitza.

from solaredge_meterproxy.

@djmoonshine: my code is attached, it is heavily based on this project, but not yet integrated so that you can for example select in the config file the type of meter you want to proxy. I've based it the register map in this PDF.
janitza-registers-umg104-en.pdf
I don't recall not having the SunSpec protocol in the menu for RS485-1 (I have my meterproxy connected to RS485-2, to test whether that made the SE-proxy work, which didn't make a difference).

The power readings seem to work fine, the energy reading is odd. I don't have a recent SetApp screenshot, and since the sun has almost set it is better to provide one tomorrow. In the solaredge app you can see a different chart that now shows not only the converted solar power, but also the consumed power, and self consumption in a single graph.

As you can see in the screenshot though is that the energy totals are off (except for the system production), and that it doesn't show any exported energy. I haven't been able to fix this, and testing is also rather slow, because when the SE-server detects a major disruption in the data (e.g. when you change signs or start providing data), you have to wait until the next day for the graphs to come back).
My assumption so far has been that negative power indicates energy is provided to the grid, however, neither the total, or the import/exported energy is negative. Any thoughts and suggestions what to test at my end are welcome.

The code is needs some cleaning up, and integration with the original project.
@nmakel : what are your thoughts about integrating my code with your project?

janitza.zip

@djmoonshine : success in getting it to work!

from solaredge_meterproxy.

@nmakel : what are your thoughts about integrating my code with your project?

Thanks for posting your working example. I'll have a look at the differences and perhaps I can find the reason why the original isn't working on newer firmware versions.

from solaredge_meterproxy.

@djmoonshine: my code is attached, it is heavily based on this project, but not yet integrated so that you can for example select in the config file the type of meter you want to proxy.

Could you also provide me with the configuration file you are using?

from solaredge_meterproxy.

The screen in SetApp is odd, since it shows the (correct) actual power, and at the same time a negative import of the same number:

from solaredge_meterproxy.

@jonesPD Thank you so much for sharing your code. It actually kind of worked, but with some weird behavior in about the same way as your screenshot. The energy bugs the most. I actually found out that my exported energy likes to show the data for " Reactive power L2", but switches to the correct data to, so it can't be just something totally wrong with the registers in the code.
The data from the SDM also looks correct so that don't seem to be the issue either. I debugged this a lot during the weekend, but for now, the issue below is the bigger one.

Also as I have mentioned before. I get "meter communication error 3x6e" in the inverter. That error didn't just go away with this code, bacause that seems to be another issue. When I disable the battery communication the communication with the meter works fine, but with the battery activated i get those "Not a valid unit id - 112, ignoring!!" which i guess is normal, because it's the communication to the battery. But I also get a lot of "DEBUG: CRC invalid, discarding header!!" and almost no requests for data for the meter. So i assume the crc errors happens for the requests to the "meter". I have tried different configurations of termination resistors both at the inverter end with the dip switch both on and off (according to the manual it should be off) and also at the meter end (or actually in this case an USB adapter in a raspberry pi) but with no luck. So at the moment i cannot have the meter and battery running at the same time, and that is a big deal since a lot of the functionality i want with the battery, needs a import/export meter.

Any suggestions? I have ordered a higher quality RS485 adapter to see if that is the issue. But it will not arrive until the end of the week.

from solaredge_meterproxy.

Just now I actually foud out an interesting thing.
I upgraded pymodbus to 2.5.1 (was on 2.4.0 before), no change there.
But I did a more complete check on the debug messages now for the CRC errors and find this:
2021-05-03 10:50:20 DEBUG: Resetting frame - Current Frame in buffer - 0xff 0xff 0xff... (repeated lot of times)... 0xff 0x51 0x5c 0x2 0x3 0x4a 0x4c 0x0 0x18 0x92 0x3c
The interesting piece here is that the last part ( 0xff 0x51 0x5c 0x2 0x3 0x4a 0x4c 0x0 0x18 0x92 0x3c) is the actual request for the Janitza registers (0x2 0x3 0x4a 0x4c 0x0 0x18 0x92 0x3c).
Not sure how this happens, is it a something that happens because of all traffic to and from the battery it's to tight in timing? Or something else that can be fixed? Or can a termination issue cause this? I get that now we off topic for this code though :( But I guess other could end up in the same situation.

from solaredge_meterproxy.

The energy bugs the most. I actually found out that my exported energy likes to show the data for " Reactive power L2", but switches to the correct data to, so it can't be just something totally wrong with the registers in the code.

So if I put the export energy values in the L2 reactive power register, they show up as export energy in SetApp? Thanks for sharing I'll try that too

The data from the SDM also looks correct so that don't seem to be the issue either. I debugged this a lot during the weekend, but for now, the issue below is the bigger one.

Have you tried connecting the meter and the battery to a separate RS485 port each? Are both set to the same baudrate (9600baud) and parity?
What kind of cable are you using to connect? The SE manual has some guidelines.

from solaredge_meterproxy.

But I did a more complete check on the debug messages now for the CRC errors and find this:
2021-05-03 10:50:20 DEBUG: Resetting frame - Current Frame in buffer - 0xff 0xff 0xff... (repeated lot of times)... 0xff 0x51 0x5c 0x2 0x3 0x4a 0x4c 0x0 0x18 0x92 0x3c

I also get those every now and then and also have not been able to resolve them with updated pymodbus, cabling, terminator settings or another rs485 dongle. I actually had two dongles talking to one another, if I recall correctly without errors.

from solaredge_meterproxy.

@jonesPD, please also share your configuration file.

@djmoonshine, while the battery modbus traffic might be reflected if you do not have proper termination resistors on the RS485 bus, there shouldn't be any timing or collission issues. The inverter is the only Modbus master on the bus, and the battery and meterproxy will only answer when spoken to. Could you share the make and model of your RS485 adapter?

I agree with jonesPD that it may be better to move the meterproxy to the second RS485 input on your inverter. It would be helpful if you could also make a few screenshots of how the RS485-1, RS485-2 and subsequent meter is configured in SetApp.

from solaredge_meterproxy.

@jonesPD, please also share your configuration file.

It should be part of the janitza.zip file in my earlier post. Otherwise it will take a few days before I have access to it.

from solaredge_meterproxy.

@jonesPD, please also share your configuration file.

It should be part of the janitza.zip file in my earlier post. Otherwise it will take a few days before I have access to it.

You're absolutely right. I must have missed it the first time around.

from solaredge_meterproxy.

The energy bugs the most. I actually found out that my exported energy likes to show the data for " Reactive power L2", but switches to the correct data to, so it can't be just something totally wrong with the registers in the code.

So if I put the export energy values in the L2 reactive power register, they show up as export energy in SetApp? Thanks for sharing I'll try that too

@djmoonshine : Removing all other measured values from the return of the 'values' functions, I've now tried your suggestion to put the energy values in different registers and import/export energy meter values now show up in SetApp:

• register 19026: actual power (import=positive/delivery=negative)
• register 19034: imported energy
• register 19042: exported energy

This seems very odd to me, all Janitza modbus register maps I've found on the web show these registers as respectively total real power, total apparent power and total reactive power (where total refers to their (vector) sum over 3 phases). I'll let it run like this for a few days to see the result in the monitoring app.

Did you get any step further?

from solaredge_meterproxy.

Energy metering now shows up properly in the mySolarEdge app as well:

from solaredge_meterproxy.

Hi everyone. How did you resolve this problem finally? It looks like I've got similar problem. My meter (SDM630) is connected, SE shows status as OK but no valid serial or meter data is presented.

from solaredge_meterproxy.

I had wierd issues and since I use battery storage with my Solaredge inverter having a constant and reliable connection was very important i finally ended up buying a real Solaredge meter.
But something that in my case got me much closer to getting things to work was to use the janizta code in this "thread" and adding a very low timeout value for the serial server since it seems in my case that something could not separate the modbus frames.

Something like this:

 StartSerialServer(
            server_ctx,
            framer=framer,
            identity=identity,
            port=confparser["server"].get("device", fallback=default_config["server"]["device"]),
            baudrate=confparser["server"].get("baud", fallback=default_config["server"]["baud"]),
            parity=confparser["server"].get("parity", fallback=default_config["server"]["parity"]),
            #timeout=confparser["server"].get("timeout", fallback=default_config["server"]["timeout"]),
            timeout=.005,
            ignore_missing_slaves=True,
        )

from solaredge_meterproxy.

Thank you for your response. It looks like SE is blocking something in new FW.
I will try find a solution as soon as I will find more free time ;-)

from solaredge_meterproxy.

I had wierd issues and since I use battery storage with my Solaredge inverter having a constant and reliable connection was very important i finally ended up buying a real Solaredge meter. But something that in my case got me much closer to getting things to work was to use the janizta code in this "thread" and adding a very low timeout value for the serial server since it seems in my case that something could not separate the modbus frames.

Something like this:

 StartSerialServer(
            server_ctx,
            framer=framer,
            identity=identity,
            port=confparser["server"].get("device", fallback=default_config["server"]["device"]),
            baudrate=confparser["server"].get("baud", fallback=default_config["server"]["baud"]),
            parity=confparser["server"].get("parity", fallback=default_config["server"]["parity"]),
            #timeout=confparser["server"].get("timeout", fallback=default_config["server"]["timeout"]),
            timeout=.005,
            ignore_missing_slaves=True,
        )

Thanks for letting us know! I would be interested in hearing whether the timeout is the real culprit, and not just a problem with the registers that are being presented -- which is what the switch to the janitza mapping would suggest.

It could of course be that SE applies more strict checks to verify the type of meter it is communicating with in newer firmware versions. Wouldn't be out of character.

from solaredge_meterproxy.

@djmoonshine

``> Interesting. What model battery do you have connected?

It's actually a DIY battery but it's reporting data over canbus with same protocol as the LG Resu battery.

Would you mind sharing how you are reporting your battery data to SolarEdge?
Im going to build a 100 kWh powerwall and would like to publish the data to Solaredge.
System will be working with Victron Multiplus 2 as charger/inverter.

from solaredge_meterproxy.