search

nmakel / solaredge_meterproxy

Modbus proxy for SolarEdge inverters and unsupported kWh meters
MIT License
29 stars 20 forks source link

Fixes direct RTU/serial connection to inverter #12

Closed ksjoberg closed 2 years ago

ksjoberg commented 2 years ago

The timeout property in a serial context means how long a read can be ongoing trying to fill the supplied buffer.

The default value of 1 second creates a situation where the simulated modbus slave appears to be nonresponsive from the SolarEdge inverter's perspective, as it issues a read request and for up to a second, the slave does not respond. The WattNode physical device is specified to respond within 200 ms. Its default setting with regards to parity is N1, i.e. no parity, 1 stop bit.

Allow fractional seconds as timeout and lower the serial timeout to 0.1 s, which risks more incomplete RTU frames to be returned from the serial library, but this is normal and handled by the pymodbus library.

nmakel commented 2 years ago

Thanks! Can you confirm this working and detail your set-up?

nmakel commented 2 years ago

As an aside, please also have a look at sending any necessary PRs to enable sdm_modbus to do what you need to have your GNM3D work without a whole bunch of hacks. The endianness issue should be configurable in the base library, for example; and I also like your scaling solution.

ksjoberg commented 2 years ago

So I have a SolarEdge SE16k inverter and a GARO GLB+ EV Charge Box.

The latter has a meter, namely a GARO GNM3D-LP-RS485 (LP for Local Production) installed in the right spot for the EV Charger to be able to limit the charge current based on the main fuse load.

I decided to see if it was feasible to use your library to connect the SolarEdge inverter to the GNM3D meter. For that purpose I have a Raspberry Pi and a couple of USB RS485 adapters CC-USB-RS485-150U, connected to the GARO meter and the inverter.

Getting the Energy meter device working was the easy part, except for a few hacks. I noticed your SDM library had a good starting point and wanted to avoid code duplication as far as possible.

I will package up and PR the changes in the sdm_modbus required for it to become more generic and work with the GARO meters too without ugly hacks. I take it from your comment that you're OK widening the device support of sdm_modbus.

I had to capture a trace from a logic analyzer to fully see what was going wrong in the initialization. I take it from the Modbus TCP support that you interact with the SolarEdge inverter side through one of those RTU/TCP converters?

I'll look into further reducing the latency over the serial link. The SolarEdge inverter seem to be extremely interested in the registers 1011-1017, containing the p1-p3 active power in Watts. I notice ~10 requests for those six registers per second.

nmakel commented 2 years ago

I take it from your comment that you're OK widening the device support of sdm_modbus.

Absolutely, if it fits in the subclass to define registers pattern the more devices that are supported the better.

I had to capture a trace from a logic analyzer to fully see what was going wrong in the initialization. I take it from the Modbus TCP support that you interact with the SolarEdge inverter side through one of those RTU/TCP converters?

That's correct. The advantage of tGW-715s with PoE is that a single system with ethernet throughout the house can do what I need instead of Pi's with serial connections everywhere.

ksjoberg commented 2 years ago

I figured that either I roll my own 3 channel Modbus RTU to TCP device, or buy three single channel devices. I opted out once I realized I still had to have a device to run your Python device on, and I also had all buses confined to the same cabinet making the grand total $150 cost for the Pi, three USB RS485 dongles and PoE shield unbeatable.