-
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
Troublesome Own Usage (Eigen Verbruik)and Export/Bought (Exporteren/Gekocht) reporting #29
Comments
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.. |
Hello nmakel, Upgraded to pymodbus 3.6.3 but solaredge_meterproxy did not start anymore with following error.
Solved it by updating semp-tcp.py and replacing Big to BIG and Little to LITTLE e.g. 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.
The SE monitoring behavior changes with the values I publish on MQTT. This is what I have currently Consuming from net only.
Consuming and delivering to net.
|
I think the problem lies in your Here is an example data set from a single phase system connected to a three-phase utility, using a SDM630 kWh meter:
|
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. This looks promising going forward. |
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 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). 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, 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 :-( This is btw what my Landis Gyr E360 meter spits out on P1.
|
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, 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?) 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. 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. |
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:
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
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.
The text was updated successfully, but these errors were encountered: