sorry, figured something out... i needed to uncomment some stuff in the following section:

[meter1] dst_address = 2 src_address = 1 type = sdm120 serial_number = 987654 #host = 10.0.0.123 #port = 502 #ct_current = 50

now i get the following error
Traceback (most recent call last): File "semp-rtu.py", line 172, in <module> extended=confparser[meter].get("extended", fallback=default_config["extended"]) KeyError: 'extended'

so i added
extended = False

to the [meter1] section. This doesnt seem to fix it.

So i changed the following line
extended=confparser[meter].get("extended",` fallback=default_config["extended"])

to include [meters]
extended=confparser[meter].get("extended",` fallback=default_config["meters"]["extended"])

Now the script seems to run but with following output:
pi@raspberrypi4:~/eastronsolaredge $ python3 semp-rtu.py 2020-11-19 08:45:50 INFO: Created <Thread(t_update_2, initial)>: meter1 sdm120 SDM120(False:False, connectionType.TCP: timeout=1, retries=3, unit=0x1) 2020-11-19 08:45:51 CRITICAL: t_update_2: getaddrinfo() argument 1 must be string or None 2020-11-19 08:45:51 INFO: Starting <Thread(t_update_2, started 3053249632)> 2020-11-19 08:45:56 CRITICAL: t_update_2: getaddrinfo() argument 1 must be string or None

from solaredge_meterproxy.

Could you paste your config file?

from solaredge_meterproxy.

tried running the code again, i did change somethings later today. so i have removed all files from my RPI and uploaded it again.

Running:
python3 semp-rtu.py

results in:
Traceback (most recent call last):
File "semp-rtu.py", line 172, in
extended=confparser[meter].get("extended", fallback=default_config["extended"])
KeyError: 'extended'

config looks like this now:

Masqueraded meters, comma separated.

optional, default: ''

#meters = meter1, meter2
meters = meter1

Meters defined in [server] need a config section, one per meter.

Depending on the type of meter that is to be masqueraded, you can

define ModbusRTU or ModbusTCP variables.

An SDM120 over ModbusTCP, for example:

[meter1]
dst_address = 2
src_address = 1
type = sdm120
serial_number = 987654
#host = 10.0.0.123
#port = 502
#ct_current = 50

if i add ["meters"] on line 172 in semp-rtu.py if get this output

2020-11-19 19:01:13 INFO: Created <Thread(t_update_2, initial)>: meter1 sdm120 SDM120(False:False, connectionType.TCP: timeout=1, retries=3, unit=0x1)
2020-11-19 19:01:14 CRITICAL: t_update_2: getaddrinfo() argument 1 must be string or None
2020-11-19 19:01:14 INFO: Starting <Thread(t_update_2, started 3053745248)>
2020-11-19 19:01:19 CRITICAL: t_update_2: getaddrinfo() argument 1 must be string or None
2020-11-19 19:01:24 CRITICAL: t_update_2: getaddrinfo() argument 1 must be string or None

from solaredge_meterproxy.

i updated the meter1 section:
[meter1]
dst_address = 2
src_address = 1
type = sdm120
serial_number = 987654
device = /dev/ttyUSB0
stopbits = 1
parity = e
baud = 2400
timeout = 1
#host = 10.0.0.123
#port = 502
#ct_current = 50

result:

Traceback (most recent call last):
File "semp-rtu.py", line 172, in
extended=confparser[meter].get("extended", fallback=default_config["meters"]["extended"])
File "/home/pi/eastronsolaredge/devices/sdm120.py", line 18, in device
unit=unit
File "/home/pi/.local/lib/python3.7/site-packages/sdm_modbus/init.py", line 256, in init
super().init(*args, **kwargs)
TypeError: init() got an unexpected keyword argument 'baudrate'

from solaredge_meterproxy.

Excellent! Looks like you ran into two bugs I would never have seen. I connect to a SDM120 over ModbusTCP via a Modbus to Ethernet gateway. Both problems should be fixed now, please try again!

Also, you mentioned that you have a SDM630 unit. If so, you should change the type configuration to SDM630 in your config file.

from solaredge_meterproxy.

Hi,

Thanks will try again tomorrow!

Yes I have a SDM120C too with which I'm testing it first. It's still connected to that RPI which I'm testing it on.

What are you using for the ModbusTCP comms? Mind sharing that too? I got a lot of Wemos D1 Mini laying around and got the SDM630 connected to one running Tasmota... but it doesn't update any faster then 10 seconds... I want it to send data every 1 second.

I always want to connect the SDM120C with a Wemos d1 mini and place my RPI in a different location.

from solaredge_meterproxy.

I have the SDM120 connected to a PoE powered tGW-715. It handles multiple requests per second without issue. I then run the solaredge_meterproxy script on an openwrt powered mini router which is connected to the inverter with a RS485 to USB dongle. Another device on the network also polls the SDM120 through the tGW-715 and dumps the results into an InfluxDB database, which could also be used as a source for solaredge_meterproxy if I find the time to make a suitable device script.

from solaredge_meterproxy.

I just changed the baud line as I already figured extended out(was also thinking of removing the rate in baudrate but didn't do it)

Now I got this:

2020-11-19 22:49:43 CRITICAL: t_update_2: Not a valid parity: 'e'����������������������������pi@raspberrypi4:~/eastronsolaredge$ python3 semp-rtu.py��������������������������������������2020-11-19 22:50:41 INFO: Created <Thread(t_update_2, initial)>: meter1 sdm120 SDM120(/dev/t�tyUSB1, connectionType.RTU: stopbits=1, parity=e, baud=2400, timeout=1, retries=3, unit=0x1)�2020-11-19 22:50:42 CRITICAL: t_update_2: Not a valid parity: 'e'����������������������������2020-11-19 22:50:42 INFO: Starting <Thread(t_update_2, started 3053675616)>������������������2020-11-19 22:50:47 CRITICAL: t_update_2: Not a valid parity: 'e'��������������

from solaredge_meterproxy.

Parity needs to be in capital letters: E for example

from solaredge_meterproxy.

Ok, thanks for looking into this. I'm not quite sure why it's defaulted to e anyway, as the sdm_modbus library is defaulted to -- correctly capitalized -- N. It is probably better to default the RTU parameters to False and let sdm_modbus figure it out.

from solaredge_meterproxy.

So, quick question on how do you see that everything needs to be wired?
You are using modbusTCP, im running wired modbus to the SDM unit for now.

So the script semp-rtu.py will pull data from the SDM when solaredge asks for it right?

So i suppose i need to daisy chain the SDM with the PI and the Solaredge right?

from solaredge_meterproxy.

My situation is a bit different from yours, i have the following: inverter <- rs485 to USB-RS485 adapter -> openwrt router <- ethernet -> modbustcp gateway <- rs485 -> SDM120. The inverter talks Modbus RTU to the semp-rtu.py script on my openwrt router, thinking it is a supported kwh meter. The semp-rtu.py script replies to the inverter over the Modbus RTU connection with values it has updated in the background over Modbus TCP from my SDM120.

In your case you have both devices as Modbus RTU connected only via RS485 twisted pair, right? I'm not sure a single RS485 serial device (your /dev/ttyUSB0) can act as server and client at the same time. The Modbus server is needed to listen to requests from the inverter, while client functionality is required to request values from your kwh meter. If you have a second USB-RS485 dongle this will definitely work, just tell semp-rtu.py to listen to your inverter on one, and connect to the kwh meter on the other. Give it a try though, it might just work. You will need to set the meter's device id on the inverter to a different value than the actual device id of your SDM120: the semp-rtu.py script will respond to any request from the inverter, but it will probably mess things up if your SDM120 also responds to the inverter with an error.

Are you currently storing your kwh meter values in a database? In that case we could have semp-rtu.py talk to the database instead.

from solaredge_meterproxy.

I got Domoticz storing the electricity company meter signals in its own database.

The SDM630 is now connected to Tasmota and publishing its data via MQTT. I haven't connected anything yet to do something with that information as is haven't yet looked for a way to push it to Influx which is also running.

I did find a script that could make a ESP8266 unit into a ModbusRTU/ModbusTCP bridge. I will try that.
www.GitHub.com/emelianov/modbus-esp8266 and then the examples ip-bridge file

from solaredge_meterproxy.

Thanks for the update. Let me know if there's anything I can do to help.

from solaredge_meterproxy.

If you want we can make a try and get it from influx to Solaredge.

Maybe for speed of communication, if you want offcourse, we can use Facebook chat? I don't know if you have Facebook.

from solaredge_meterproxy.

Check out the influxdb script in devices. You will need to modify the variable names to correspond to those in your database.

No Facebook I'm afraid, but feel free to send me an e-mail (in the git log).

from solaredge_meterproxy.