Firmware is automatically pushed to the ECU-R
1 Like
just to say how happy I am with the insights this integration gives me:
the per panel graphs are really nice to have. I could even decide based on this data to move and reposition some of the panels to get more out of this system.
funny to see also the temperatur… The shade temp is now 6 degrees, seeing 20+ on the inverters is showing how much heat they are producing.
Great view Sander, also still very happy with the integration 
to Kyle! Inverter temperature could heat up to 80 degrees celcius! It’s nice to see power is increasing every day towards the summer 
Kudos to Kyle indeed, not just for the integration but I also got inspired by his Lovelace UI (post 100 in this thread) and build something similar.
Too bad current production is low, was way better this morning.
I’ll post a screenshot in the future of my Grafana page with even more details and graphs of the whole setup.
What’s the color codings meaning here ?
These ‘bars’ represent the 18 solar panel as they are layed out on a flat roof (east/west orientation).
The color groups are the panels connected to a single inverter, so 4 * 4-port inverters, 1 2-port inverter)
Each bar chart has a maximum scale of the Wattpeak of each panel, and fill up with a brighter color as they produce more energy. The actual number value is also displayed in the bar.
I figures something like that indeed, but couldnt explain for sure the 2 purple ones . so they installed a yc600 or is is a qs1 with only 2 panels?
Hey @ksheumaker, personally I’d still drop this option 
, there is less data/parameters to obtain from this 4540 method. If I could I would concentrate on compatibility for the YC1000. This way the integration would be complete for all three possible inverters which can be attached to the ECU-R. And maybe later add the other features from the EMAapp also (like historical data). Also don’t forget that version numbering must also be included in the manifest: “version”: “1.x”,
please don’t get me wrong, it is your integration and I am still grateful to you for building this so the decision is yours.
It’s one YC600 indeed and four QS1
Thanks. I haven’t dedicated much time to the ethernet code, because I agree and don’t see a lot of value, the wifi stuff has worked great for me, and we are getting less data from querying port 4540.
I know about the version update in the manifest and will certainly be adding that shortly. I didn’t know we had someone trying to get it to work for a YC1000. Can someone provide me the insight into what needs to be changed, or the data structure of the YC1000? That should be a lot easier fix than the switch to ethernet.
I’m certainly open for anyone that would like to contribute the ethernet code as a patch through GitHub though. And on that front, if there are issues like getting the YC1000 to work, opening a GitHub issue would be great, then it can be tracked and you can see when the code has been updated to include that.
you’ve been busy
That ‘getEnergyfoweekmonthyear’ is that really served by ECU?
had this now too twice this week. The integration seems not to recognize the original entities and creates a _2 version of those.
@kyle, would a ‘reload integration’ action be feasible to facilitate? i have no idea how that part works, but for most integrations it seems a good way to get away from some incidental situations.
APS18 frame
I managed to grab the ECU-C firmware 
.
In one of the files (firmware is Linux based), we can find something like this (names of methods, a blue ones, are not mine 
)
We can say that we know more about those unknown params 
Accordingly, the frame looks like this:
Hey Wadzio, don’t mean to be rude but ECU-C is offtopic here A new topic should be started and who knows someone will step up to further develop an integration for the ECU-C. Lessons can be learned from this topic thread though.
I don’t want to be rude either
But did I write: please integrate with ECU-C?
I only wrote that, based on the ECU-C firmware, we know the meaning of the previously unknown fields from the APS18 frame
And by the way: the ECU-C should also work with this integration on the WiFi interface
Ah, I did not realize that the ecuapp is also intended for the ECU-C and therefor the integration also works with the ECU-C as an advantage. Topic could be rewritten to ECU-R/ECU-C then.
So the APS18 frame is related to the 4540 method, I was close, great that the parameters are clear now!
Does the integration work for you, having the YC1000?
First of all thanks to everyone for creating this project. I’m using this now for approx. one week for my PV installation (Ecu-r together with two QS-1 and one YC600 inverter) but I encounter a lot of stability issues. I do get data in HA for some hours but then all entities are not available and in the logs are error messages for error fetching and connection failed. When I power cycle the Ecu-r all is functioning properly for a few hours and then same errors pop up.
I already did a ip address assignment in my router for the Mac address of the Ecu-r so that it uses the same address on the local network. Any other suggestions?
What is your current ECU-R firmware version (we are now at ECU_R_1.2.17009)? Indeed, if you are connected via Wi-Fi, you have to instruct the router to assign the node (ECU-R) a fixed IP address based on the MAC address. Make sure that the ECU-R is logged into your WiFi network and that you are not accidentally using the ECU-R’s temporary hotspot with the integration (IP address would then be 10.10.100.254). The ECU-R switches off this hotspot after a while. If the ECU-R is logged into your WiFi network, make sure that that the reception is good. Test the stability of the connection by, for example, running a ping [ip-address] -t on a PC for a while.