Thank a lot
Thanks for starting a new thread…
I’m just about to pull the trigger on a Solar install (SolarEdge obviously) and seems that ModBus over TCP is the way to go. At this stage, I’m holding off on the battery, but other threads have talked about clamps etc.
Just to confirm, I can connect in via RJ45 to inverter and I’m all good? There will be two inverters, if they’re set up properly as a leader and a follower, do I just need the leader connected to the network?
Thanks.
Not the biggest expert on installation but…
Yes, I would make sure your main inverter has the wired ethernet connection to your network and guess that is enough. I am assuming that the second inverter will share it’s data with the master through RJ45 (modbus) and your master is the one you query over modbus.
When it comes to clamps etc… In my installation I have a SolarEdge meter installed in my breaker box, directly after the 3 phases enter the house. It has 3 clamps for the 3 phases and is also connected through RJ45 (modbus) with my inverter. This meter is required to get data about self consumption, import and export.
1 Like
I dunno man. I have ethernet running to my router directly and modbus over TCP is working but I don’t get any data over M1, M2, or M3 channels for a reason that no one can take a guess at why or what is missing, so be careful and don’t expect this is a guarantee.
Thanks very much - looks like I’ll need to get one of these added to my install then…
@Remko: Just saw that the old thread was closed. I read the initial post in this new thread. But I am not sure, if I understood all your points correctly. Maybe you can quickly clarify the following questions:
- Is there any difference between old and new setup apart from “WillCodeForCats” instead of “binsentsu” and some non-functional formula refactoring?
- Why are you saying “binsentsu” was/is not maintained (anymore)? Is there any problem with this integration that I missed?
- I am currently running your old setup with Ashporks “fix” and some own extensions on top. Do you see any benefit in moving to your new setup for my single-inverter-with-single-battery-setup?
Thanks for your answers. In any case I am happy that you are still driving and improving this topic.
- no, there are no further differences. This integration offers support for multiple inverters (which I do not need) and I like the naming and structuring of the entities better. So overall…in my setup, just cosmetic changes. I did the formula refactoring based on some of the recommendations in the other thread and learned some new things about yaml, that is why I updated…
- Well…binsentsu did not bring out any updates anymore. A couple of releases ago, there was a significant change in Homeassistant which would have caused it to stop working. I forked the integration and made the necessary change, which he then incorporated. WillCodeForCats is actively developing his integration, plus the cosmetic differences made me change
- So overall…I do not see a benefit in your setup. Our setups are the same and besides the cosmetics…no benefit at all.
And yes…I keep fiddling with HomeAssistant and since I like this setup, I always keep looking at improvements.
2 Likes
A few of us have issues getting any of the M1/M2/M3 sensor data. We get all the “main” data, but need the M1 data to make use of these dashboards. I have installed/uninstalled several times but no joy. Any ideas?
I don’t understand why they wouldn’t show. It is an issue of the integration though, have you opened an issue there?
Maybe a stupid question, but… What kind off setup do you have, I mean, do you actually habe an import/export meter installed? My parents have a setup without such a meter (which only issue required off you have a battery if I understand it correctly) and therefore do not get these entities of course.
- no, there are no further differences. This integration offers support for multiple inverters (which I do not need) and I like the naming and structuring of the entities better. So overall…in my setup, just cosmetic changes. I did the formula refactoring based on some of the recommendations in the other thread and learned some new things about yaml, that is why I updated…
- Well…binsentsu did not bring out any updates anymore. A couple of releases ago, there was a significant change in Homeassistant which would have caused it to stop working. I forked the integration and made the necessary change, which he then incorporated. WillCodeForCats is actively developing his integration, plus the cosmetic differences made me change
- So overall…I do not see a benefit in your setup. Our setups are the same and besides the cosmetics…no benefit at all.
Thanks so much for clarification. Maybe you can give an explicit hint to all users of the old setup if you’re adding/fixing stuff which makes switching to the new setup worth it.
1 Like
See the instructions for filing a bug report issue on how to enable debug logging which will show low level info when the integration asks the inverter if it has any meters configured. Specifically, there are debug log lines that say “Inverter X meter Y” and some hex numbers like this:
A valid meter (as configured in the inverter through the front panel or SetApp) should respond with C_SunSpec_DID 0x1 and C_SunSpec_Length 0x41. If it doesn’t (in the example there is no meter 3 so Inverter 1 Meter 3 is 0x0 instead) or responds with other values then it’s not a valid meter according to the specs and you would need to open a support request with your installer or SolarEdge support asking why the meter doesn’t identify itself as a meter according to the published specs.
I am the author of solaredge-modbus-multi so here’s my backstory about why my integration exists.
I started out looking for a way to get local data from my setup of two inverters and one meter. I searched a lot and it turns out very few (basically nobody) cared about setups that had more than one device, until I found someone had made a fork of an integration that did support two inverters. So I ended up using that fork of what I’ll call it the “other” integration. At the time my knowledge of development for HA and Python was nonexistent, although I have plenty of experience with C/C++, Perl, PHP, and other languages. Just never Python.
I started using the other integration and tested the PR, but it quickly became apparent that the author had no intention of actually merging the PR for multiple inverter support, but did merge requests for other stuff. I don’t know why, but it was critical to me so I started a fork that included the PR I needed and tried to backport upstream changes into my fork, but that also eventually ran into my Python knowledge limits at the time.
In the meantime I decided to try to learn how to write a complete integration from scratch for a Tekmar home automation gateway integration since literally none existed: my tekmar-482 integration and tekmar-packetserv add-on. I learned a hell of a lot about HA development and Python after tackling that task, then I took all of that knowledge and applied it to a ground-up rewrite for my solaredge-modbus-multi integration. I’ve tried to adhere to HA developer guidelines and practices, keep up on HA changes, and make sure the integration works as well as I want it to work since I’m actually using it for myself. That means I want my work to be robust and error free as possible.
The only thing my integration lacks over the other one is that (It has control options added since this was written.)solaredge-modbus-multi doesn’t have power control command support. This is because I don’t personally have any batteries, but I am slowly working through that using a modbus simulator to pretend to be a battery using data based on other user’s debug logs (since I don’t have a real battery to develop with). So it will eventually have that feature too, but obviously without real hardware on my end and most people still wanting to stick with the other integration means less demand for that feature and fewer testers for me. The beginning of that work is in PR #117 and the power-control branch.
I’m biased but I think my integration is better maintained, more robust, and higher quality. I just took a glance at all the open issues and complaints in the other integration’s “issues”, and my impression is that I think that my solaredge-modbus-multi integration fixes or addresses almost every compliant, problem, or defect present in the other one. I take pride in trying to quickly address issues that are brought up, especially if it’s a bug I missed, because I do not want to ship low quality or incomplete releases. Since I do use my own integration I see things over time that can be done better.
That’s the basic story behind why solaredge-modbus-multi exists. Even if nobody used it I would still be working on it because I use it for my system, but I’ve added a lot of features for stuff I don’t have since other people do use it instead other options. For example, I recently added SolarEdge Synergy support which is something I was aware of but didn’t originally spend time on since Synergy inverters are large three phase commercial systems up to 120kW, not something I thought HA would be connected to, but someone did so I added support for it.
Of course, if you are happy with the state of the other integration then by all means keep using it.
Edit: The v2.2.7 release of solaredge-modbus-multi will add support for battery commands.
7 Likes
@WillCodeForCats, thanks for this detailed explanation. I am a software developer myself, so I fully understand your points and can totally value your work and motivation. Much appreciated. In the near future I will definitely switch to your integration. The only thing which hindered my so far was the fact that the old one is working stable and a switch would cost me quite a bit of time since I extended @Remko old setup quite a bit for my own purpose. Anyways, by the end of the year I will have switched. Keep up your work. Thanks.
Quick question: I did not understand “power control command support”. What is this for? When would I need it? I have a battery. But as far as I understood, this is supported by your integration even tough you don’t have a battery yourselves.
@Remko and @WillCodeForCats thanks for the info. I am not sure how to enable the detailed logging you are showing but that looks like my next step, then I can file a bug if the DID shows 0. Are there instructions for enabling detailed debugging?
If the DID and Length are not 0x1 and 0x41 respectively, then it’s not a bug, the inverter is saying it doesn’t have a meter configured. Those are a header that say “yes there is a meter in this config slot” if set to those values.
If you click on the bug report template under issues that template has instructions for logging configuration for your configuration.yaml file.
Edit: I should say it’s not my bug to fix. If you actually have a physical meter (assuming it was commissioned properly) and the inverter is still saying no meter then that’s a question for SolarEdge support or your installer.
Some people like to change modes under what conditions their battery discharges or charges. I don’t have a battery so I can’t say why this would be useful or not.
The integration only supports reading and reporting battery data. It does not support sending commands to change battery modes yet. Storage and site limit controls are available since Release v2.2.7.
1 Like
It is useful if you have a time of use tariff, you can of course do this via the SolarEdge installer tools (SetApp) if you have access to them (rumoured to be coming to the consumer facing app this year).
Even if you do have access to SetApp there are certain configurations that are impossible e.g. in my case I don’t want to drain the battery when off-peak power begins because I want that power to be used in the morning during the on-peak time.
I have these automations:
- Change solar battery mode to “Maximise self consumption” when off-peak ends.
- Change solar battery mode to “Off” when off-peak begins.
This script is also worth a look to see what can be done:
2 Likes
This was the beginning of my research, wich ended up with @Remko old setup and additional alternative solutions.
I am really happy to have full storage control with automated predictive charging to maximize production and the ability to care about the storage‘s aging.
In personal contact with fredlcore, he told me the script isn‘t in use any more, since he switched to FEHM. But if he will find some time in unknown future, he thought about developing predictive charging on an ESP32 board as a standalone solution for solcast + solaredge.
@SgtBatten
Did you change your energy.yaml to work with this integration? If so, could you please share it?
@Remko
Can you provide details on how to add multiple inverters to the energy.yaml? I have three inverters and I am trying to figure out where to add xxx_i2 xxx_i3 into the code.
What is FEHM? What additional alternative solutions did you end up with?