@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
I was wondering how people have enabled Modbus over IP and if possible to do as owner, instead of the installer.
On other matters, I was thinking to start a local version of the APsystems sensor. Basically, the same as the above but querryng the local MCU instead of the cloud. Would people be interested on that?
I love the work from @bgbraga & @synack, but I can see 2 benefits from this. First, my unit has consumed/import sensors as well as the connection to the panels so I could get a few extra data points there. Also, since the queries are local, data could be refreshed more freely than a cloud service. Bear in mind all measurements happen in 5min slots, so there’s no point on anything smaller than that.
To do this I was looking to do HTTP requests to the MCU such as “http://<MCU_IP>/index.php/meter/old_meter_power_graph?date=2022-04-07”, however I’m unsure whether the same API is in all MCU’s. I only have MCU-C (less than 48h with it), so I’d appreciate if people can confirm it works on others.
So far I have the following entry-points:
Power by inverter data: http://<MCU_IP>/index.php/realtimedata/old_energy_graph?date=2022-04-08&period=weekly
Energy by inverter data: http://<MCU_IP>/index.php/realtimedata/old_energy_graph?date=2022-04-08&period=weekly
Power measured by sensors: http://<MCU_IP>/index.php/meter/old_meter_power_graph?2022-04-07
Energy measured by sensors: http://<MCU_IP>/index.php/meter/old_meter_energy_graph?date=2022-04-08&period=weekly
Is that the old ECU’s? ECU-C seem to be refreshing all(panel info, total generated and meter information) at 5min intervals. I actually have the HW for it, it’s the same as any zigbee2mqtt but I don’t see what’s the advantage between this and what you have in the ECU. As far as I can tell this project also do 5min intervals.
ups, maybe misunderstanding :-), current i get my data from apsystems server and they reduce to 1 hour, therfore i like to switch to a differnent way, but… have a ECU-B
