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 
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
My PV installation is done by an installer and setup access to the EMA website. I also have access to the EMA app. So i guess this step is not needed as data is already pushed to EMA. I also want to keep a working EMA app and let the system be accessible by the installer, just in case of something hapening / waranty.
The time between the ‘crashes’ are variable, right now i restarted the ECU-R yesterday around 12:00 AM and it is still functioning now. But i had crashes after a few hours in the past.
@checking12 smart solution, did you encounter any ‘crashes’ when using this automation? or is all stable now.
You might try sending a reboot through that script. As far as we know, this only works if you also have the ECU connected by ethernet cable but if it works you can use the smartplug for other things. Wadzio came up with the existance of this command.
Send the string “reboot” to the ethernet ip-address of the ECU on port 4540. This is quite fast and settings are retained.
ECU responds with “reboot ok”
The non responsive port, doesn not seem a crash, but the ESP being stubborn. Had weeks with no issues, sometimes 2 times a day… hence the automation.
I also blame the 2,4Ghz band being distorted around my house… too many devices on that band. 2 zigbee networks in my house and a shitload of wifi nearby.
The hardware for the ECU isnt the most sophisticated, but thats china approach, built cheap and a lot.
In the end the least demanding proces would be de man in the middle (proxy) setup, it’s what the ema site is relying on and dont mess up the device itself.
A note to others re: a setup snag I encountered (one of those “D’oh!” moments)–
My ECU was set up via ethernet by my installer, it had never been connected to wifi. I could get the ECU’s access point to appear by unplugging the ethernet cable and power cycling, but couldn’t figure out how to configure the wifi via what I thought was “THE app”–
Turns out there is the consumer-level, data reporting “EMA App”, which my installer had me download, and a separate “ECUAPP”, which is I believe intended for installers and has the ability to connect to the ECU via the ECU access point.
Everything worked great once I overcame my self-imposed befuddlement! Thanks!
Welcome and thank you for the comments Matt. I added prerequisites to the readme in the GitHub repository to make it clearer for future users. I also added a version number because from HA 2021.6 it will not be allowed to omit the version number in (custom) components. @ksheumaker can you pull them in (after review)?
It’s a known issue. Zigbee and WiFi use the same 2.4 GHz band. Only the Zigbee signals are narrower. To prevent issues with interference carefull planning of WiFi channels with neighbours might help although there will always be overlap with Zigbee signals. If possible move WiFi to the 5Ghz band only there’s a lot more bandwith available there.
Apart from the YC600 I only use Z-wave devices and I must admit that the integration is very stable.
Today I created a fork and made some changes to hopefully support the YC1000 also. Dataframe looks almost the same so that should work. @ksheumaker if you have time please review and pull revisions.
Sorry for not being more active on this, real life has been pretty busy. I did just merge @HAEdwin PR so the newest version in github the latest HA versions (by adding a version # to the manifest) and adds YC1000 support. I’m going to work on getting it prepped to be included into HACS later this evening.
Glad to see additional people using and having success with the integration!
No problem @ksheumaker, it was kind of a personal mission to complete the compatibility and completeness of this integration with the addition of the YC1000.
Håkan reported on Github that this integration does not work for the ECU-C. Initially I expected that, partly based on the compatibility sheet, the use of the same ECUapp to configure the ECUs and the assumption of @Wadzio that the integration should also work for the ECU-C based on the firmware.
I set my ECU-R to connect by WIFI which is working. I assigned it whit a fixed IP. Strange is that if I look in my IP-scanner (Advanced IP-Scanner) the ECU does not a appear. Even in Wireshark nothing is visible. Also in my DHCP-server the IP is not vissible. In the APS-app all the data is receiving so there is a connection.
How can I make it vissible?
@smurmug If you assigned a fixed IP-address it will indeed not appear in the DHCP leases unless you assigned the fixed IP within the DHCP range. Your fixed IP address should reside outsite the DHCP range. But a wrong subnet could also be at hand here. If you’re on Windows open a CMD and type: “ping [ip-address]” (without quotes and brackets) and see if you get a response. You can also asign your ECU-R a fixed IP-Address in the router configuration. What do you mean by APS-app? There are two apps “ECUapp” and “EMAapp” The first connects to a temporary ECU-R hotspot when the button on the side was pushed. The other one connects over the internet to the EMA website where your data is pushed upon. Best way to try if assignment of the fixed IP-address succeed is to ping the node.
Hello HAEdwin,
The APS-app is the one one my laptop. I have a installer account and a custumour account. Also I have the ECU-app en the EMA-ap on my phone. Data is pushed upon al apps.
The fixed IP is within the range. When I connect the ECU wired then I see it in my IP-scanner as connected and I can Ping it also. If I take out the wire the ECU stays connected and uploads the data but in my IP-scanner it is seen as not connected. I even can’t Ping it anymore.
In Wireshark I can not find anny connection in booth ways, wired or wireless.
How can I make the wireless connection vissible?
Is the Mac-dres for booth wired and wireless the same? If not how can I find the wireless Mac.
