Open fkemps opened 10 months ago
The debug output looks fine. As you see the meter is correctly registered and reporting values in the SolarEdge app.
What are the necessary MQTT fields and value dimensions? You'll need to ask @marcelrv as you're using his P1 scripts.
__Am I correct that latest pymodbus version supported is 2.5.3? (with latest 3.6.3 solardedge_meterproxy didn't start)__ Grab the latest github version, which should support newer pymodbus versions.
The screenshot you posted shows correct self-consumption, or am I misinterpreting it?
Sorry I'm on holidays this week.. Can take a look next week... But the screenshot indeed looks like it has the right consumption and delivery to the net
Hello nmakel,
Upgraded to pymodbus 3.6.3 but solaredge_meterproxy did not start anymore with following error.
Feb 12 21:39:55 hab python3[21214]: Traceback (most recent call last):
Feb 12 21:39:55 hab python3[21214]: File "/etc/openhab/github/solaredge_meterproxy/semp-tcp.py", line 160, in <module>
Feb 12 21:39:55 hab python3[21214]: 2024-02-12 21:39:55 INFO: Connected to MQTT: 192.168.254.13:1883/energy/meter
Feb 12 21:39:55 hab python3[21214]: block_1601 = BinaryPayloadBuilder(byteorder=Endian.Big, wordorder=Endian.Little)
Feb 12 21:39:55 hab python3[21214]: File "/usr/lib/python3.9/enum.py", line 405, in __getattr__
Feb 12 21:39:55 hab python3[21214]: raise AttributeError(name) from None
Feb 12 21:39:55 hab python3[21214]: AttributeError: Big
Solved it by updating semp-tcp.py and replacing Big to BIG and Little to LITTLE e.g.block_1601 = BinaryPayloadBuilder(byteorder=Endian.Big, wordorder=Endian.Little)
by block_1601 = BinaryPayloadBuilder(byteorder=Endian.BIG, wordorder=Endian.LITTLE).
I suggest updating your code as I've seen a couple of posts where ppl reported solaredge_meterproxy failed to start with the same error.
I'm not using marcelrv's mqttP1.py device but the default mqtt device and feed it from OpenHAB via a rule in which I publish values to MQTT. I've been busy for a month now but can't get it stable on Solaredge Monitoring and values incorrect.
The SE monitoring behavior changes with the values I publish on MQTT. That's why I'm very curious about what needs to be published on MQTT and in what values.
This is what I have currently
Consuming from net only.
{
"l1_power_active": 16.000,
"l2_power_active": 220.00,
"l3_power_active": 242.000,
"voltage_ln": 236.8,
"l1n_voltage": 236.8,
"l2n_voltage": 236.5,
"l3n_voltage": 235.1,
"frequency": 50,
"l1_energy_active": 0.016,
"l2_energy_active": 0.22,
"l3_energy_active": 0.242,
"l1_import_energy_active": 0.016,
"l2_import_energy_active": 0.22,
"l3_import_energy_active": 0.242,
"l1_export_energy_active": 0,
"l2_export_energy_active": 0,
"l3_export_energy_active": 0,
"export_energy_active": 0,
"l1_current": 0.06756757,
"l2_current": 0.93023256,
"l3_current": 1.02934921
}
Consuming and delivering to net.
{
"energy_active": 1.083,
"l1_power_active": -194.000,
"l2_power_active": 265.000,
"l3_power_active": 1012.000,
"voltage_ln": 237.1,
"l1n_voltage": 237.1,
"l2n_voltage": 236.5,
"l3n_voltage": 234.3,
"frequency": 50,
"l1_energy_active": -0.194,
"l2_energy_active": 0.265,
"l3_energy_active": 1.012,
"l1_import_energy_active": 0,
"l2_import_energy_active": 0.265,
"l3_import_energy_active": 1.012,
"l1_export_energy_active": 0.194,
"l2_export_energy_active": 0,
"l3_export_energy_active": 0,
"export_energy_active": 0,
"l1_current": -0.81822016,
"l2_current": 1.12050740,
"l3_current": 4.31924883
}
I think the problem lies in your *_energy_*
values. These are cumulative, not instantaneous. You should be feeding kWh and not W into them.
Here is an example data set from a single phase system connected to a three-phase utility, using a SDM630 kWh meter:
{
'l1_voltage': 237.73455810546875,
'l2_voltage': 237.90313720703125,
'l3_voltage': 236.62315368652344,
'l1_current': 0.9704264998435974,
'l2_current': 1.1172029972076416,
'l3_current': 1.05608332157135,
'l1_power_active': 118.17377471923828,
'l2_power_active': 53.25270462036133,
'l3_power_active': 58.313140869140625,
'l1_power_apparent': 230.70391845703125,
'l2_power_apparent': 265.7861022949219,
'l3_power_apparent': 249.89376831054688,
'l1_power_reactive': -198.13951110839844,
'l2_power_reactive': -260.3966369628906,
'l3_power_reactive': -242.99481201171875,
'l1_power_factor': 0.5122312903404236,
'l2_power_factor': 0.20035924017429352,
'l3_power_factor': 0.2333517074584961,
'l1_phase_angle': -59.19178771972656,
'l2_phase_angle': -78.44780731201172,
'l3_phase_angle': -76.51114654541016,
'voltage_ln': 237.4202880859375,
'current_ln': 1.0479042530059814,
'total_line_current': 3.144514560699463,
'total_power_active': 231.32945251464844,
'total_power_apparent': 739.7161865234375,
'total_power_reactive': -702.6143188476562,
'total_power_factor': 0.3127272427082062,
'total_phase_angle': -71.7816162109375,
'frequency': 49.92549133300781,
'import_energy_active': 5797.40283203125,
'export_energy_active': 5632.2275390625,
'import_energy_reactive': 2.4019999504089355,
'export_energy_reactive': 11099.5068359375,
'total_energy_apparent': 15933.888671875,
'total_current': 56672.921875,
'total_import_demand_power_active': 315.1787109375,
'maximum_import_demand_power_apparent': 3761.124755859375,
'import_demand_power_active': 0.0,
'maximum_import_demand_power_active': 0.0,
'export_demand_power_active': 0.0,
'maximum_export_demand_power_active': 0.0,
'total_demand_power_apparent': 774.6001586914062,
'maximum_demand_power_apparent': 3849.246337890625,
'neutral_demand_current': 0.27261316776275635,
'maximum_neutral_demand_current': 11.004886627197266,
'l12_voltage': 411.8796691894531,
'l23_voltage': 410.880859375,
'l31_voltage': 410.7441101074219,
'voltage_ll': 411.168212890625,
'neutral_current': 0.1270132064819336,
'l1n_voltage_thd': 2.6970396041870117,
'l2n_voltage_thd': 2.6505331993103027,
'l3n_voltage_thd': 2.3453309535980225,
'l1_current_thd': 43.37419891357422,
'l2_current_thd': 34.6869010925293,
'l3_current_thd': 22.72454833984375,
'voltage_ln_thd': 2.5643012523651123,
'current_thd': 33.59521484375,
'total_pf': -71.93041229248047,
'l1_demand_current': 1.003432273864746,
'l2_demand_current': 1.0749841928482056,
'l3_demand_current': 1.2879137992858887,
'maximum_l1_demand_current': 12.498915672302246,
'maximum_l2_demand_current': 6.935347080230713,
'maximum_l3_demand_current': 6.183877944946289,
'l12_voltage_thd': 0.0,
'l23_voltage_thd': 0.0,
'l31_voltage_thd': 0.0,
'voltage_ll_thd': 0.0,
'total_energy_active': 11429.630859375,
'total_energy_reactive': 11101.908203125,
'l1_import_energy_active': 2063.18896484375,
'l2_import_energy_active': 2089.662841796875,
'l3_import_energy_active': 1644.5509033203125,
'l1_export_energy_active': 5632.2275390625,
'l2_export_energy_active': 0.0,
'l3_export_energy_active': 0.0,
'l1_energy_active': 7695.4169921875,
'l2_energy_active': 2089.662841796875,
'l3_energy_active': 1644.5509033203125,
'l1_import_energy_reactive': 0.8269999623298645,
'l2_import_energy_reactive': 0.9099999666213989,
'l3_import_energy_reactive': 0.6649999618530273,
'l1_export_energy_reactive': 2722.0,
'l2_export_energy_reactive': 4846.35693359375,
'l3_export_energy_reactive': 3531.14990234375,
'l1_energy_reactive': 2722.826904296875,
'l2_energy_reactive': 4847.2666015625,
'l3_energy_reactive': 3531.81494140625
}
Thanks for sharing the SDM630 value details. It gives me something to chew on.
The upgrade of pymodbus v2.5.x to v3.6.x made a huge difference in monitoring stability on the SE monitoring portal. There are no more gaps during the day, which happened randomly and frequently. This resulted in the high-energy reported peaks (40kWh and higher) as shown in the screenshot.
This looks promising going forward. Today not much PV production and values look much better. Will optimize MQTT shared fields in the next few days and share the result.
With regards to the energy would it mean that the following calculation should be performed while reporting every 10 seconds?
(W x hrs)/1000 so 500W becomes (500W x 0,00277778h)/1000=0,0138889kWh ?
no, you need report your meter value. ('meterstand') in energy If you have dual tarif, you will need to sum the value of the day and night meters.
Currently I have similar calulation like you shown to find the phase meter values, as the Dutch P1 meter does not provide the meter value per phase, but gives the power and I wanted to know on which phase I'm consuming the most (so my home battery can be connected there). In that case I do something like: Ph1 kWh = last Ph1 value kWh + ph1 W * (second since last value) / 3600 for each phase.
NB. As SolarEdge is not necessary handling the initial value of the meters very well (see one of my issues earlier in this repo) I changed my script to start at 0 from when I started measuring. So I always substract the a fixed inital meter value from the meterstand. Otherwise you see an enormous first / initial value. That is disturbing your year totals.
Thanks Marcel, Understood to change the energy values to sum of Tarif1 + Tarif2, those are available.
Trying to understand when you're starting with value 0, know why you do it though. Seen these high energy spikes disturbing my year reporting :-( I'm pushing the values to MQTT from an OpenHab rules, so I guess it would be on (re)starting OpenHab.
This is btw what my Landis Gyr E360 meter spits out on P1.
1-3:0.2.8(50)
0-0:1.0.0(231xxx3840W)
0-0:96.1.1(4530303532303xxx35383039343139)
1-0:1.8.1(007777.144*kWh) <== this would be needed for energy reporting
1-0:1.8.2(005576.970*kWh) <== this would be needed for energy reporting
1-0:2.8.1(004030.973*kWh) <== this would be needed for energy reporting
1-0:2.8.2(009081.937*kWh) <== this would be needed for energy reporting
0-0:96.14.0(0002)
1-0:1.7.0(00.393*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00008)
0-0:96.7.9(00003)
1-0:99.97.0(2)(0-0:96.7.19)(000101000000W)(0000000399*s)(210609060051S)(0000000443*s)
1-0:32.32.0(00024)
1-0:52.32.0(00018)
1-0:72.32.0(00020)
1-0:32.36.0(00001)
1-0:52.36.0(00000)
1-0:72.36.0(00001)
0-0:96.13.0()
1-0:32.7.0(230.5*V)
1-0:52.7.0(231.3*V)
1-0:72.7.0(232.7*V)
1-0:31.7.0(001*A)
1-0:51.7.0(001*A)
1-0:71.7.0(000*A)
1-0:21.7.0(00.195*kW)
1-0:41.7.0(00.232*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(00.034*kW)
!8869
/XMX5LGF0010xxxx4858094
Yes, indeed those are the ones I use.
Yes... I also have my first year with a huge spike of 30 MWh ;-) in a single day ( and rest of the year unreadable as the table automatically adjusts to the high value...). I called with SolarEdge support if they could remove it, but the said the couldn't
So this year I when I needed to replace my Solaredge inverter, I made indeed the offset to not have the same problem again.
It is truly a fixed value to offset, as SE expects the number to grow over time. So in your case, as you already have the spike, no need to change it anymore (unless you still need to do the summing of the Day+Night meters)
Big thank you nmakel and marcelrv, After the suggested engery-related updates the "Verbruik" and "Productie" widgets seem to work well.
Added the per phase energy consumption to get consumption insights as well.
May I ask you about your experience with the battery (Solar Edge 10kW?) Okay to do this per DM (and in Dutch).
PS. In January I asked SE to remove my incorrect monitoring values as well. Nope, the Dutch response was that they couldn't do it........
I have no experience with battery... Yet. I have this week received my battery, ( not SE), but have to see if there is any chance to die it in the SolarEdge monitoring.
But you can reach out, no problem. (You can dm in in openhab forum, or send email)
Uploading battery data to Solaredge would be nice!
Got my 90 kWh pack up and running with Victron and would like to tie it into Solaredge too.
@marcelrv @Maikel-K did you ever manage to integrate a DIY battery into the SE monitoring?
No I haven't invested any time in it yet😅
Same here... Still on my wish list... But no time invested
Thanks for your response guys. I actually assume that it is not possible anyway, as nothing besides Energy and Power is available for the dummy meter at the SE portal if you check the charts page. Have the impression that the need to configure it as a 'meter' limits the capabilities the inverter would check, even if correct data would be provided. A pity, but great work by @nmakel for this piece of software nonetheless, huge thank you!
@fkemps my power reporting now runs since some months without any issues, but I still did not get the energy stuff into SE. Currently my json, that is submitted with semp-tcp.py looks like this:
{ "l3_power_active":361.5,
"l3_energy_active":2.1999999999999993,
"energy_active":2.1999999999999993
}
Am I missing anything? Do I need to add the remaining phases even if it is a single phase system and if this single phase information worked with power?
Hello SE geeks,
I'm having trouble reporting my Own Usage (Eigen Verbruik) and Export/Bought (Exporteren/Gekocht) on the SE Monitoring platform. Using the Solaredge_meter with MQTT connected to SE5000H via modbus RS485-1 (termination on).
The solar panel, home, and export power seem to work well, both online monitoring platform and SolarEdge App are showing the correct kW values and green/orange arrows during the day. I can't get the reporting working correctly (blue/green and blue/red bars) because the Exporteren and Gekocht values are incorrect for unknow reason.
Questions 1) Is the modbus communication working as expected? 2) DEBUG information looks different compared to what I've found online. Why the "Frame advanced, resetting header!!" message. 3) What are the necessary MQTT fields and value dimensions? 4) Am I correct that latest pymodbus version supported is 2.5.3? (with latest 3.6.3 solardedge_meterproxy didn't start)
Communication between solaredge_meterproxy and SE5000H is via Elfin EW11A, 9600_8,_N,_1 as shown.
My environment and configuration details can be found in the drawing
Thanks in advance for any guidance to get this last step working........in preparation for adding a SE battery to the environment.