-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No values reported #8
Comments
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... |
Looks like I had a typo in the configuration examples. 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... |
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.
|
That's weird. Can you set your config to block_1601:
block_1651:
block_1701:
block_1001:
block_1101:
A working example is worth a thousand words, here are my meter
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 |
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.
|
I think you forgot the attachment. |
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. |
Indeed. Removed that. |
The first zip file, yeah. After that, nothing. |
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. |
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. 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. |
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? Which pymodbus version are you on? Which inverter CPU version are you on? |
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 Can you provide screenshots of the SetApp |
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). 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? |
Thanks for the screenshots. All of that looks fine. There shouldn't be a difference between SolarEdge or Wattnode as 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. |
It is no problem to read out the Modbus inverter values via RS485. |
Ok, so that's not something to worry about.
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
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. |
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 |
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? |
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:
What I noticed though, also when the 1608 is configured as 1, it sends a request to modify the register: --> after a while <-- 2021-03-07 19:59:15 DEBUG: Getting Frame - 0x6 0x6 0x47 0x0 0x0 --> is it writing to the correct register here? it now says 1607, where 1608 was requested? --> subsequent requests for the whole of 1601 --> 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? |
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.
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.
That's odd if true, but check your logs. The write request, for example
I tried to find this in the documentation but couldn't. I'm assuming it does.
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_1701, modified the model to 203.
|
That didn't help either unfortunately. 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? |
Are you saying that with the terminator set to OFF the correct serial number is displayed? |
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. |
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. |
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. |
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). |
Sure, see the attached debug output. Your |
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
The text was updated successfully, but these errors were encountered: