APsystems APS ECU R local inverters data pull

Screenshot 2021-03-06 105122
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 :wink:, 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.

Based on EcuAPP and Firmware:

1 Like

you’ve been busy :slight_smile:
That ‘getEnergyfoweekmonthyear’ is that really served by ECU?

Yes. This is for this(those) screen

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 :star_struck:.
In one of the files (firmware is Linux based), we can find something like this (names of methods, a blue ones, are not mine :yum:)

We can say that we know more about those unknown params :slightly_smiling_face:
Accordingly, the frame looks like this:

Hey Wadzio, don’t mean to be rude but ECU-C is offtopic here :wink: 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 :wink:
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.

What’s the quickest way to find my firmware version? ECU-R is connected to local wifi and is accessed by the IP assigned to it, so not through the wifi hotspot of the device.

EDIT: took a look on tweakers.net to find a test python script and found my firmware version: ECU_R_1.2.17009. So thats seems to be fine

Yes, and what about the stability of the WiFi connection for your ECU? Btw if you click on the ECU Current Power entity you also should be able to see the firmware version.

Tested with the ping command; gives me response times of ~ 5ms for 90% of the time. There are some spikes to 40 - 80 ms but these are occassionally.

Another thought; there is something happening in the ecu (overload? crash? blocked request?) so that port 8899 is blocked / not responding. So i presume something in the communication from our side can cause this. But its hard to know what without good debug data (yes i am a programmer myself) especially when we don’t have the exact protocol information. Are there some tools you guys use to trace these bugs? i can imagine running a python script locally, catch the output and wait for the crash :slight_smile:

Just to make shure,… did you register for the EMA? ECU still shuts down when data cannot be pushed to the apsystemsema.com website. The ecu expects a response from the EMA so that the data buffer management runs smoothly. So besides using the integration make sure you registered with DIY registration method if you haven’t done that yet: https://emea.apsystems.com/wp-content/uploads/2020/10/DIY-EMA-account-registration.pdf

The ECU seems to shut down if it does not receive a timestamp every 5 minutes. This ensures the ECU knows it is keeping up with updates to the EMA site. If connection to EMA fails for a longer time period and then gets restored, the ECU buffer will flush it’s data to EMA to ensure all data is present.

Tomorrow I am going to see what the effects on ECU are if I send a timestamp to the ECU each 5 minutes while blocking access to EMA. My hope will be that the ECU stays up’n’running although not connected to the cloud. I know this works in response to sending data to the EMA cloud, I wrote a EMA proxy to prove this but now the response “from EMA” will not be in direct response to data sent from the ECU to EMA.

My best guess in ECU instability is when WIFI traffic is hampered while communicating and when inverters are not reporting consistantly. It’s proably also the reason that the device is only reporting to the cloud once each 5 minutes and (reportedly) on bigger installations even once in 15 minutes. (not sure when 'big’starts).
sometimes ECU recovers by itself, sometimes it requires power cycle.

To get around this unavailble thing, I’ve used a smart plug on Hue for the ECU and created below automation:

alias: Fix unavailable ECU
description: ''
trigger:
  - platform: state
    entity_id: sensor.ecu_current_power
    to: unavailable
    for: '00:09:00'
condition:
  - condition: time
    after: '09:00'
    before: '21:00'
action:
  - service: apsystems_ecur.stop_query
  - service: light.turn_off
    target:
      entity_id: light.ecu_power
  - delay:
      hours: 0
      minutes: 0
      seconds: 20
      milliseconds: 0
  - service: light.turn_on
    data: {}
    target:
      entity_id: light.ecu_power
  - delay:
      hours: 0
      minutes: 3
      seconds: 0
      milliseconds: 0
  - service: apsystems_ecur.start_query
mode: single