During install and configuration the unit broadcasts its own WiFi network and all data can be accessed via the APSystemsECU app to verify connection. Configuration is done through that app, after which it joins the customer’s WiFi network and starts reporting data to the cloud service. After that point the customer is instructed to use the APSystemsEMA app or the website to access the data via the cloud service.
I’ll see if I can locate some way to access the ECU directly on my own network as well; meanwhile I’ll be eagerly watching this thread since I just set up my Home Assistant install yesterday.
I have checked this but on the ip address of the ECU there are no open ports. As far is I can find there was in a early version of the ECU a local webinterface where you can pull info out. But in the new version it is not available. Maybe there is a way to enable it but there is nog much info around on the internet.
My findings are similar; you can press the button and get it to broadcast its own wireless network that connects with the ECUApp. Once that expires or is configured to connect to an existing Wi-Fi, the ECU starts reporting data to the website and stops being available locally. The website seems to be the only choice for the ECU-R.
I installed appdaemon and the script, which worked out of the box but I made some tweaks, and then created my own module to pull my net metering stats from my power provider (Florida Power and Light) as well.
I’m learning how to write addons directly for HA, and am using the FPL as a sample case, but plan to do the same with the APSystems EMA as well. I’ll contribute the code for both once I have something that works.
This is a side project for me in addition to both work and school, any my first addon code, so I don’t have a timeline for completion.
@phrfpeixoto Are you using an ECU as well? I have written a windows program that proves that you can indeed work independently of the cloud. So it’s just a POC not a data logger. The most important thing is to return a correct timestamp to the ECU-R (don’t know if it also applies to the ECU-C). If the returned timestamp does not match the last data sent from the ECU, the ECU will retransmit buffered data frames or go into error modus. It requires some Python knowledge to deploy the four necessary socket channels for this purpose. Also, the DNS query from ECU to apsystemsema must be routed locally to the node that is capturing the data. But that was all under investigation in January of this year. Meanwhile, the necessary firmware versions for the ECU-R have been released and since I now know what is being sent, I don’t feel the urg to work off cloud anymore. Data also does not include temperature and Zigbee signal strenght.
There is an integration for HA available on Github (based on the ECUapp) and there is also a discussion on GitHub to directly read Zigbee from the inverters without ECU.
Note: registration to the EMA cloud is available for DIY installers
Since your post, there have been some changes. There is an integration available on GitHub. It reads the ECU same way the ECUapp without the need of activating the ECU’s own WiFi point. Ports are open (Wifi as well as ethernet).
@HAEdwin
Amazing work! Congratulations! Is that open source? Any way I can deploy it directly on an RPi running local and push the necessary data through MQTT?
Your screenshot shows the raw socket comms, but we can’t see exactly which parameters are being reported by the ECU, and what sensors we could create from that data.
The bottom line is that the ECU expects a response to the data sent by the ECU to the EMA cloud.
Every 5 minutes the ECU opens port 8995 or 8996 and sends out the data to EMA. In response the ECU expects a timestamp -5 minutes so that the ECU data buffer is maintained. Port 8995 or 8996 is being closed after a while so response must be given while the port is open. Command and Timestamp format is 10120210328100026. If no response is sent, ECU shuts down after a while, thinking there is no internet connectivity.
I’m now investigating if timestamp responses must be given on these two ports or can also be given on 8899. This is the query port the ECUapp uses. Purpose is to keep the ECU up’n’running.
EDIT: Well this experiment failed
It would take some programming experience to build this in Python the ECU responses can be what confusing if it empties the data buffer so it is complex. Less parameters are available (no inverter temperature and inverter signal strenght).
Due the problem with the old apsystems API that is not working anymore, I create a new HTTP APsystems Sensor. It is in HACS structure. So if you are using HACS, just add this repository:
It uses the https://apsystemsema.com web site to get the information. So it works with any APsystems inverter / ECU model.
Please, help me to test. If you like, just give me a beer
I got access to an ECU-C for 1hour.
I found out that you can activate Sunspec Modbus on the ECU-C.
Next i have installed the Modbus Doctor Software. https://www.kscada.com/modbusdoctor.html
Modbus TCP will work on ECU-C
I have read the holding register 40000-40399 and i got an answer.
may be other registers are also OK
it seems that the registers are the same as solaredge
Next is to find out all the registers that are used.
have a nice day
Jean